😭 Damn, how much Golang surpasses Node.js 😭

# [ $davids.sh ] · message #195

• @ [ $davids.sh ] · # 700

  – The built-in test library just WORKS, right out of the box – There's a built-in benchmark library – Built-in linter and formatter (prettier) – Libraries can be imported via URL, for example, directly from GitHub, unlike some others (yes, I'm talking about you, npm, you mutt) – Want to know what a library function does? Click on it, and instead of going to the .d.ts with types, you immediately go to the implementation (specific code) of the library and can study it – You type the package.function name, and Go automatically imports it – The built-in Go code parser with convenient AST tree manipulation + a built-in templating engine allow anyone to write their own code generator – switch case with predicates at the case level – Want a library? Most likely, the one you find will work really well – No bullshit with typing: no npm i -D @types/..., typing is so dumb that you can't write any magic, anyone can read and understand this code

  And many, many small features that turn coding into a finger dance

  The text doesn't fully convey the pleasantness of all these things; you have to try it, and then it even becomes unpleasant to write in Node.js (I have fewer questions for TypeScript, but until it gets its own virtual machine and separate infrastructure, it's also an accomplice)

• @ Kirill Arutyunov · # 701

  You haven't even compared it with PHP yet.

• @ Kirill Arutyunov · # 702

  By the way, yesterday I had a brilliant thought about PHP:

  Imagine you code in Java but with a lot of $$$$$ and you still have no money. I think people become angry and start to hate PHP.

• @ [ $davids.sh ] · # 703

  The existence of PHP is the reason why JS isn't the worst language in the world

• @ [ $davids.sh ] · # 704

  BUT in defense of PHP: it's the language that developed serverless long before it appeared (I can even write an article on this topic sometime)

• @ Kirill Arutyunov · # 705

  Well, in terms of the JS ecosystem, it really sucks compared to PHP.

• @ [ $davids.sh ] · # 706

  And yes, Symfony and Laravel are among the best frameworks on the market (among all languages).

• @ [ $davids.sh ] · # 707

  On Node.js, things like Nest.js look like a joke.

  I'd say Laravel gives RoR and Django a slap in the face, and Symfony finishes them off in the corner ASP.net.

  The only limiting factor is the syntax itself and some architectural decisions of PHP, which is why it can still offer something to the first two, while ASP.net, Spring, etc., already win in certain categories simply due to the fact that they are more advanced languages.

• @ [ $davids.sh ] · # 708

  But this is all IMHO, because it's debatable

• @ [ $davids.sh ] · # 709

  Specifically, if someone is already a Senior in a certain language, I can't advise them to go into PHP / Java / C# / Python / Ruby, unless they specifically want to join a particular company that uses them.

  These are all first-line defense languages.

• @ Nikita · # 710

  Here's a brief impression of Cargo (Rust):

  Cargo is Rust's build system and package manager. It's incredibly well-integrated and makes managing Rust projects a breeze.

  Key highlights:

  • Dependency Management: Adding external libraries (crates) is as simple as listing them in your Cargo.toml file. Cargo handles downloading, compiling, and linking them automatically.
  • Build Automation: cargo build compiles your project. cargo run compiles and runs it. cargo test runs your tests. It's all very intuitive.
  • Project Structure: Cargo enforces a standard project layout, which makes it easy to understand and navigate any Rust project.
  • Publishing: cargo publish makes it easy to share your own crates with the Rust community on crates.io.
  • Workspaces: For larger projects with multiple related crates, Cargo's workspace feature is a lifesaver, allowing you to manage them together efficiently.

  Overall:

  Cargo is a huge part of what makes the Rust development experience so pleasant. It's robust, fast, and takes care of a lot of the boilerplate and complexity, letting you focus on writing code. It's definitely one of the best package managers and build tools I've used. 👍

• @ [ $davids.sh ] · # 711

  I've already opened rustlings ))

