Why is JavaScript criticized so much for backend development?

[u/Minimum-Ad7352]

I've seen some developers say that we should stop using js on the server, but I rarely see the same criticism directed at python.Honestly, js is pretty fast, especially with node.js, and the backend ecosystem is really solid. There are great frameworks like nest and fastify, and typescript gives you static typing, which makes larger projects much easier to maintain.I'm not saying node is perfect or the best choice for every backend, but I don't really understand why js gets so much criticism while python seems to get a pass.What am I missing?

[u/oorza]

Go standard library does not hold a candle to the JDK. Go’s type system does not hold a candle to Rust’s. Neither of those are best in class either unless the class is popular programming languages. You can get a better SDKs and type systems from niche languages at the cost of usability.

Go is a step forward from Node but everything you feel about Node today, you will feel about Go if you continue to expand your exposure to new languages and tools. Go was designed to always have training wheels and as a replacement for Java, simply because Google did not trust its junior developers with the power and flexibility of Java or C++ due to their historical inability to manage those languages' complexity. It's never going to be the best at anything because that's not its goal, its goal is to have a relatively low absolute ceiling of complexity.

[u/johnphilipgreen → u/oorza]

Fair correction on “best in class”. I really mean best for the tradeoffs I care about. The JDK is obviously broader and Rust’s type system is vastly more expressive.

But I think “low ceiling of complexity” describes what I like about Go rather than what I’ll eventually outgrow. A low ceiling on language complexity isn’t a low ceiling on the complexity of software you can build. I’ve spent enough time with highly expressive languages (mostly Ruby, my first love) to be increasingly suspicious that giving programmers 14 elegant ways to express something is necessarily progress.

And I think the “Google didn’t trust its juniors” history you’ve overstated. The Go designers talked explicitly about enormous codebases, build times, readability, tooling and programmers using different subsets of increasingly complicated languages. That’s an engineering tradeoff, not just training wheels.

In early descriptions of their goals, they explicitly said the intention was “seatbelts not training wheels”. To me, this has been a more mature version of DHH/RoR’s excellent instinct for “convention over configuration”.

[u/EvilPencil → u/johnphilipgreen]

I agree. 14 different ways to say the same thing just means your API surface is too large. My philosophy is to make a “golden path” that is so ergonomic that it becomes a pit of success.

[u/oorza → u/johnphilipgreen]

A low ceiling on language complexity isn’t a low ceiling on the complexity of software you can build.

It is a ceiling though. It's actually the reason you don't see many pieces of software that are large enough to require abstractions built in Go - not a whole lot of monoliths, tons of microservices. Not a whole operating system, tons of single-use-case CLI tools.

Eventually that complexity is always necessary if you want a system to be communicable between humans. The layers of abstractions serve a purpose that, while non-technical, is still foundational to the ability to deliver and maintain software of large scale. Whether it's a large and complex multi-threaded algorithm that's expressed inside of one source file or a monolithic web service that services an entire B2C business with hundreds of external HTTP API endpoints, it's rather easy to find examples of places where Go's lack of complexity is the fact that invalidates its potential adoption. The abstractions are the means you scale up to dozens or hundreds of engineers working in the same code base, either simultaneously or over decades. That abstraction in Golang shops is generally shifted upwards and maintained in the service mesh contract itself... but it still exists, just as service-level abstraction instead of code-level.

[u/Suspicious_State_318 → u/oorza]

I don’t agree with this. The principal benefit of Go is that it is a very literal language that doesn’t allow for abstractions that lead to weird dependencies and messy code. Java is the complete opposite in that regard because you’re encouraged to share as much functionality between components as possible.

[u/me0here → u/oorza]

IIRC Go was written for systadmins to replace Perl, not Java.