• @ Yakiv Ponomarenko 🙏 · # 714

  If you're working with small, more or less standard projects: APIs, authentication, some kind of document processing, maybe a couple of external API requests - is it worth considering Go as an alternative to Laravel or Nest? It seems like it would increase development speed and simplicity (not considering the hassle with linters, prettyers, etc.) - am I right, or is this a myth? Does anyone actually do this in Go on a regular basis?

• @ [ $davids.sh ] · # 715

  That's the beauty of Go: unlike everything on its level and below, when you write something simple, it WON'T get in your way (you won't even have to write goroutines).

  The only thing you'll have to do is write tests (preferably integration tests), because Go is absolutely not null-safe.

  But this is often more of an advantage, and writing tests in it is a pleasure (I'll soon post a boilerplate with everything you need for Go).

• @ [ $davids.sh ] · # 716

  At the same time, any library will be of super quality – I'm so fed up with problems in Node.js like "axios / express / typeorm / knex - the most popular libraries, but only with a ton of bugs and they break half the time for absolutely no reason."

  There's simply no such thing in Go.

  Simple APIs can be written ENTIRELY with the standard library: it has http, sql, logger, etc. Right in the LANGUAGE.

• @ Sergey Pogranichnyy 📍 · # 717

  https://github.com/metarhia/impress

• @ [ $davids.sh ] · # 720

  Here's what I'll say:

  1. No ecosystem of ready-made solutions and plugins has formed around it, and most importantly, no community or job openings.

  This means it cannot be compared to RoR, Django, Asp, or Symfony.

  2. It's unpopular and never will be, because it has existed for too long from a too-famous person.

  And this is another loss compared to the aforementioned.

  3. Subjectively, but if something is written entirely in JS without TS, it only has a right to exist as a development platform (Svelte as an example).

  4. It first says "lightweight," and then the heaviest patterns in the world: "DDD, layered (onion) architecture, DI, SOLID and GRASP principles, contract-based approach;"

  Turning Node into Java/C# is a very bad idea (I'm saying this as someone who did it once).

  And in general, Shemsedinov is cool and has many interesting ideas, but his style is from an era of big solutions that didn't pay off, so you should definitely listen to him, but only to understand "how it was back then," and then understand "ah, that's why we're not doing it that way now."

• @ YURII VLADIMIROVICH · # 721

  Right, now we can just throw in more hardware and churn out tons of boilerplate and crap code directly into production.

• @ [ $davids.sh ] · # 722

  If it's about defending "DDD, layered (onion) architecture, DI, SOLID and GRASP principles, contract-based approach," they imply such a distant abstraction from the data source and hardware that you have to work suboptimally from an infrastructure perspective to maintain "business logic purity."

  And it's precisely because of them that in the past, you had to maintain gigantic machines to "unload the entire aggregate, make one transactional change, then a second, and the same, and if necessary, roll back by making a compensating transaction."

  But when you stop creating a bunch of abstraction layers and in an HTTP controller (well, at most, extract functions from an interface, for example, into "features"), you write one optimal SQL command for UPDATE FROM SELECT, iterate through the resulting cursor, sending each ready piece of data to the HTTP response socket, you spend minimal resources, and the logic is much clearer.

• @ YURII VLADIMIROVICH · # 723

  Who understands better? An engineer with a rate of $5000+?

  These abstractions were invented and refined over time as one of the tools to reduce cognitive load. This means you can hire cheaper people to focus on business functionality, and it will be faster and more comfortable. This also applies to the support of what's written.

  And if super high load is needed, then C or Rust will come into play.

• @ [ $davids.sh ] · # 724

  Great, I'm glad it's helping someone

• @ YURII VLADIMIROVICH · # 725

  So, is there anything that could help more, and that you know about?

  Let's take a fast-growing startup with a team of 15 people as an example. 5 of them are backend, 2 are infrastructure, and the rest are mobile developers.

  1. How to maintain the pace of adding new features?
  2. How to organize code and collaborative development?
  3. How to onboard new engineers into the team quickly?

• @ [ $davids.sh ] · # 726

  I've tried to describe all the best techniques for writing convenient, simple, and understandable code and put them into a book https://fop.davidshekunts.ru/

  I won't say it's "for everyone," it's for those who resonate with it.

  If it doesn't resonate, then you can try something else.

  Now, our team of 7 back-end and 3 front-end developers is working on 3 high-load projects, and before that, we used a similar methodology in a company with 300 developers, and it also worked well.

• @ YURII VLADIMIROVICH · # 727

  I'll familiarize myself

• @ [ $davids.sh ] · # 728

  I'd be glad to hear your comments)

• @ Artur G · # 737

  "But when you stop creating a bunch of abstraction layers and write 1 optimal SQL command for UPDATE FROM SELECT in the HTTP controller (at most, extract functions from the interface into 'features'), iterate through the resulting cursor, sending each ready piece of data to the HTTP response socket, you spend minimal resources, and the logic is much clearer."

  But then why is the "database" abstraction needed? By this logic, you could store everything in files and build your own index. Why convert everything to strings every time? So many resources are burned! 😂

• @ [ $davids.sh ] · # 740

  If I understood the question correctly, then the answer is: "Database" is an abstraction in the form of technology, and I'm talking about abstractions in your own code.

  Therefore, a DB is a natural complexity, and "your own abstraction layers" are artificial complexity (I wrote about this in the book).

  And knowing that you like FP, I'll immediately add a comment: when we do layered work with IO (first IO, then logic, then IO, and so on), it's a good approach because it's not about "abstraction," but about control flow, where we want to stay more in the realm of pure functions.

  Example: the "repository" pattern abstracts the DB, and if you make an SQL query, then pass its value to pure functions, then the result of the functions back into an SQL query – this is simply a separation of the IO workflow.

  "Why convert everything to strings every time?" – I didn't quite understand)

• @ Artur G · # 741

  Example: The "repository" pattern abstracts the database, and if you make an SQL query, then pass its value to pure functions, then pass the result of the functions back into an SQL query – that's just separating the IO workflow.

  Should the repository be implemented or not? I didn't quite understand. 🤔

  "Why convert everything to strings every time?" – I didn't quite understand that either)

  SQL is about strings. First, you convert the data into a query string, then you send it to the database. The same situation applies to the response: you receive strings and parse them. 🥸

• @ [ $davids.sh ] · # 742

  I've used the "repository" pattern for many years, but over time I realized it causes more problems than it helps (if you want more details, I'll describe them in a separate article).

  "SQL is about strings." – if you need to query a DB (if you have an SQL DB), you'll have to form an SQL query with the correct argument sequence and attach it along with the arguments to the connection. It's definitely worth doing this through a Query Builder (kysely) or a generative one (sqlc).

  And if you also need to transform the response from the DB, you'll get it from the cursor, modify it, and send it to the client.

  Or what did you mean?

• @ Artur G · # 743

  What I mean is, you can store bytes in files, why this intermediary layer? 😁

  Why build abstract queries and use complex serialization/deserialization? If you want to get an entity, read the file, parse it into an object, and you're done. 😁

• @ [ $davids.sh ] · # 744

  In general, you can do that, but later you'll run into issues with read/write speed, concurrency, storage size, maintenance complexity, and hiring.

  If you can solve these problems by writing bytes, and you won't get fired for the feature development being delayed for many years, then you can definitely do it))

  As a side effect, you'll become the author of a cool new DB 😎

• @ Artur G · # 746

  If performance issues or similar arise, lmdb or similar can be used. And the repository will be extremely simple. 😁

  But you won't need to look for an SQL DBA specialist. The pool of specialists will immediately expand. 😂

• @ [ $davids.sh ] · # 747

  By the way, I'm currently studying the source code of https://github.com/dgraph-io/badger, it's very interesting reading.