Sharing types between React and a Typescript backend is great DX for developing both in parallel and I've not seen anything that comes close to being as enjoyable. Being able to change the signature of an API endpoint and immediately having all places in the codebase where the change will cause problems flagged as type errors is wonderful. I went back to working with duplicated types across python/typescript on a contract project recently and it took me 5x longer to fix the downstream implications of signature changes.
I'm quite dismayed to say that this has been a feature of any Java developer setup for the past 25 years. Yet hipsters threw it all in the garbage when node.js took off and are only now starting to approach feature parity with a 2002 JBuilder or Eclipse of the same era.
Can I tell you about live debugging of an app server and hot reloads? Pretty wonderful stuff really.
I can't believe how much knowledge, tooling and experience was thrown in the dumpster when Java was abandoned en masse by the younger generation of devs due to the rise of node.js. And if it weren't for Typescript the tooling would still likely suck.
What always strikes me about posts like this is the lack of introspection: why did younger developers reject Java?
It’s easy to say “because they’re hipsters following trends” but I dipped my toe in the Java world years ago and found it immensely frustrating. Eclipse was awful compared to the lightweight editors I was using at the time. The language got in my way more often than it helped me.
I’m sure that’s not the case these days (indeed I’ve done a little Android-adjacent stuff and found it to be fine) but the idea that there were no downsides to Java at the time strikes me as unlikely.
The design of Java is focused on code maintenance. That's exactly what young developers lack experience in. They know how to write greenfield code, by themselves. They haven't yet looked back at code they wrote and said, "ugh, what the hell was I thinking?"
Since Java was developed the world has shifted to accommodate a lot more rapid development and code you throw away rather than maintain. But experienced developers also know how often "prototypes" are still around decades later.
Java is also not perfect, and a lot of new languages are conscious of its faults. But the reason it's still around is that it's core principles are oriented to code that sticks around.
> But the reason it's still around is that it's core principles are oriented to code that sticks around.
You could equally say this of COBOL.
> They haven't yet looked back at code they wrote and said, "ugh, what the hell was I thinking?"
Ironically, "what they hell were they thinking" is exactly the reaction I have to even Greenfield code written using Spring Boot or any of the other annotation driven nonsense.
The idea that programs written in Java are more maintainable than programs written in (say) Go, where you can read what the program does end-to-end instead of having to guess at what garbage has been generated by Lombok or overridden by some random JAR on the class path is bizarre. Let's not even talk about Gradle.
Yeah, I'll defend Java, but I won't defend Spring. I have no idea what they were thinking.
A lot of external Java framework is about inversion of control. It looks good on PowerPoint slides, but I think it's horrific to maintain (as well has hard to write). Inversion of control means you have no control, and the most common error case is "why didn't my code run?" But you can't use a debugger to tell you what didn't happen. Any breakpoints have to be set inside the framework code, which is open source but is not intended for your eyes.
I have (in depth, often under the gun of a production outage).
Kubernetes is not a good example of idiomatic Go in any sense. Perhaps Spring Boot and friends are also not good examples of idiomatic Java, but they are absolutely the common case of what is found in the wild.
Kubernetes is a single (bad) Go project. Every piece of Java I ever see is AbstractFactoryProxyBean nonsense with annotations all over the show.
I don’t know of a Go project where I can’t start at main (for a given program) and work out how it works without a bunch of ecosystem context. I can’t think of a single Java program where I can.
I have experience with code maintenance. The only upside of Java is that it's faster than JS or Python. It's otherwise a worse language and ecosystem, and it was even worse before it had lambdas.
My problems with Java are startup time and memory consumption (and NPEs).
If that's not your problem - fine. But writing web apps in the Java ecosystem has been terrible for many of the most important years (let's say 2005 to 2015) and that's where all the "young people" forsake it for... PHP, Rails, node.js.
(You can already guess that I'm not even counting myself as part of the younger generation here. I'd used used Java and the JVM intermittently between 2000 and 2020 but it has never been my favourite stack).
Java was so bad that Android took a hard pivot to Kotlin. If anyone understands the importance of code maintenance, it's Google. They built a language for it (Go). I think it's ok to look at historical Java for what it is and learn from it's mistakes. Modern Java is better. Unfortunately, it's developed a bad rap, and it looks like it's in a decline. Fortunately we have Kotlin, Go, Typescript, etc.
Exactly! I got my first job in Java after a few years as hobbyist programmer in other languages (mostly PHP and JavaScript but a few others too) and what struck me was that the tooling was both mandatory and painful to use.
I wasn't fond of JavaScript (In particular, I never liked dynamic typing), but when I had the opportunity to work in node.js instead of Java I took it immediately, just to avoid the pain and suffering that the Java toolchain inflicted on me.
Java is a language of bondage and discpline. And architectures. And myriad pointless interface definitions. And overblown class hierarchies for problems ill-suited to the OO paradigm.
I started my career in Java, and worked in it for 20 years before I really started using Javascript in anger. I didn't (and don't) like Javascript, but the freedom for prototyping was a revelation. When Typescript appeared, I fell in love.
It had a steeper learning curve than other languages or environments but that was for a reason. You got a lot in return. And those lightweight editors and environments are like that because they don't do very much.
And talk not to me about lightweight. I'm currently on Day 4 of setting up a Python environment in VsCode that doesn't suck. I'm nearly there though it's still a bit inferior to a 20 year old JBuilder install for Java but I guess it needs a few more years to get there. Oh and as I said, I'm on a long quest here to pave the road for my devs but it looks like this hodgepodge of extensions still won't deliver the experience I had decades ago.
Isn't using VsCode for a non-Microsoft language going to be difficult, by (MS's) design? I'm not saying it can't/hasn't be/been done, but I doubt MS are making it easier to do so. It's been their m.o. for a long time now.
I'm also not saying there's a better option for you and your team, either, my friend.
As a python programmer using bare-bones vim (on purpose), having abandoned all fancy IDEs, I really wouldn't know where the state of the art is, anyway, but I doubt the MS leopard has changed its spots.
Isn't using VsCode for a non-Microsoft language going to be difficult
Python is pretty close to a 'Microsoft language' these days. They've hired several Python core developers to make sure windows is first class citizen for python and the developing python on windows and with VSCode is as good an experience as possible. They also develop the official VS Code Python extension and language server as well as many other python tools and extensions.
I'd say the current state-of-the-art is either VSCode with the Microsoft python extensions or Jetbrain's PyCharm. Personally I slightly prefer PyCharm Pro, but it's pretty much a toss up.
Yup. As an older programmer I can say that there were indeed very good reasons back then to stop using Java. Mostly related to JVM but also the language lacked lots of features.
But the comment you're replying to doesn't say Java doesn't have any downsides. It just says that Java has a great story for doing shared types between client and server, which is true. It's also true that Java as a language has gotten a lot better over time. This is I think thanks to pressure from other languages written for the jvm like kotlin, And also developer feedback for those who work in other languages like JavaScript. Java is old and boring. Just like go is new and boring. Rust has plenty of downsides this idea that it's easy to use. Seems wrong to me. The borrow checker is famously difficult to work with despite being a central feature of the language. The really big upside to JavaScript is that it's the native language of browsers and so in a weird way. If you want to get closest to the metal so to speak, JavaScript is a better option for most deployed applications. It's interesting to note that the op's article mostly points to build tools that are written in rust rather than applications and I think that's telling.
> But the comment you're replying to doesn't say Java doesn't have any downsides
Yet it blames "hipsters" for throwing "it all in the garbage," implying that there was no rational reason for people to switch away from Java. Naturally, people respond by sharing their reasons.
At least from an Android point of view, the JVM world still has its share of frustrations and lack of polish/QoL relative to other software development spheres. Gradle has me pulling my hair out multiple times each year for example, and yet for some reason nobody sees it fit to replace it with something less ridiculously complex and prone to error (user or otherwise).
Don't blame Java for the misteps of Google and Android team.
Android started being devleoped mostly by C++ refugees, that is why originally all framework code is full of m_ prefixes.
Then the whole standard library fragmentation that persists to this day.
Despite the whole excuse why Dalvik was created, Nokia and Sony-Ericson had quite good JVM implentations for Symbian.
When Kotlin was introduced they stiffled Java on purpose, left it on Java 8, using Java 8 examples to promote Kotlin, and have since Android 12, started to finally update ART to more modern versions, because as it turns out, even with Kotlin, loosing compatibility with the Maven Central ecossytem isn't that great.
Still, it is mostly Java 17, and all the ongoing improvement in Java land across all JVM vendors, will most likely never land on Android.
Android is not Java, even though it relies heavily on the ecosystem for its tooling.
Android is basically Google's .NET, and Kotlin plays the same role as C# in relation to Microsoft's J++, that lead to Sun's lawsuit.
Jetbrains have a project to try and replace Gradle.
I've looked at it also. The problem is incentives. Will developers pay for a better build system? Probably not. Then, what people use is whatever happened to be given away for free first.
Another problem with shifting Gradle is that lots of libraries now come with build system plugins too, so you'd need to replicate all that logic into whatever new build system you create. And it's actually not easy to get everyone to agree on what they don't like about Gradle. Say "imperative not declarative" and half of devs will agree and the other half will say, no, you need programmatic configuration because build systems are genuinely complex. Etc.
I've long since given up on Gradle being able to get this stuff right. The syntax they're proposing is the THIRD similar-but-incompatible syntax they've adopted after Groovy and Kotlin. Good luck figuring out which is in use by looking at a code sample.
The biggest problem with Gradle is not Kotlin or even Groovy syntax. Kotlin isn't a bad language to use even for writing configuration. It's that the entire thing is designed in extremely confusing ways from back to front, and has a lot of awkward design choices and bugs that result in a hyper-complex user model.
What the JVM world needs is a totally new tool that has the same feature set as Gradle but with a drastically simpler mental model behind it. The only real contender right now is Bazel, I think.
Yeah, gradle/maven was a mistake that happened along with most "app store" style 3d party library slingers.
I'm of the opinion that the world was a better place with Ant and when we had third party dependencies manually, deliberately adn deliberatively managed by hand in /jars/thirdparty
Speaking as a younger developer at the time, Java just seemed weak compared to my favorites -- Common Lisp and Scheme. It lacked a proper procedural abstraction and forced you to do everything through classes and objects in a way that not even Smalltalk, having blocks, demanded. This was especially the case when it became an enterprise language and the standard development process involved lots of boilerplate. Also, a lot of kids came out of school knowing almost only Java, and it seems they were cut off from different worlds of development which could provide some insights. Even C++, which I loathed, had things to teach.
I've grown up a bit since then, and so has Java. These days I work in Java for my day job, and it's perfectly fine. I don't even mind all the boilerplate, I can look at a page of code and just see blonde, brunette, redhead.
But I still love Common Lisp and Scheme much more.
In my experience, young people who hated java never worked in java and knew nothing about it except that it is evil.
The second thing however is that fronted is better off in non-java languages, you can afford to do small backend in typescript and what not. And larger enterprise projects were done in java the whole time.
> The language got in my way more often than it helped me
Got in the way how?
By insisting that things have types and one cannot blindly add an object to an array [] + {} and expect it to behave?
Never mind that in Javascript adding an array to an object {} + [] gives a different result.
Java is verbose, is a resource hog, requires runtime management for basic app performance, the major frameworks (used to) require an awful lot of boiler plate, the developer tooling almost necessitates an IDE which 10-15 years ago meant eclipse which was slow, bloated, and unstable. There’s also always been licensing “fun” with oracle, sun, and the jdk.
What are you talking about, seriously. 10-15 years ago, eclipse was neither slow nor unstable. It worked perfectly well. IntelliJ was not slow or unstable. There were not real major licensing issues.
As a newcommer to javascript, I was able to learn faster and produce same quality faster then non-IDE developers. Not because I would be smarter or more talented, but because I had no emotional need to prove myself by not using ide.
Eclipse was _the_ tool when I was working with Java at the time. Slow and unstable is definitely my lasting memory, compared to virtual studio 2008/2010 which was fast and powerful.
> there were not real licensing issues
Oh yes there were. Even in 2024 the “which JDK are you running on” debate still goes on. There are notable differences between corretto and openjdk, and openjdk and Oracle JDK. Here [0] is a stack overflow question that notes it was asked 10 years ago that talks about the various JDKs and the license change where oracle started charging for JDK access.
As for your point about IDE’s vs non-IDE’s that’s a straw man. I said that you were forced to used an IDE for Java (which is of course not technically true but compared to rails which took of at that time it is), but also that the IDE du jour (eclipse) was pretty monstrous.
I’ve said this on here before but the minute maven gets introduced into a project build times are measured in minutes. My current work project is c# and I can run my entire test suite faster than the jvm got itself up and running on my last kotlin project. Even IntelliJ and co suffer from these limitations - manually bumping the memory limits for IntelliJ and friends in 2024 is practically a requirement, and the startup times are very Java inspired.
If you mean visual studio for dotnet and it is comparably piece of crap. A lot of unexplained behavior and it generally feels like someone just wanted to check boxes. Dotnet and visual studio actually made me love love a lot more after I worked with them.
Java and Eclipse are waaay better then C# and visual studio. Kotlin is a pure pleasure against C#.
Also, I see people using different JDKa on the same project. That there is competition is a good thing, it is not like you was locked in one.
> If you mean visual studio for dotnet and it is comparably piece of crap. A lot of unexplained behavior and it generally feels like someone just wanted to check boxes.
I disagree. dotnet has it's quirks, but so does every mature ecosystem. I wouldn't use "piece of crap" to describe it (or java) and I get that it's an opinion, but I think your opinion is more misguided than what yo're accusing other people of believing.
> Kotlin is a pure pleasure against C#.
My last project was a kotlin backend powering a C+ desktop app. The kotlin backend took longer to compile than the C++ did. Kotlin is the kitchen sink bolted onto Java. It's definitely a nice environment to work in, but it's certainly not a more streamlined java.
> That there is competition is a good thing, it is not like you was locked in one.
If by competition you mean OpenJDK forks with minor differences then yes there's competition. To me that's not competition, that's fragmentation.
> Java and Eclipse are waaay better then C# and visual studio. Kotlin is a pure pleasure against C#.
Except, unlike Kotlin, C# has a rich selection of what to use for development across a variety of platforms and is not constrained to JVM's type system limitations, allowing the syntax differences to have meaningful impact on the code execution.
It also has excellent, comparable to Go and Rust, CLI tooling to further streamline the process of quickly managing, building, testing, running and deploying projects, something JVM ecosystem is yet to provide an alternative for.
15 years ago, it took a full 10 minutes to launch IDEA or Eclipse and have it finish opening a large (100kloc+) java project on a brand-new high-end MacBook Pro.
3-10 crashes per day were common.
Lots or coffee breaks, or at least switching back to emacs to just finish editing whatever classes you were touching.
It's probably unavoidable that people's memories will differ, but personally, as someone who worked with Java 10–15 years ago and then ran away as fast as he could, these are the things I remember most: the IDEs being awfully slow and unstable (though quite powerful for their time) and the language/ecosystem being painfully verbose and full of boilerplate and layers of indirection. I remember how, after switching away from Java, I felt elated by how easy and maintainable things could be when I was allowed to use simple, fast tools and write straightforward code that just did what it was supposed to do.
I won't apologize for rebelling against Eclipse, SOAP, XML and AbstractBeanFactories. Java the language is pretty cool and very powerful, it's the ecosystem that was turning people off.
I hear Java has gotten a lot better. But then again there is C#, which is pretty much just better Java. Still too enterprisy for the tastes of most HN types though
> I'm quite dismayed to say that this has been a feature of any Java developer setup for the past 25 years. Yet hipsters threw it all in the garbage when node.js took off and are only now starting to approach feature parity with a 2002 JBuilder or Eclipse of the same era.
Last I checked If I change a signature or something in Java, I am not guaranteed the whole thing "checks". If I add a new exception to a function, how do I know what else is effected?
Java checked exceptions are (were?) a wonderful feature that was wrongly dissed for the same reason Java types and IDEs were dissed. It forced people to handle exceptions or pass them up the call stack but they had to be dealt with. And IDEs were aware of them so not catching or rethrowing was immediately flagged by the IDE.
I give it five years until Typescript and peers adds checked exceptions.
It's pretty interesting that people think Java was abandoned because of other languages, and not because of the problems of Java itself - or indeed that features like hot reloading and live debugging are niche or unique to Java.
.NET has also had all these features for just as long, and is less prone (though definitely not immune) to AbstractFactoryProxyBean nonsense.
Java was abandoned en masse by the younger generation
We tried. Java was fine, JBuilder was fine. When they instead started pushing J2EE, EJB and all the other acronyms I've forgotten, this 'youngster' realised he'd never be smart enough to be a Java developer and bailed back to C, Perl and Python.
Had they focused on Java and making Java a great language in its own right, it no doubt would have gone a lot better. But all the 'hype' and marketing around Java was focused entirely on these huge frameworks and enterprise 'solution' architectures which most 'youngsters' just didn't understand and didn't see the need for.
If someone makes it clear their product isn't for you and that they don't care about solving your problems, is it strange they abandon you?
JavaScript is an awful language. Doesn’t mean Java is the answer. There are other languages—Go, Rust, Python, C# that offer better protection without sacrificing ergonomics.,
> feature of any Java developer setup for the past 25 years
do you mean rmi/javabeans or something else ?
beside that, I left java long ago, and believed in simpler REST stuff but now I realize that it's indeed rediscovering stuff people dealt with long ago
Java beans was just convention. Enterprise Java Beans was a mistake which probably contributed to Java's bad rap for a while. But you could use an app server without EJB just fine. I did for years and never had problems.
As for rmi, when Java was in its heyday the most popular protocol for remote api handling was SOAP. But when RESTful era arrived Java tooling adapted very quickly and it made little difference what you were using to call outside the app server.
JavaBeans and EJB became things because Microsoft was eating everyone's lunch with their component paradigm, COM, on the client side and were making inroads into server-side enterprise computing as well. With COM, you could write components that just plugged right in to an application, in any language. Java, despite being ostensibly object-oriented all the way down, didn't have an answer for this until JavaBeans emerged and then EJB for the server side. You have to remember that Microsoft had a relentless focus on developers building stuff on top of their platform. That image of Steve Ballmer sweating like a mule and chanting "Developers! Developers! Developers!" wasn't just a meme, it was an indicator of the entire company's direction. Nobody could match them at the time. From Internet Explorer to Visual Studio, 70%-80% of Microsoft's monopoly was built in simply outcompeting everyone else. If people were locked into Windows, it was because it just made sense from a business standpoint.
But yeah, I built business apps with just Tomcat and no J2EE components and it was fine.
and call its methods. It will use the annotations to validate the call client side before sending it, and you can implement the same interface on the server:
@Controller("/pets")
public class PetController implements PetOperations {
@Override
@SingleResult
public Publisher<Pet> save(String name, int age) {
Pet pet = new Pet();
pet.setName(name);
pet.setAge(age);
// save to database or something
return Mono.just(pet);
}
}
where the same validations will occur before the call is accepted.
> Don't worry, the Typescript ecosystem is fast becoming Java.
Typescript is somehow becoming a laguage that supports writing extremely performant high throughput and very scalable server code? That seems unlikely. So no worries, it can't become Java.
> Java, as a language is fine I guess, but the culture around it sucks.
Culture is what you want it to be.
There are indeed some ridiculous subcultures within the world of developers who use Java. Like J2EE-anything or any of the baroque frameworks.
It is important to realize none of that is part of Java and none of that is required unless you really want to.
You can use Java simply as a memory safe language with reasonably good type safety that can create wicked fast code and has huge library and tooling support. On all those checkboxes, there are few-to-none options that are so good across all those aspects at once.
Unfortunately so many people just complain about writing TaskStubConsumerWatcherVisitorServiceContainerListIdentifier classes, without realizing nobody is forcing you to do that. So don't.
You mean capable of stable firehose throughput, similar to Go? State of the art GC research on state of the art VM? I wouldn't be surprised if Java had more money behind it than JS on the R&D & corporate backing side.
GWT was an attempt to let you live in java land and also still get the (tremendous) benefits of deploying to the browser Javascript VM. We used it on a java backed project, but we were not building an SPA so didn't see all the benefits.
It still blows me away that we settled on JavaScript as a VM. It wasn't designed for that, and it took a superhuman effort to make it work well enough.
I feel like there's an adjacent universe where the JVM lives in every browser and JS was a weird failed experiment. But it turned out that the browser was the universal UI everyone had waited for, and Java didn't connect to it while JS entrenched itself there.
GWT was a glimpse of trying to send us to that universe, via a twisty back door. But it was never gonna happen.
You can thank Sun Microsystems for this. They had the world in the palm of their hand with HotJava, but decided to abandon it. If they had continued, Java would been the language of choice for the web and they likely wouldn't have been acquired by Oracle.
HotJava, IIRC, was more focused on Swing apps. Swing just wasn't the right thing for users; the HTML DOM turns out to be more comfortable. Even though it means sometimes failing out to the Canvas, which gives you nothing.
NB: I was very distantly part of the Swing team. I did early reviews of its design documents.
Considering we have full replacement frameworks like React, Flutter, etc built as DOM replacements, I would say Swing was definitely the right thing for users. Probably could have offered an "easy markup enhancement" library for plain documents, but anything extensively dynamic should be written with a proper UI framework.
It's a hard sell for the majority of users and the mainstream market at the time. Flash apps had cute, lazy loaded, ~lightweight, animated mini apps. Anything java at the time was heavy, enterprisey, requiring more setup to get blocky GUIs that didn't do much.
I wish to live in that universe, and hope that WASM will bring it closer to us. Clearly, Javascript gets compiled to some intermediate representation, that then gets JITed/interpreted and then interacts with the native browser API.
I wish us devs would have access to that intermediate representation.
the client side java didn't last long, flash and js were more mechanically sympathetic on too many aspects (dev culture, user expectation about load time, cute visuals)
That's cool but I get a chuckle when I see server side html rendering being all the rage now and thinking to myself, should I tell the juniors about servlets, JSP and Struts?
No chance, relatively few software companies ever adopted Rails but a huge number went from Java or .NET -> JS/TS. The draw of cross project code reuse and having teams only needing to know a single language remains compelling.
Java was largely already being abandoned before NodeJS existed. A huge percentage of the web 2.0 companies were built on Rails. Twitter, Github, Shopify, AirBnB, Groupon, SoundCloud, Instacart were all built on Rails. It maybe flew beneath your radar but it was a phenomenon at the time, way before Node.js even existed.
Those examples aren't representative of the broader industry though. There are far more devs working at former Java and .NET shops that have never written a single line of Ruby and are all in on JS/TS now
What you are saying is hyperbole. They are "All" in JS/TS now? I never said JS wasn't bigger than Rails, but Rails was the first and biggest axe to fall against Java. JS just took the baton from them
Java took a ton of heat in 2005-2009 (before Node existed) because Rails came through and was eating it's lunch. It's the reason that a huge percentage of the successful Web 2.0 companies were built using Rails, not Java or .NET.
As someone who did Java WebApps for 10 years - they sucked if you cared about making a good user interface.
I thought JS was bad at the time, but node.js was a breath of fresh air for API development, and client side JS has been fine for like 10 years (assuming you care about UI development).
I'd never go back to Java except for maybe some backend service away from the UI.
At Oxide we use OpenAPI schemas generated from the server code to generate clients and it works quite well to produce the DX you describe despite different languages on server and client. OpenAPI has its frustrations, but it’s good enough.
I like to say that the main value of GraphQL was never really in the dynamic queries (in many ways an anti-feature) but rather in having a nice typed spec that lets you generate typed clients.
This is where OpenAPI/Swagger shines, we use C# backends and with NSwag (built in now also I think) you get an online API-spec directly from the controller (and types) of the C# code.
Only extra step is running a tool to download the swagger and produce auto-generated typescript definitions, otherwise the workflow is the same as shared code (Some projects are typescript on both ends but C# gives a ton of other benefits for backends).
My recent experience with NSwag was really bad... It could only handle the simplest of jsonschema. We were trying to connect with a typescript API that had heavy use of union and product types. Maybe the problem was just that C# doesn't support algebraic typings?
Yeah, the C++/Java/C# family of type systems have obvious holes in them. There are various hacks/implementations for them but since they're not in the core they're not really expected to be supported by random tools either.
Like mentioned, our regular pipe is C# producer (server) and TS consumer (client). Consuming services authored in Java,etc is usually not a problem either but the TS system definetly has a bunch of more cases that aren't easily mapped.
This is what we do. We use kiota to generate clients within other C# services, and orval to generate a client in the frontend. We also run some basic checks against the openapi definition in branch, to detect breaking changes and whatnot.
This is the nice if your only consumption of the frontend is first party.
Alternatively you could go the openAPI route and declare your API as a spec with types for a client to consume and the endpoint to return. This works cross-language and gives you docs first. (Start from the docs, convert that to types, then implement).
I just wish YAML wasn’t so unwieldy for that, especially given the overall complexity of the spec.
I also thing that the tooling hasn’t kept the same pace as it has with graphql, where it’s easy to document your schema and the inspector makes it super easy to play with.
You can write OpenAPI in JSON, which can help a bit with encompassing the complex and frankly fractured ecosystem of OpenAPI.
I have found that the tooling tends to have the problem of not knowing how to catch edge cases like webhooks, websockets, complex auth and additional logic beyond just an HTTP request. Many tools add layers of configuration and extension to work around these, but i feel it misses the mark.
I'm building Borea.dev to solve this pain by keeping the source of truth in your OpenAPI doc and allowing for custom code implementations. We support Python rn, are building out generators for multiple other languages and we're open source :P hope it helps
Typescript and Rust may be more similar in this regard than you think. Both languages are born out of the desire to make coding simpler by making a stronger, more expressive type system. Sure, the details differ: Rust has lifetimes and about 8 number types, Typescript is garbage collected and has about one number type. But the spirit is similar. Both the typescript ecosystem and the rust ecosystem love the idea of taking types and function signatures and providing them for downstream consumers.
While I haven't gone too deep down this particular rabbit hole, if you build a Rust backend you can use function signatures and annotations to automatically build an OpenAPI specification for it. You can then consume that specification to automatically build a typescript client library, giving you an automatically updating Typescript interface to your Rust backend.
Similarly, there are multiple projects to automatically provide python type hints for your Rust python extensions. None of them really production-ready yet, but this is something people are actively working on for quite a while
THis is very similar to what Oxide.computer has done. They wrote their own tooling to go from Rust API to spec to Rust and TS client. Very specific to their use case, but I think its the right approach. If something is wrong in the client, you probably generated a bad spec, and therefore something in the API is rotten and should be adjusted. Using the spec as an intermediate to know if upstream is bad, can be a great benchmark for developers.
My co-founder and i have a long term goal of building an end to end tooling chain for OpenAPI to generate spec and clients/tests/docs under one roof. Its definitely far off in development, but think its where devs are moving
I thought the same but recently we started using .net on backend and openapi to generate typed api clients for typescript. I mean the initial setup was 15 minutes longer than a full stack typescript app but I get to use .net on the backend and all the type safety on both sides.
> Sharing types between React and a Typescript backend is great DX for developing both in parallel and I've not seen anything that comes close to being as enjoyable. Being able to change the signature of an API endpoint and immediately having all places in the codebase where the change will cause problems flagged as type errors is wonderful.
Have you ever seen Scala.js? Same language on the frontend and backend, in a way that actually feels first-class and real. Type system that's as powerful as Typescript but also sound. Full IDE functionality if you need it.
Maybe that’s because you only know one language and focused on using that everywhere.
I have worked at 2 of those named companies where people made conscious decisions of moving away from TS backend because JS is an awful language to be used for system critical things.
JavaScript, in general, is awful as a language in terms of design, and more astute people have wasted many words on this before me.
It was originally designed for writing throwaway frontend code, but people liked it so much that they started using it to build their system architecture—only to realize it doesn’t work well for anything beyond glorified RPC backends.
The type system is wishy-washy, and TypeScript needs a massive type space to compensate for it. Python is also dynamically typed, but it has a strongly typed system that saves you from runtime blowups. JavaScript doesn’t even properly blow up at runtime—you just get [object Object] or some random undefined error. TypeScript is a fantastic piece of engineering from the C# guy, but even they couldn’t fix all of JavaScript’s language-level blunders.
Few people want to build mission-critical backends on a weakly typed language.
The ecosystem is a mess, and things randomly break after a few days. My Python and Go apps from 2018 still work exactly as they did on day one. Go’s gorm and Python’s SQLAlchemy are the default ORMs that pretty much everyone uses. And how many ORMs does the JS ecosystem have?
And let’s not even start with frontend frameworks—no one loves them two days later.
The Next.js project I built yesterday is already showing 69 vulnerabilities. This sorry excuse of a language, coupled with terrible design and an indecisively childish community, makes it difficult to take seriously.
You're throwing random things but you have failed to explain real world pains.
By the way you can be extremely strict and safe in typescript, it's really up to the team using it, but you can encode virtually everything and have it fully type safe.
Also, there's great tools like effect-ts if you're more functionally leaning.
If you really want to waste time on types, the bolted-on TS is never going to work as well as Golang where they're native. Maybe TS types are better than Python types is all.
To be honest, I don't like the look of Effect for the same reason I don't like error handling in Golang. It's easier to assume anything can fail (which is 99% correct) and use exceptions. But anyway, every language can be extended in many ways, so I can really only compare default vs default.
In common JS or Py use cases, static typing makes your code less safe, because all that extra time you spend on it is less time writing tests. Meanwhile the types won't catch any bugs even the most simple test coverage would.
Sure, JS has some quirks that language design gurus complain about, but nothing that actually matters on the job. Like, == operator is weird, oh well.
Python is rightfully king for certain things like data science, but parallelism and package management are two big messes in it. ||ism is trying to be fixed with asyncio, but it's kinda too late. You know packaging is broken because every Python repo has a Dockerfile, not something you see in JS where npm is solid.
Golang is more for different use cases. Looks good but really should have done error handling like Rust, or used exceptions.
My point is that the JS ecosystem is masqueraded by script kiddies who will throw a hissy fit every time someone criticizes JS, and you just proved that ;)
This is an embarrassing comment, there are few things this world needs less than more smug engineering tribalism. Even weakly typed languages. Typescript has many downsides, as does Python, and if you think the downsides of Python are trivial then I would invite you to take a look at the sea of different competing tools for environment management. I need a python env, now will that be with pyenv or venv or pipenv or pyvenv or virtualenv or poetry?
I’ve been writing JS and then TS on the backend since 2013. Built large apps, startups and while it does the job fine I’d not go with Js on the backend anymore.
We built some stuff with Go and then went with full .Net. Its like fresh air after years of Js.
- Proper static typing. This is not .net specific but bolting types on a dynamicly typed language only works to some degree. It also opens the gate to runtime type intospection such as generating OpenAPI definitions without any other input than the handler signatures themselves etc. This is handled fine by a full stack ts framework like next or nuxt and such but you are still trapped in that implementation.
- Proper multithreading and performance story. Performance itself is not the most important thing when your app mostly waits on IO. However you still get to use thread pooled async in .net or parallel goroutines in go etc and they sometimes make a difference.
- ASP.NET Core is fully feature packed and easy to work with. .net has a more cohesive ecosystem where tools, libraries, and frameworks are designed to work together seamlessly. In js runtimes, you often need to piece together different approaches and deal with compatibility issues.
- Proper standard library. Both node.js stdlib and the js globals are really weak compared to what Go or .NET or Java etc provides you out of the box. I hate dealing with npm dependencies with a passion at this point and you can have minimal dependencies when the standard library is decent. There is also the fact that upgrading an npm package is a dice roll as you need to trust the semver or check update logs etc. At least with a static typed language you get to catch public api changes on your dependencies during compile time, not in runtime.
- Linq is good, Linq expressions are great. I don't really love ORMs but I tend to use Entity Framework Core on top of low level SQL access in .NET. Makes life easier.
I don't hate TypeScript though. I still use it on the frontend obviously and I'm fine with it but given the choices on backend, it does not make much sense for me anymore.
I know about 10 languages by now, and JS is one of the later ones I learned. Nah, it's the best at what it does. And if I drew a graph of every project that's moved from language A to B, it would have cycles.
There are legions of languages that can be transpiled into JS. Use any of them both for back and front-end and suddenly, not only can you use the same types but also the same functions.
This is where Rust shines, CLI tools where a ton of processing needs to happen and execution time is extremely important. For almost every other problem, the amount of computation is much lower and/or the execution time isn't as important.
Indeed, no sane JS dev would jump to Rust bandwagon, even if he’s very fond of TS.
Besides Bun is not Rust even though Deno and some tools are. The JS crowd generally does not care about coding Rust, though would welcome faster tools which are sometimes rust based. Also Go based and even Zig based.
Additionally if one cares about performance, I would much rather write C++ than Rust, as that is directly supported by V8 tooling, without adding even more additional layers to debug.
I think the future of JS is going to be a lot like Python - you write your code with JS libraries because of the ergonomics, but critical pieces of those libraries are implemented in WASM under the hood.
For example, you’ll still write your React components, but the React framework itself might be written in Rust and compiled down to WASM to make everything snappier (e.g. DOM diffing).
I personally really love this pattern because it strikes a balance between speed and DX. Not everything has to maximize performance, and not everything has to maximize productivity.
Like libsodium.js and pqcrypto.js. They're distributed as single self-contained JavaScript files, but under the hood have wasm embedded using the emscripten SINGLE_FILE flag with an asm.js fallback.
Tbh I would much rather write utilities in Go. The advantages of Rust are minimal here and the disadvantages are an obstacle. Last time I wrote a CLI in Rust it was a search index builder you could pipe CSV to. Awful DX. Go is almost too easy for that kind of thing.
If anything I’ve actually seen people using the OS’s virtual memory as a garbage collector in C and C++. Not really portable everywhere, but close enough for most people. For short-lived executables that can’t really allocate unlimited memory, it’s perfectly fine.
It's true, but the absence of adoption of these great tools in industry worries me. Most Python developers in industry don't seem to care one iota about handling corner cases of types, and so their code is full of problems. Most Python developers in industry are very untrained, and have no discipline when it comes to types. It makes me sad while working in such a setting.
mypy and pyright have been out for so long, and they're in a pretty usable state. Ignoring to use them leads to buggy code that shows its ugly head as unhandled rare conditions begin to manifest themselves. The compounding effects of these unhandled rare conditions ultimately ends the project when the lead subject matter expert exits the team.
A large amount of important Python libraries are still missing a good amount of typing - and dealing with third party typesheds is not a good developer experience. The implementation of types in cpython has also been glacially slow and fragmented.
To add to the issue, a huge amount of Python in public repositories is untyped and unversioned- which means that LLMs are pretty bad at getting typing correcting in Python, so the debt is growing much faster than the solutions.
I honestly think that the most viable solution at this point for typing is a typescript-adjacent solution for Python. I’m kind of surprised Microsoft hasn’t put one out yet
Speed and types are different topics. Types are valued by mature programmers who recognize that maintainable and comprehensible projects require aggressive use of types. Short-term thinkers will not value types, and will lead to rapidly decaying and eventually unmaintainable dead projects.
I think what will happen is something like numba gets more use. Bad developers can keep writing as they do, but critical infrastructures and functions will be written in natively compiled numba/python code.
I don't think I could agree less. Numba has always had too many errors, bugs, and too inconsistent of a performance gain. Moreover, Python has always been a glue language where numerous packages interact together to form functionality, and this glue usage makes no sense with Numba.
LOL, no. Rust is not eating javascript but COMPILED languges are, and only in the build pipeline. Rust does not matter, even Go is far more superior than anything in JS land.
Eg. My webpack builds in 35 seconds. The i try esbuild and it does the same job in 35ms. Insane! Ok now lets try rust, now i get 20ms. Wow!
Do i care about 35ms -> 20ms? Nope, not one bit. I just want it to compile under 1second.
Rust lacks major financial backers for the tooling ecosystem. This leads to a huge number of ambitious projects which are abandoned when folks get bored.
A single startup with fickle founders/investors is not a reliable source of funding.
C/C++ developed thanks to the effort of hardware, kernel, and os makers who invested billions into its development. Development of the JVM once occupied the effort of 10k engineers at SUN. JavaScript has a complex history, but has received significant investment from Netscape, Mozilla, Facebook, Google, and Microsoft.
Rust needs one or two singular players with 5+ billion to spend supporting and improving devs lives. The nascent efforts I’ve seen so far are just that - nascent.
I don’t want to actually get into a “which is more” argument because I think historically in total you are correct, but Mozilla, Facebook, Google, and Microsoft are some of the largest financial backers of Rust.
Yes :) however Mozilla is in a mixed state today, FB/Google/MSFT are interested in Rust to modernize legacy code bases - but I don't see the same kind of Rust artifacts coming out of these firms as they produced for JS (React), or Java (Guice). Perhaps they are still tinkering on this point, but something doesn't add up.
Yeah it’s just early and different; Google gave the foundation a million dollars to work on rust <-> c++ interoperability last year, but that work is still ongoing. They do put out projects but they’re not as dominant in the ecosystem as React became in JS, for sure.
God this comment thread is a series of unsubstantiated subjective opinions trashing languages that people don’t like and ignoring the faults of the languages they do….
Why must we rehash this type of post every few months?
See the problem to me is that this comparison isn't nice. Javascript comes with a lot of its problems , so of course people would want go / C / rust
but Now the author thus concluding that people want "the fastest" out of go/C/rust is just wrong.
I love golang.
People like fast software but hate abandoned software even more . Yes there are rustaceans who would love the project but now hand anybody genuinely interested to contribute a rust project and ask them to learn rust and they would come hating at you.
And now ask them to learn go. They can actually much easily do that.
I stand with this opinion that go code can be read / written by anybody. There is very rare bad go code but rust code feels "magic" to people.
Admire simplicity. That being said , I use archlinux with paru instead of yay , I use a lot of rust tools as well.
To be honest , to me it doesn't matter that much , what matters is if its being maintained stable / has active community. It could be written in any language just make it easy to embed / provide bindings for major languages like python node golang etc.
Or though this might come overkill but I wish if there was some sort of glue code which can bridge languages , most of these glue code libraries end up having so many use cases. so I like the idea of wasm but its just not that performant. If we can have insanely performant wasm ...
I learned golang and rust, and I can say that both have significantly different concepts from other "conventional" OOP languages that it's not just learn new syntax approach.
it's of course very subjective, but for me golang feels more magic, especially with importing GitHub repositories like local files.
The easiest language is of course the one you already know.
i would also argue that it's easier to write bad go code (I personally wrote some of it while learning) in rust usually if it compile and your are not using unsafe, it's at least ok quality and clippy is great with guiding you how to improve your code.
to be fair JavaScript also is weird and different than OOP languages but from some time it tries to feel more traditional with classes and this handling.
wasm is already fairly performant in comparison to native code, it might lack in come cases like simd (there are extensions already, but I'm not sure about adoption) but generally it's only about 20% slower than native binary.
I'm not sure how much wasi is practical for cli tools, but using was for plugins to allow any language someone might be comfortable with seems like no-brainer to me (also isolation will allow you to control potential memory leaks and crashes so your application will not get corrupted or anonymously destabilised)
That would be nice. Instead we’re seeing all these JS/Python tools written in Rust - a complex language whose complexity comes providing memory safety without garbage collection.
Their authors are deliberately choosing to take on that complexity for programs where it’s unnecessary - programs which would work equally well with a GC.
The overwhelming majority of Rust borrowing complexity can be trivially solved by just doing .clone() which is basically all those GC languages like Go and Python are doing themselves anyway. You can avoid the borrow checker altogether if you want to, and a lot of people do. It will still be much faster than go or python just due to the lack of runtime overhead and GC
The reason Rust and Go tooling is getting popular is because they are appropriate for the job.
C and C++ are riddled with footguns and non-ideal for this kind of tooling, Ruby and Python provide only disadvantages compared to current JS tools, Haskell and OCaml are good but too niche. And so on.
And the reason Rust and Go are getting usage in WASM is because they have a good WASM story. They are static, compiled and born at the right time. Other than C and C++, they're the only ones that put the effort.
The reason people are making projects in Rust and Go is because they are accessible to those people. For me both hit a sweet spot that none of the languages above do.
C++ was also very popular and fashionable at some point. It also promised better type safety and better memory management than C. Now, 20 years later, it's easy see that C++ didn't deliver on all of its promises about better abstractions and object oriented productivity gains. RAII promised to make race conditions, memory leaks, and use-after-free bugs a thing of the past. The C++ hype was relentless and a very loud minority argued every C project should really adopt C++. Thankfully, a handful of grouchy naysayers stuck with C.
Fashion and hype has always played a big role in software and our industry has at times unwisely abandoned good technology in favor of the 'New hotness'. We gyrate between local apps and cloud apps, thin and thick clients, static and dynamic typing, micro-services and monoliths, relational databases and keyval stores. Our industry is not very rational and the best tools don't always win. Marketing and market effects (winners keep winning) play a big role.
Recognizing the role hype plays in our industry is not myopia.
I would not take the time to add my little voice to the ones that express their exasperation with rust, if not for the scornfull tone of your message.
We all know that rust has a lot of merits, in that it is trying to establish a different, ambitious new trade off wrt. safety ganranties vs expressive power, and as a result is one a the few serious contender to replace C++ in the very areas where C++ is king, trading just a bit of performance for a vastly more sane language and better static garanties.
But it is also fair to acknowledge that more often than not, in the many "old_thing but in rust" that are being posted on HN, the old_thing at hand does not actually fall in that very important but also very small subset of programs that can not tolerate automatic memory management.
In other words, rust was not the good choice from a technical stand point.
Maybe it's particularly obvious to me because I have tried to promote rust before it became cool? At that time my coleagues could only tolerate Python or Go. These days the same people probably program in rust (or are at least considering it), and that's not because rust improved that much, or because they have sudenly learned to use the right tool for the job.
I will keep calling this attitude negative and disrespectful, because it's belittling other people's work, curiosity and experimentation.
A lot of the things being posted in HN are not products but rather small-to-mid-size programs written by (quite often) experienced developers trying out a new language and somehow managing to scratch theirs or someone else's itch. On top of that, they are learning and we as a community are also learning from their hits and their misses.
A lot of things, such as WASM frameworks, are heavily experimental, and in this very thread there is an example of an author of those saying they're back to working JS. This is fine.
I would be totally fine with comments like "Rust is not good for this" or "Go is not good for that", and I have given some examples myself above. But this is clearly not what's happening here. It's ok to not want to participate on something, but the vitriol and flamewar-bait on those topics is not that.
Well, I agree to all of that, I just don't read the same thing as you do in those critiques. To me, they do not sound like belittling authors who post here (frankly, of all languages that are used just because they are trendy, I much prefer that it's rust than any of the many runtime typed evaluated languages that used to be popular in the past).
To me the actual target of those critical comments are not the projects at hand but rather that trend in our industry to let popularity lead our decisions, and how easily we form small chapels that fight each others instead of encouraging learning and practicing several competing techs.
Not that it will change anything, though.
It's worse: the target is always the people, not even the projects. It would be fine if there were any actual criticism, but it's just name calling all the way.
And the top level comment about "cool kids" I answered to definitely doesn't have the nuance you suggest it has, nor does the flagged comment comparing it to a religion, or the comments calling people "hipsters". And this thread here is actually better than average.
As someone that was around for the C++ hype, it was designed as TypeScript for C, and many of the reasons why it didn't deliver was exactly those C refugees that kept writing C code, but now with a C++ compiler.
It is no different than those folks, now 20 years later, that adopt Typescript, but really the only thing they do is to rename the file extension, and keep writing plain old JavaScript as always.
For a developer tool? Genuine question, how long does the JVM take to start? It used to be slow, but I don't know what it's like now. Check out the speed comparison of a few linters on this page -> https://astral.sh. Would the JVM start before the fastest one finished?
And supposing you took start time out of it, how long would an equivalent Java program take to run?
Memory isn't as much of an issue, but all other things being equal users do prefer the program that consumes less memory.
Java doesn't do cooperative multitasking (sorta aka greenthreading). That's why there are all these promise/future/whatever frameworks that do it, vs Golang, Rust, and even JS where it's just part of the runtime.
Yes it does, that is why originally there were green and red threads, the language specification doesn't require which kind exactly a JVM implementation should provide.
Also since Java Loom project, it has virtual threads.
Additionally, since at least a decade you could your own thread scheduling if feeling so inclined to do some low level coding, as the scheduling architecture is customisable.
Greenthreads were abandoned long ago and aren't present in any mainstream JVM. I don't know about Loom, seems recent (or upcoming?) and specific to OpenJDK.
I rather use tools not stuck in jurassic time of programming language design, again, Go's performance is behind most Java implementations.
That wouldn't be true for gccgo implementation, but then again, it is now abandoned in pre-generics Go, stuck at version 1.17, no one seems to care to update it.
Your assertion that Rust isn’t well suited for command line programs contradicts reality, where developer tools for multiple languages are being rewritten in Rust. The new bundlers, linters and formatters for JavaScript and Python (the most popular languages by far) preferring Rust and gaining massive adoption tells me that Rust is pretty well suited to CLI programs.
And the success of ripgrep, mcfly/atuin, zoxide, hyperfine and starship, just reinforces the feeling that yeah, CLIs written in Rust can succeed.
So yeah, strongly disagree with you about Rust’s place.
But from your previous comments I also know you’re very knowledgeable about Rust so I’m surprised you came to this conclusion.
Don't mistake Rust Evangelism Strike Force, and joining the hype cycle, with the suitabitility for writing CLI developer tools there is nothing there that requires the use of borrow checker.
Depending on how many years into the past of HN headlines we would search for, it would be Go, Scala, Haskell, Ruby,...
Maybe all those Rust CLIs will be all being rewriting into Zig, as soon as version 1.0 gets out.
I've been on HN for a while, I saw the previous hype cycles. I have no doubt we'll see a Zig hype cycle as well.
One of the reasons Rust succeeded, especially in CLI was
1. Low fixed memory overhead (compared to most popular VM based language - Python, Ruby, Java).
2. Startup time is nearly instantaneous, compared to the same languages. Don't have to wait 50-100ms or so just to start executing code.
3. Run time is faster as well, especially so for programs like ripgrep that use SIMD.
4. Single static binary with no dependencies. Didn't need a VM or toolchain to be installed on the user's computer.
Having a great CLI library like clap.rs brought it all together.
If you think this is simply a cycle and Zig will replace Rust, I'm slightly skeptical. Rust had an easier time competing with the status quo because of the 4 advantages it had.
Zig however, will have to compete with Rust. Sure, you can start ziggrep, but it'll be about equal in all these 4 factors. So why would anyone adopt something that has fewer features than ripgrep and about the same performance, memory consumption and ease of use? Just hype? Some people will, but not enough to get the critical mass ripgrep has.
That's why I'm bullish about Rust - the performance of existing codebases means that in many cases, it's hard to migrate away from it, or replace Rust programs with reimplementations. You'd have to be getting something really unique that Rust doesn't offer. You said Roc, and Roc is actually a great example of benefiting from something unique. Roc plans to reuse the Zig compiler's library that emits LLVM bitcode. There's no Rust equivalent.
But I'd argue that that's pretty niche. How many other examples are there of Zig libraries that have no Rust equivalent? Something that would make Zig the no-brainer choice over Rust, even if you had to reimplement in Zig.
Again, I'm sure people will try to rewrite things in Zig. But I'll confidently assert -> the most popular toolchain for Python in 5 years will be Rust based, not Zig or any other language. $10 on that.
I think a really important benefit is going to be binary size. That's what initially made me dislike Rust quite a lot.
And for CLI tools, you need those to be tiny. You're going to many of them, and you'll want to build a whole distribution, which you'll want to be small (for small images, small containers, etc).
Another benefit (that Zig won't offer) is good shared library support, which distribution maintainers will always prefer. I don't think there's a good language for that, but if one will appear, it will definitely be favored.
As ripgrep's author, I think binary size is important, but I think it's simultaneously a niche concern. Saying that they need to be tiny is I think a pretty big overstatement. They might need to be tiny in specific use cases, i.e., niche. But the 99% use case is probably that most users don't care. ripgrep's binary size is already pretty meh (especially compared to similar tooling that relies more heavily on dynamic linking). My guess is that if its binary size doubled even from what it is today, few would notice and even fewer would care.
AFAIK, ripgrep's biggest deployment is through VS Code, by far. Nobody is going to notice that some part of VS Code is now using 8MB instead of 4MB (or whatever it is, I think it's around that). It's largely a non-issue from my perspective.
Now, compile times... That's a different story. I'll happily complain about that one.
> But the 99% use case is probably that most users don't care.
For 1 really good utility like ripgrep, yeah. You'll convince many people to use it based on its merits. You might even have 5 or 10 of these utilities, if they're really good.
But for Linux system builders, for the things that go into standard distributions, where you need hundreds of such utilities, Rust CLI binaries are simply not sustainable. Not for size, not for security, not for simplicity of bootstrapping, nor, as you said, for compiling an OS from sources.
You will be able to get ripgrep into many distributions, but it will be more unlikely to become one of the tools installed by default for that reason.
> You will be able to get ripgrep into many distributions, but it will be more unlikely to become one of the tools installed by default for that reason.
Oh I don't agree with that all. It might be a factor, but it isn't going to be installed by default because grep will already be there. Unseating a POSIX user land in a Linux distro is not going to be blocked just on binary size IMO.
I also think what you're saying is not inconsistent with what I'm saying. The default tools installed on a Linux distro is a niche use case. ripgrep doesn't need to be installed by default in any Linux distro in order to be successful.
If you're setting out to build tools to replace, say, a GNU user-land to fulfill POSIX (or provide an entirely different sort of user experience), then binary size is probably the least interesting thing to overcome. And if you "try" hard enough, Rust binary sizes can be reduced quite a bit. ripgrep being 4MB is the result of me not caring at all about binary size (beyond stripping debug info). But this is a niche goal IMO, and IMO does not support your initial claim:
> And for CLI tools, you need those to be tiny.
Notice how if you instead said:
> And for CLI tools that are installed by default on a Linux distro, you need those to be tiny.
then it takes almost all the air out of your comment.
I’m not sure if calling Rust “what’s in fashion this week” is accurate since it has been common for at least five years (if not longer) for posts that include “in Rust” to blow up on HN.
It has been the Most Loved/Most Admired language on Stack Overflow’s developer survey for 9 years in a row. I know that’s a relatively short amount of time for a programming language, but to me it seems like it has some serious staying power.
Maybe, just maybe, some of these "kids" know what they're doing and are preferring Rust for legitimate reasons other than fashion - such as performence, memory safety, and type safety.
Rust is legit for use cases typically served by C, C++, or maybe Java. I get more skeptical when someone's trying to shoehorn it into some other use case.
Rust is great, but it's not like it's "fast" to develop in. JS, Python, and Go are all languages that can move a lot faster because you have less rules to follow. Maybe an _expert_ Rust eng can move just as fast, but you'll still move as slow as your slowest team member most likely
I think you're confusing "garbage" with just normal heap allocation. Rust will free that memory automatically when the JSON strings go out of scope. There's no "stop the world" thing that periodically scans and deletes stuff while your program is running like in Go or JavaScript. Because there's nothing to delete. There's no "garbage".
At least reference-counting is typically considered a form of garbage collection (e.g. using Rc<> or Arc<> in Rust, or std::shared_pointer in C++). Arguably, RAII calling destruction code at the end of a scope could also be considered garbage collection, the garbage is just very short lived ;)
I guess 'automatic memory management' is the less controversial term which covers both traditional GC and RAII, the downsides are very similar though.
It's different because the free() is deterministic, the instruction is encoded into the binary. Completely different than garbage collection where there is a whole runtime that has to periodically go figure out what can be safely deleted and what can't.
For one-shot programs like Babel, Prettier, Terser, etc. mentioned in this article, I don‘t see how the lack of a garbage collector is a strong argument for an alternative language.
This is a strange distinction. So something is garbage because it is not used? In Rust, a Vec is only deallocated at the end of the function, regardless of when it is actually stopped being used. Are those garbage too?
At this point, garbage just means whatever does not follow RAII. And RAII is not the best solution either. For throughput reasons, GC languages can be siginificantly faster exactly because it doesn't have to clean those "garbage" at every step.
It can happen in practice. For example, I see a lot of C++ code with extra string copying that would be hard to avoid. Like if some func takes a const vector<string>& and you have a string in any structure besides a vector, you're gonna copy that string.
Sure, what's the issue? Do you think that there is an algorithm that
a) does not do this,
b) can't be implemented in rust, but can be implemented in C or other language?
…if there’s a “why”, maybe it’s because WASM can’t interact with the DOM and the debugging experience isn’t very good.
The DOM API is defined as a JavaScript API. The browser, JavaScript, and the DOM API have been evolving in parallel for over 20 years. If you want to interact with the DOM from WASM, what you can do is write a function in JavaScript that interacts with the DOM, and then import that function into your WASM module.
To further explain: the standard WASM ABI is essentially just a C ABI, so you can pass integers and pointers around, but you can't do much more; anything more complex needs to be built on top of that, which precludes binding to the DOM API directly.
The existing workarounds for this glue the JS DOM API to the guest language through glue on both sides, but this means that you have to pay the penalty of marshalling through JS for every single call you make.
There's a solution in the works to make direct interaction possible, but it's proven to be quite challenging to finalise: essentially, you need a high-level ABI that can provide a safe and fast interface between the host and whatever guest language, and defining that in a way that makes everyone happy is non-trivial.
For more information, see the Component Model [0] and WIT [1]; the idea is that you will eventually be able to compile your WASM to WASM Components, which can then interface with the host (or other WASM components) through the WIT IDL, including interacting with the browser's DOM.
No, not even that (the second thing, passing pointers)! WASM has a different address space (starting from 0), effectively indexing into the WASM module's linear memory. A pointer/reference from the outside env can not be dereferenced from within the WASM bytecode.
The multiple linear memory proposal can circumvent this (allowing you to build something somewhat similar to a simple MMU/address translation engine), but language support for that feature is sparse (AFAIK, Rust does not expose any way to access a different than the default linear memory for example).
There is various hacks around it, but sharing memory block-wise between WASM and outside env is involved already.
It's defined via WebIDL (https://webidl.spec.whatwg.org/) which is theoretically language agnostic, but practically speaking the primary implementation target is JavaScript.
So is Go, and so is Python. The LLM craze shifted the focus from JS to Python a while back, and I’m all for it.
That doesn’t mean I’m under the delusion that JS is going away anytime soon; at least from the FE. But its monopoly on the web took a big hit—and rightfully so.
JS is a terrible language, and people who only know that one language will fight tooth and nail with anyone who opposes them.
This gave birth to the awful trend of using JS in the backend. I understand that sometimes JS is the only option for frontend work, but keep that junk out of my sysarch. There are better languages your backend can benefit from—Go, Rust, Zig, Kotlin, Python—anything but JS/TS.
I’m glad the industry has learned from its mistakes. I’m seeing far fewer Node.js backend jobs and a lot more Python, Go, Rust, and C# roles.
Jobs are regional. Here in Estonia I see a lot more Node.js jobs YoY, very few Python gigs, zero Rust jobs, and very few C# jobs. Heck, PHP has more jobs than C#. Node/JS seems to compete with Java here for job popularity, according to local job boards, and most Java jobs also require Node.js/JS knowledge.
Europe is always playing catch-up with the US. Even so, the number of Node.js backend jobs has declined in both Berlin and Amsterdam.
I’m also seeing a ton of Java, C#, and Go jobs in London. At my workplace, Wolt/DoorDash, all new services are being spun up in Go, where Node.js used to be the default.
Plus, LLMs have gotten really good at Node.js and Python, driving backend salaries down quite a bit. In this age, being a one-trick pony just won’t cut it anymore.
Getting kind of tired of this Europe vs US trope. Europe is a huge place with each country having a rather unique economy, making a blanket statement like you just did entirely ignores that, and where does this constant need to compare one place on the planet with another place comes from? I don't live my life comparing everything about my country with another country, do you? Development trends themselves tend to also be cyclical.
As for LLM's, from what I see the languages that LLM's are most often used for are those with the lower barrier to entry / and those that UNI's and bootcamps teach, which would very much also include Java. However, what I see is actually my salary going up as the average candidate quality has been also decreasing, almost in correlation with the usage of LLM's. So while maybe the junior/mid-level salary goes down, the senior salary, in my observations, has not. And I keep hearing from companies how finding actually capable developers has become harder and harder, so I expect my salary to only go up.
Now, of course, being a one trick pony has never been a good thing, I agree on that (did you assume that I'm a just JS dev?), but I was just answering to your original comment.
The new thing that gadget addicted males love because it's shiny and it's better and safer and the ultimate cool.
Come everyone. C is dead, Javascript is dying.
Also it is used by the bigdiks, like facebook who can't make a proper comment system, yet they market react as another shiny thing. And Apple who always turn your bluetooth back on after update. And google, who act like inbred mutants thanks to the incest that is going on there. A W S, the three letter magic thing also uses it. Plus cloud!
And the list goes on! Plus it has fugly syntax, but who cares, it is memory safe!
Sharing types between React and a Typescript backend is great DX for developing both in parallel and I've not seen anything that comes close to being as enjoyable. Being able to change the signature of an API endpoint and immediately having all places in the codebase where the change will cause problems flagged as type errors is wonderful. I went back to working with duplicated types across python/typescript on a contract project recently and it took me 5x longer to fix the downstream implications of signature changes.
I'm quite dismayed to say that this has been a feature of any Java developer setup for the past 25 years. Yet hipsters threw it all in the garbage when node.js took off and are only now starting to approach feature parity with a 2002 JBuilder or Eclipse of the same era.
Can I tell you about live debugging of an app server and hot reloads? Pretty wonderful stuff really.
I can't believe how much knowledge, tooling and experience was thrown in the dumpster when Java was abandoned en masse by the younger generation of devs due to the rise of node.js. And if it weren't for Typescript the tooling would still likely suck.
What always strikes me about posts like this is the lack of introspection: why did younger developers reject Java?
It’s easy to say “because they’re hipsters following trends” but I dipped my toe in the Java world years ago and found it immensely frustrating. Eclipse was awful compared to the lightweight editors I was using at the time. The language got in my way more often than it helped me.
I’m sure that’s not the case these days (indeed I’ve done a little Android-adjacent stuff and found it to be fine) but the idea that there were no downsides to Java at the time strikes me as unlikely.
The design of Java is focused on code maintenance. That's exactly what young developers lack experience in. They know how to write greenfield code, by themselves. They haven't yet looked back at code they wrote and said, "ugh, what the hell was I thinking?"
Since Java was developed the world has shifted to accommodate a lot more rapid development and code you throw away rather than maintain. But experienced developers also know how often "prototypes" are still around decades later.
Java is also not perfect, and a lot of new languages are conscious of its faults. But the reason it's still around is that it's core principles are oriented to code that sticks around.
> But the reason it's still around is that it's core principles are oriented to code that sticks around.
You could equally say this of COBOL.
> They haven't yet looked back at code they wrote and said, "ugh, what the hell was I thinking?"
Ironically, "what they hell were they thinking" is exactly the reaction I have to even Greenfield code written using Spring Boot or any of the other annotation driven nonsense.
The idea that programs written in Java are more maintainable than programs written in (say) Go, where you can read what the program does end-to-end instead of having to guess at what garbage has been generated by Lombok or overridden by some random JAR on the class path is bizarre. Let's not even talk about Gradle.
Yeah, I'll defend Java, but I won't defend Spring. I have no idea what they were thinking.
A lot of external Java framework is about inversion of control. It looks good on PowerPoint slides, but I think it's horrific to maintain (as well has hard to write). Inversion of control means you have no control, and the most common error case is "why didn't my code run?" But you can't use a debugger to tell you what didn't happen. Any breakpoints have to be set inside the framework code, which is open source but is not intended for your eyes.
Yeah, spring was and still is, an abomination. Spring boot also. But it's not a requirement even if many Java projects fell into that trap.
My opinion is that Spring usage should be minimised as much as possible but it is a matter of fact that Spring is not Java.
Spring may not be Java (The Language), but it absolutely is Java (The Ecosystem).
It is mainstream Java, though.
Yes, it (Spring) is. However its current scope creates more problems then it solves.
//go:generate
Yep no magic...
Have you ever read Kubernetes source code?
I have (in depth, often under the gun of a production outage).
Kubernetes is not a good example of idiomatic Go in any sense. Perhaps Spring Boot and friends are also not good examples of idiomatic Java, but they are absolutely the common case of what is found in the wild.
Just like Kubernetes, and its related ecosystem at CNCF are the main raison dêtre why many of us put up with Go.
The difference is prevalence.
Kubernetes is a single (bad) Go project. Every piece of Java I ever see is AbstractFactoryProxyBean nonsense with annotations all over the show.
I don’t know of a Go project where I can’t start at main (for a given program) and work out how it works without a bunch of ecosystem context. I can’t think of a single Java program where I can.
I have experience with code maintenance. The only upside of Java is that it's faster than JS or Python. It's otherwise a worse language and ecosystem, and it was even worse before it had lambdas.
Actually... if it's for a web backend, NodeJS might be faster in practice.
It's a very one-dimensional view.
My problems with Java are startup time and memory consumption (and NPEs).
If that's not your problem - fine. But writing web apps in the Java ecosystem has been terrible for many of the most important years (let's say 2005 to 2015) and that's where all the "young people" forsake it for... PHP, Rails, node.js.
(You can already guess that I'm not even counting myself as part of the younger generation here. I'd used used Java and the JVM intermittently between 2000 and 2020 but it has never been my favourite stack).
Java was so bad that Android took a hard pivot to Kotlin. If anyone understands the importance of code maintenance, it's Google. They built a language for it (Go). I think it's ok to look at historical Java for what it is and learn from it's mistakes. Modern Java is better. Unfortunately, it's developed a bad rap, and it looks like it's in a decline. Fortunately we have Kotlin, Go, Typescript, etc.
Exactly! I got my first job in Java after a few years as hobbyist programmer in other languages (mostly PHP and JavaScript but a few others too) and what struck me was that the tooling was both mandatory and painful to use.
I wasn't fond of JavaScript (In particular, I never liked dynamic typing), but when I had the opportunity to work in node.js instead of Java I took it immediately, just to avoid the pain and suffering that the Java toolchain inflicted on me.
Java is a language of bondage and discpline. And architectures. And myriad pointless interface definitions. And overblown class hierarchies for problems ill-suited to the OO paradigm.
I started my career in Java, and worked in it for 20 years before I really started using Javascript in anger. I didn't (and don't) like Javascript, but the freedom for prototyping was a revelation. When Typescript appeared, I fell in love.
It had a steeper learning curve than other languages or environments but that was for a reason. You got a lot in return. And those lightweight editors and environments are like that because they don't do very much.
And talk not to me about lightweight. I'm currently on Day 4 of setting up a Python environment in VsCode that doesn't suck. I'm nearly there though it's still a bit inferior to a 20 year old JBuilder install for Java but I guess it needs a few more years to get there. Oh and as I said, I'm on a long quest here to pave the road for my devs but it looks like this hodgepodge of extensions still won't deliver the experience I had decades ago.
Isn't using VsCode for a non-Microsoft language going to be difficult, by (MS's) design? I'm not saying it can't/hasn't be/been done, but I doubt MS are making it easier to do so. It's been their m.o. for a long time now.
I'm also not saying there's a better option for you and your team, either, my friend.
As a python programmer using bare-bones vim (on purpose), having abandoned all fancy IDEs, I really wouldn't know where the state of the art is, anyway, but I doubt the MS leopard has changed its spots.
Isn't using VsCode for a non-Microsoft language going to be difficult
Python is pretty close to a 'Microsoft language' these days. They've hired several Python core developers to make sure windows is first class citizen for python and the developing python on windows and with VSCode is as good an experience as possible. They also develop the official VS Code Python extension and language server as well as many other python tools and extensions.
I'd say the current state-of-the-art is either VSCode with the Microsoft python extensions or Jetbrain's PyCharm. Personally I slightly prefer PyCharm Pro, but it's pretty much a toss up.
Thanks for excellent breakdown.
This feels true for other Microsoft products, but not VSCode. Besides, they embedded Python into Excel (for 365 users) over Typescript or C#.
Interesting.
Embrace & extend complete ;-)
This time it looks like 'integrate' will be the third step.
Thanks for the great info.
Yup. As an older programmer I can say that there were indeed very good reasons back then to stop using Java. Mostly related to JVM but also the language lacked lots of features.
Java today looks like a fine platform, though.
But the comment you're replying to doesn't say Java doesn't have any downsides. It just says that Java has a great story for doing shared types between client and server, which is true. It's also true that Java as a language has gotten a lot better over time. This is I think thanks to pressure from other languages written for the jvm like kotlin, And also developer feedback for those who work in other languages like JavaScript. Java is old and boring. Just like go is new and boring. Rust has plenty of downsides this idea that it's easy to use. Seems wrong to me. The borrow checker is famously difficult to work with despite being a central feature of the language. The really big upside to JavaScript is that it's the native language of browsers and so in a weird way. If you want to get closest to the metal so to speak, JavaScript is a better option for most deployed applications. It's interesting to note that the op's article mostly points to build tools that are written in rust rather than applications and I think that's telling.
> But the comment you're replying to doesn't say Java doesn't have any downsides
Yet it blames "hipsters" for throwing "it all in the garbage," implying that there was no rational reason for people to switch away from Java. Naturally, people respond by sharing their reasons.
At least from an Android point of view, the JVM world still has its share of frustrations and lack of polish/QoL relative to other software development spheres. Gradle has me pulling my hair out multiple times each year for example, and yet for some reason nobody sees it fit to replace it with something less ridiculously complex and prone to error (user or otherwise).
Don't blame Java for the misteps of Google and Android team.
Android started being devleoped mostly by C++ refugees, that is why originally all framework code is full of m_ prefixes.
Then the whole standard library fragmentation that persists to this day.
Despite the whole excuse why Dalvik was created, Nokia and Sony-Ericson had quite good JVM implentations for Symbian.
When Kotlin was introduced they stiffled Java on purpose, left it on Java 8, using Java 8 examples to promote Kotlin, and have since Android 12, started to finally update ART to more modern versions, because as it turns out, even with Kotlin, loosing compatibility with the Maven Central ecossytem isn't that great.
Still, it is mostly Java 17, and all the ongoing improvement in Java land across all JVM vendors, will most likely never land on Android.
Android is not Java, even though it relies heavily on the ecosystem for its tooling.
Android is basically Google's .NET, and Kotlin plays the same role as C# in relation to Microsoft's J++, that lead to Sun's lawsuit.
Jetbrains have a project to try and replace Gradle.
I've looked at it also. The problem is incentives. Will developers pay for a better build system? Probably not. Then, what people use is whatever happened to be given away for free first.
Another problem with shifting Gradle is that lots of libraries now come with build system plugins too, so you'd need to replicate all that logic into whatever new build system you create. And it's actually not easy to get everyone to agree on what they don't like about Gradle. Say "imperative not declarative" and half of devs will agree and the other half will say, no, you need programmatic configuration because build systems are genuinely complex. Etc.
It’s both now.
https://gradle.github.io/declarative-gradle/
Fingers crossed.
I've long since given up on Gradle being able to get this stuff right. The syntax they're proposing is the THIRD similar-but-incompatible syntax they've adopted after Groovy and Kotlin. Good luck figuring out which is in use by looking at a code sample.
The biggest problem with Gradle is not Kotlin or even Groovy syntax. Kotlin isn't a bad language to use even for writing configuration. It's that the entire thing is designed in extremely confusing ways from back to front, and has a lot of awkward design choices and bugs that result in a hyper-complex user model.
What the JVM world needs is a totally new tool that has the same feature set as Gradle but with a drastically simpler mental model behind it. The only real contender right now is Bazel, I think.
We just keep using Maven, there must be valid reason on customer side why we should use Gradle instead of Maven on our Java consulting projects.
Yeah, gradle/maven was a mistake that happened along with most "app store" style 3d party library slingers.
I'm of the opinion that the world was a better place with Ant and when we had third party dependencies manually, deliberately adn deliberatively managed by hand in /jars/thirdparty
As long as you don't get to debug such builds....
As someone that was writing Ant scripts when CruiseControl was modern, and there was no Ivy in sight, not sure if it was such a better place.
I hated Maven at the beggining, exactly because we got some hipster company pushing for it during Maven early days, it was still hot out of the oven.
20 years later, I don't see a reason to use anything else other than Maven.
Speaking as a younger developer at the time, Java just seemed weak compared to my favorites -- Common Lisp and Scheme. It lacked a proper procedural abstraction and forced you to do everything through classes and objects in a way that not even Smalltalk, having blocks, demanded. This was especially the case when it became an enterprise language and the standard development process involved lots of boilerplate. Also, a lot of kids came out of school knowing almost only Java, and it seems they were cut off from different worlds of development which could provide some insights. Even C++, which I loathed, had things to teach.
I've grown up a bit since then, and so has Java. These days I work in Java for my day job, and it's perfectly fine. I don't even mind all the boilerplate, I can look at a page of code and just see blonde, brunette, redhead.
But I still love Common Lisp and Scheme much more.
In my experience, young people who hated java never worked in java and knew nothing about it except that it is evil.
The second thing however is that fronted is better off in non-java languages, you can afford to do small backend in typescript and what not. And larger enterprise projects were done in java the whole time.
> The language got in my way more often than it helped me
Got in the way how? By insisting that things have types and one cannot blindly add an object to an array [] + {} and expect it to behave? Never mind that in Javascript adding an array to an object {} + [] gives a different result.
ETA: for bonus points, what does {} + {} return?
Java is verbose, is a resource hog, requires runtime management for basic app performance, the major frameworks (used to) require an awful lot of boiler plate, the developer tooling almost necessitates an IDE which 10-15 years ago meant eclipse which was slow, bloated, and unstable. There’s also always been licensing “fun” with oracle, sun, and the jdk.
What are you talking about, seriously. 10-15 years ago, eclipse was neither slow nor unstable. It worked perfectly well. IntelliJ was not slow or unstable. There were not real major licensing issues.
As a newcommer to javascript, I was able to learn faster and produce same quality faster then non-IDE developers. Not because I would be smarter or more talented, but because I had no emotional need to prove myself by not using ide.
Eclipse was _the_ tool when I was working with Java at the time. Slow and unstable is definitely my lasting memory, compared to virtual studio 2008/2010 which was fast and powerful.
> there were not real licensing issues
Oh yes there were. Even in 2024 the “which JDK are you running on” debate still goes on. There are notable differences between corretto and openjdk, and openjdk and Oracle JDK. Here [0] is a stack overflow question that notes it was asked 10 years ago that talks about the various JDKs and the license change where oracle started charging for JDK access.
As for your point about IDE’s vs non-IDE’s that’s a straw man. I said that you were forced to used an IDE for Java (which is of course not technically true but compared to rails which took of at that time it is), but also that the IDE du jour (eclipse) was pretty monstrous.
I’ve said this on here before but the minute maven gets introduced into a project build times are measured in minutes. My current work project is c# and I can run my entire test suite faster than the jvm got itself up and running on my last kotlin project. Even IntelliJ and co suffer from these limitations - manually bumping the memory limits for IntelliJ and friends in 2024 is practically a requirement, and the startup times are very Java inspired.
[0] https://stackoverflow.com/questions/22358071/differences-bet...
If you mean visual studio for dotnet and it is comparably piece of crap. A lot of unexplained behavior and it generally feels like someone just wanted to check boxes. Dotnet and visual studio actually made me love love a lot more after I worked with them.
Java and Eclipse are waaay better then C# and visual studio. Kotlin is a pure pleasure against C#.
Also, I see people using different JDKa on the same project. That there is competition is a good thing, it is not like you was locked in one.
> If you mean visual studio for dotnet and it is comparably piece of crap. A lot of unexplained behavior and it generally feels like someone just wanted to check boxes.
I disagree. dotnet has it's quirks, but so does every mature ecosystem. I wouldn't use "piece of crap" to describe it (or java) and I get that it's an opinion, but I think your opinion is more misguided than what yo're accusing other people of believing.
> Kotlin is a pure pleasure against C#.
My last project was a kotlin backend powering a C+ desktop app. The kotlin backend took longer to compile than the C++ did. Kotlin is the kitchen sink bolted onto Java. It's definitely a nice environment to work in, but it's certainly not a more streamlined java.
> That there is competition is a good thing, it is not like you was locked in one.
If by competition you mean OpenJDK forks with minor differences then yes there's competition. To me that's not competition, that's fragmentation.
> Java and Eclipse are waaay better then C# and visual studio. Kotlin is a pure pleasure against C#.
Except, unlike Kotlin, C# has a rich selection of what to use for development across a variety of platforms and is not constrained to JVM's type system limitations, allowing the syntax differences to have meaningful impact on the code execution.
It also has excellent, comparable to Go and Rust, CLI tooling to further streamline the process of quickly managing, building, testing, running and deploying projects, something JVM ecosystem is yet to provide an alternative for.
Yes, 10-15 years ago, Eclipse and IntelliJ were unbearably slow, overly complex, and made developers very frustrated.
Yeah but that was when product managers broke it. The early days eclipse circa 2002 was amazing
15 years ago, it took a full 10 minutes to launch IDEA or Eclipse and have it finish opening a large (100kloc+) java project on a brand-new high-end MacBook Pro.
3-10 crashes per day were common.
Lots or coffee breaks, or at least switching back to emacs to just finish editing whatever classes you were touching.
> What are you talking about, seriously
It's probably unavoidable that people's memories will differ, but personally, as someone who worked with Java 10–15 years ago and then ran away as fast as he could, these are the things I remember most: the IDEs being awfully slow and unstable (though quite powerful for their time) and the language/ecosystem being painfully verbose and full of boilerplate and layers of indirection. I remember how, after switching away from Java, I felt elated by how easy and maintainable things could be when I was allowed to use simple, fast tools and write straightforward code that just did what it was supposed to do.
I won't apologize for rebelling against Eclipse, SOAP, XML and AbstractBeanFactories. Java the language is pretty cool and very powerful, it's the ecosystem that was turning people off.
I hear Java has gotten a lot better. But then again there is C#, which is pretty much just better Java. Still too enterprisy for the tastes of most HN types though
Java types are not nearly as expressive as typescripts. As someone who has worked with both, I would personally pick typescript everytime.
> I'm quite dismayed to say that this has been a feature of any Java developer setup for the past 25 years. Yet hipsters threw it all in the garbage when node.js took off and are only now starting to approach feature parity with a 2002 JBuilder or Eclipse of the same era.
Last I checked If I change a signature or something in Java, I am not guaranteed the whole thing "checks". If I add a new exception to a function, how do I know what else is effected?
Java checked exceptions are (were?) a wonderful feature that was wrongly dissed for the same reason Java types and IDEs were dissed. It forced people to handle exceptions or pass them up the call stack but they had to be dealt with. And IDEs were aware of them so not catching or rethrowing was immediately flagged by the IDE.
I give it five years until Typescript and peers adds checked exceptions.
TypeScript definitely won't add checked exceptions, because Anders Hejlsberg considers them a mistake[0].
[0] https://www.artima.com/articles/the-trouble-with-checked-exc...
If you add a checked exception to a function, your code will not compile and the compiler errors will tell you everything that is affected.
It's pretty interesting that people think Java was abandoned because of other languages, and not because of the problems of Java itself - or indeed that features like hot reloading and live debugging are niche or unique to Java.
.NET has also had all these features for just as long, and is less prone (though definitely not immune) to AbstractFactoryProxyBean nonsense.
Java was abandoned en masse by the younger generation
We tried. Java was fine, JBuilder was fine. When they instead started pushing J2EE, EJB and all the other acronyms I've forgotten, this 'youngster' realised he'd never be smart enough to be a Java developer and bailed back to C, Perl and Python.
Had they focused on Java and making Java a great language in its own right, it no doubt would have gone a lot better. But all the 'hype' and marketing around Java was focused entirely on these huge frameworks and enterprise 'solution' architectures which most 'youngsters' just didn't understand and didn't see the need for.
If someone makes it clear their product isn't for you and that they don't care about solving your problems, is it strange they abandon you?
JavaScript is an awful language. Doesn’t mean Java is the answer. There are other languages—Go, Rust, Python, C# that offer better protection without sacrificing ergonomics.,
> feature of any Java developer setup for the past 25 years
do you mean rmi/javabeans or something else ?
beside that, I left java long ago, and believed in simpler REST stuff but now I realize that it's indeed rediscovering stuff people dealt with long ago
Java beans was just convention. Enterprise Java Beans was a mistake which probably contributed to Java's bad rap for a while. But you could use an app server without EJB just fine. I did for years and never had problems.
As for rmi, when Java was in its heyday the most popular protocol for remote api handling was SOAP. But when RESTful era arrived Java tooling adapted very quickly and it made little difference what you were using to call outside the app server.
JavaBeans and EJB became things because Microsoft was eating everyone's lunch with their component paradigm, COM, on the client side and were making inroads into server-side enterprise computing as well. With COM, you could write components that just plugged right in to an application, in any language. Java, despite being ostensibly object-oriented all the way down, didn't have an answer for this until JavaBeans emerged and then EJB for the server side. You have to remember that Microsoft had a relentless focus on developers building stuff on top of their platform. That image of Steve Ballmer sweating like a mule and chanting "Developers! Developers! Developers!" wasn't just a meme, it was an indicator of the entire company's direction. Nobody could match them at the time. From Internet Explorer to Visual Studio, 70%-80% of Microsoft's monopoly was built in simply outcompeting everyone else. If people were locked into Windows, it was because it just made sense from a business standpoint.
But yeah, I built business apps with just Tomcat and no J2EE components and it was fine.
It never occured to me to link COM and J2EE RMI/EJB.
Both of them are at their core a set of conventions to make a component usable at runtime without having to know its API aforetime.
and what kind of library / ide plugin is used to call rest api in a type safe manner without writing boilerplate ?
Most frameworks will do that? In Micronaut it's something like this on the client:
then you inject and call its methods. It will use the annotations to validate the call client side before sending it, and you can implement the same interface on the server: where the same validations will occur before the call is accepted.thanks
Jesus Christ.
Don't worry, the Typescript ecosystem is fast becoming Java.
And that's the exact reason I'm done with it.
> Don't worry, the Typescript ecosystem is fast becoming Java.
Typescript is somehow becoming a laguage that supports writing extremely performant high throughput and very scalable server code? That seems unlikely. So no worries, it can't become Java.
I said the Typescript ecosystem.
Java, as a language is fine I guess, but the culture around it sucks.
> Java, as a language is fine I guess, but the culture around it sucks.
Culture is what you want it to be.
There are indeed some ridiculous subcultures within the world of developers who use Java. Like J2EE-anything or any of the baroque frameworks.
It is important to realize none of that is part of Java and none of that is required unless you really want to.
You can use Java simply as a memory safe language with reasonably good type safety that can create wicked fast code and has huge library and tooling support. On all those checkboxes, there are few-to-none options that are so good across all those aspects at once.
Unfortunately so many people just complain about writing TaskStubConsumerWatcherVisitorServiceContainerListIdentifier classes, without realizing nobody is forcing you to do that. So don't.
You mean capable of stable firehose throughput, similar to Go? State of the art GC research on state of the art VM? I wouldn't be surprised if Java had more money behind it than JS on the R&D & corporate backing side.
GWT was an attempt to let you live in java land and also still get the (tremendous) benefits of deploying to the browser Javascript VM. We used it on a java backed project, but we were not building an SPA so didn't see all the benefits.
I haven't used it for a long time, but it's still alive: https://www.gwtproject.org/
It still blows me away that we settled on JavaScript as a VM. It wasn't designed for that, and it took a superhuman effort to make it work well enough.
I feel like there's an adjacent universe where the JVM lives in every browser and JS was a weird failed experiment. But it turned out that the browser was the universal UI everyone had waited for, and Java didn't connect to it while JS entrenched itself there.
GWT was a glimpse of trying to send us to that universe, via a twisty back door. But it was never gonna happen.
You can thank Sun Microsystems for this. They had the world in the palm of their hand with HotJava, but decided to abandon it. If they had continued, Java would been the language of choice for the web and they likely wouldn't have been acquired by Oracle.
HotJava, IIRC, was more focused on Swing apps. Swing just wasn't the right thing for users; the HTML DOM turns out to be more comfortable. Even though it means sometimes failing out to the Canvas, which gives you nothing.
NB: I was very distantly part of the Swing team. I did early reviews of its design documents.
Considering we have full replacement frameworks like React, Flutter, etc built as DOM replacements, I would say Swing was definitely the right thing for users. Probably could have offered an "easy markup enhancement" library for plain documents, but anything extensively dynamic should be written with a proper UI framework.
It's a hard sell for the majority of users and the mainstream market at the time. Flash apps had cute, lazy loaded, ~lightweight, animated mini apps. Anything java at the time was heavy, enterprisey, requiring more setup to get blocky GUIs that didn't do much.
I wish to live in that universe, and hope that WASM will bring it closer to us. Clearly, Javascript gets compiled to some intermediate representation, that then gets JITed/interpreted and then interacts with the native browser API.
I wish us devs would have access to that intermediate representation.
the client side java didn't last long, flash and js were more mechanically sympathetic on too many aspects (dev culture, user expectation about load time, cute visuals)
but yeah js is a strange creature
That's cool but I get a chuckle when I see server side html rendering being all the rage now and thinking to myself, should I tell the juniors about servlets, JSP and Struts?
Most of the abandoning of Java was due to Ruby on Rails not JavaScript.
No chance, relatively few software companies ever adopted Rails but a huge number went from Java or .NET -> JS/TS. The draw of cross project code reuse and having teams only needing to know a single language remains compelling.
Java was largely already being abandoned before NodeJS existed. A huge percentage of the web 2.0 companies were built on Rails. Twitter, Github, Shopify, AirBnB, Groupon, SoundCloud, Instacart were all built on Rails. It maybe flew beneath your radar but it was a phenomenon at the time, way before Node.js even existed.
Those examples aren't representative of the broader industry though. There are far more devs working at former Java and .NET shops that have never written a single line of Ruby and are all in on JS/TS now
What you are saying is hyperbole. They are "All" in JS/TS now? I never said JS wasn't bigger than Rails, but Rails was the first and biggest axe to fall against Java. JS just took the baton from them
I said they've gone "all in", not that they're all using JS/TS now
Not where I am. Maybe a peculiarity of the community I'm in but here it was all Node all the time after Java was declared uncool.
Java took a ton of heat in 2005-2009 (before Node existed) because Rails came through and was eating it's lunch. It's the reason that a huge percentage of the successful Web 2.0 companies were built using Rails, not Java or .NET.
When java shut it's door to me. When c++ gave me the cold shoulder. When mvn was very confusing for me. This little language became a cozy home for me
As someone who did Java WebApps for 10 years - they sucked if you cared about making a good user interface.
I thought JS was bad at the time, but node.js was a breath of fresh air for API development, and client side JS has been fine for like 10 years (assuming you care about UI development).
I'd never go back to Java except for maybe some backend service away from the UI.
Hot reloads?
https://tapestry.apache.org/development-dashboard.html
https://tapestry.apache.org/service-implementation-reloading...
Java was not abandoned en masse. Small projects were done in node.js. Large projects were and still are done in java or other non-js languages.
At Oxide we use OpenAPI schemas generated from the server code to generate clients and it works quite well to produce the DX you describe despite different languages on server and client. OpenAPI has its frustrations, but it’s good enough.
I like to say that the main value of GraphQL was never really in the dynamic queries (in many ways an anti-feature) but rather in having a nice typed spec that lets you generate typed clients.
https://oxide-and-friends.transistor.fm/episodes/the-fronten...
OpenAPI, protobuf, etc. There are a lot of options that don't even require TS.
This is where OpenAPI/Swagger shines, we use C# backends and with NSwag (built in now also I think) you get an online API-spec directly from the controller (and types) of the C# code.
Only extra step is running a tool to download the swagger and produce auto-generated typescript definitions, otherwise the workflow is the same as shared code (Some projects are typescript on both ends but C# gives a ton of other benefits for backends).
My recent experience with NSwag was really bad... It could only handle the simplest of jsonschema. We were trying to connect with a typescript API that had heavy use of union and product types. Maybe the problem was just that C# doesn't support algebraic typings?
That would track, one of the few things I miss when writing c#. Instead you break out into interfaces as much as you can.
Yeah, the C++/Java/C# family of type systems have obvious holes in them. There are various hacks/implementations for them but since they're not in the core they're not really expected to be supported by random tools either.
Like mentioned, our regular pipe is C# producer (server) and TS consumer (client). Consuming services authored in Java,etc is usually not a problem either but the TS system definetly has a bunch of more cases that aren't easily mapped.
This is what we do. We use kiota to generate clients within other C# services, and orval to generate a client in the frontend. We also run some basic checks against the openapi definition in branch, to detect breaking changes and whatnot.
This is the nice if your only consumption of the frontend is first party.
Alternatively you could go the openAPI route and declare your API as a spec with types for a client to consume and the endpoint to return. This works cross-language and gives you docs first. (Start from the docs, convert that to types, then implement).
I just wish YAML wasn’t so unwieldy for that, especially given the overall complexity of the spec.
I also thing that the tooling hasn’t kept the same pace as it has with graphql, where it’s easy to document your schema and the inspector makes it super easy to play with.
You can write OpenAPI in JSON, which can help a bit with encompassing the complex and frankly fractured ecosystem of OpenAPI.
I have found that the tooling tends to have the problem of not knowing how to catch edge cases like webhooks, websockets, complex auth and additional logic beyond just an HTTP request. Many tools add layers of configuration and extension to work around these, but i feel it misses the mark.
I'm building Borea.dev to solve this pain by keeping the source of truth in your OpenAPI doc and allowing for custom code implementations. We support Python rn, are building out generators for multiple other languages and we're open source :P hope it helps
You can write/generate OpenAPI in JSON. There are also many GUIs out there
Typescript and Rust may be more similar in this regard than you think. Both languages are born out of the desire to make coding simpler by making a stronger, more expressive type system. Sure, the details differ: Rust has lifetimes and about 8 number types, Typescript is garbage collected and has about one number type. But the spirit is similar. Both the typescript ecosystem and the rust ecosystem love the idea of taking types and function signatures and providing them for downstream consumers.
While I haven't gone too deep down this particular rabbit hole, if you build a Rust backend you can use function signatures and annotations to automatically build an OpenAPI specification for it. You can then consume that specification to automatically build a typescript client library, giving you an automatically updating Typescript interface to your Rust backend.
Similarly, there are multiple projects to automatically provide python type hints for your Rust python extensions. None of them really production-ready yet, but this is something people are actively working on for quite a while
THis is very similar to what Oxide.computer has done. They wrote their own tooling to go from Rust API to spec to Rust and TS client. Very specific to their use case, but I think its the right approach. If something is wrong in the client, you probably generated a bad spec, and therefore something in the API is rotten and should be adjusted. Using the spec as an intermediate to know if upstream is bad, can be a great benchmark for developers. My co-founder and i have a long term goal of building an end to end tooling chain for OpenAPI to generate spec and clients/tests/docs under one roof. Its definitely far off in development, but think its where devs are moving
You can achieve that with OpenAPI using any backend language.
There are tons of generators that can create a client with types from an OpenAPI spec. Not only to/from TS but also tons of other languages.
I thought the same but recently we started using .net on backend and openapi to generate typed api clients for typescript. I mean the initial setup was 15 minutes longer than a full stack typescript app but I get to use .net on the backend and all the type safety on both sides.
> Sharing types between React and a Typescript backend is great DX for developing both in parallel and I've not seen anything that comes close to being as enjoyable. Being able to change the signature of an API endpoint and immediately having all places in the codebase where the change will cause problems flagged as type errors is wonderful.
Have you ever seen Scala.js? Same language on the frontend and backend, in a way that actually feels first-class and real. Type system that's as powerful as Typescript but also sound. Full IDE functionality if you need it.
Maybe that’s because you only know one language and focused on using that everywhere.
I have worked at 2 of those named companies where people made conscious decisions of moving away from TS backend because JS is an awful language to be used for system critical things.
Care to expand?
I've been writing backend TypeScript for 8 years and it's more than fine.
It's not my favorite language but it's a great compromise, and I would never choose a Lisp, Haskell, Java or C over it (the other languages I know).
JavaScript, in general, is awful as a language in terms of design, and more astute people have wasted many words on this before me.
It was originally designed for writing throwaway frontend code, but people liked it so much that they started using it to build their system architecture—only to realize it doesn’t work well for anything beyond glorified RPC backends.
The type system is wishy-washy, and TypeScript needs a massive type space to compensate for it. Python is also dynamically typed, but it has a strongly typed system that saves you from runtime blowups. JavaScript doesn’t even properly blow up at runtime—you just get [object Object] or some random undefined error. TypeScript is a fantastic piece of engineering from the C# guy, but even they couldn’t fix all of JavaScript’s language-level blunders.
Few people want to build mission-critical backends on a weakly typed language.
The ecosystem is a mess, and things randomly break after a few days. My Python and Go apps from 2018 still work exactly as they did on day one. Go’s gorm and Python’s SQLAlchemy are the default ORMs that pretty much everyone uses. And how many ORMs does the JS ecosystem have?
And let’s not even start with frontend frameworks—no one loves them two days later.
The Next.js project I built yesterday is already showing 69 vulnerabilities. This sorry excuse of a language, coupled with terrible design and an indecisively childish community, makes it difficult to take seriously.
You're throwing random things but you have failed to explain real world pains.
By the way you can be extremely strict and safe in typescript, it's really up to the team using it, but you can encode virtually everything and have it fully type safe.
Also, there's great tools like effect-ts if you're more functionally leaning.
If you really want to waste time on types, the bolted-on TS is never going to work as well as Golang where they're native. Maybe TS types are better than Python types is all.
Golang's type system is not as expressive as TypeScript's.
It's fine to not know about the goods in the TypeScript ecosystem.
Again, I recommend you checking libraries like effect-ts or effect/schema or even better trying them.
https://effect.website/docs/getting-started/why-effect/
To be honest, I don't like the look of Effect for the same reason I don't like error handling in Golang. It's easier to assume anything can fail (which is 99% correct) and use exceptions. But anyway, every language can be extended in many ways, so I can really only compare default vs default.
In common JS or Py use cases, static typing makes your code less safe, because all that extra time you spend on it is less time writing tests. Meanwhile the types won't catch any bugs even the most simple test coverage would.
Sure, JS has some quirks that language design gurus complain about, but nothing that actually matters on the job. Like, == operator is weird, oh well.
Python is rightfully king for certain things like data science, but parallelism and package management are two big messes in it. ||ism is trying to be fixed with asyncio, but it's kinda too late. You know packaging is broken because every Python repo has a Dockerfile, not something you see in JS where npm is solid.
Golang is more for different use cases. Looks good but really should have done error handling like Rust, or used exceptions.
> npm is solid
sure it is
It's solid enough that people don't fall back to Docker.
> My Python and Go apps from 2018 still work exactly as they did on day one
My NodeJS apps from 2014 still work exactly as they did on day one as well, what's your fucking point?
My point is that the JS ecosystem is masqueraded by script kiddies who will throw a hissy fit every time someone criticizes JS, and you just proved that ;)
This is an embarrassing comment, there are few things this world needs less than more smug engineering tribalism. Even weakly typed languages. Typescript has many downsides, as does Python, and if you think the downsides of Python are trivial then I would invite you to take a look at the sea of different competing tools for environment management. I need a python env, now will that be with pyenv or venv or pipenv or pyvenv or virtualenv or poetry?
I’ve been writing JS and then TS on the backend since 2013. Built large apps, startups and while it does the job fine I’d not go with Js on the backend anymore.
We built some stuff with Go and then went with full .Net. Its like fresh air after years of Js.
What exactly did you like better in .Net than in TypeScript?
- Proper static typing. This is not .net specific but bolting types on a dynamicly typed language only works to some degree. It also opens the gate to runtime type intospection such as generating OpenAPI definitions without any other input than the handler signatures themselves etc. This is handled fine by a full stack ts framework like next or nuxt and such but you are still trapped in that implementation.
- Proper multithreading and performance story. Performance itself is not the most important thing when your app mostly waits on IO. However you still get to use thread pooled async in .net or parallel goroutines in go etc and they sometimes make a difference.
- ASP.NET Core is fully feature packed and easy to work with. .net has a more cohesive ecosystem where tools, libraries, and frameworks are designed to work together seamlessly. In js runtimes, you often need to piece together different approaches and deal with compatibility issues.
- Proper standard library. Both node.js stdlib and the js globals are really weak compared to what Go or .NET or Java etc provides you out of the box. I hate dealing with npm dependencies with a passion at this point and you can have minimal dependencies when the standard library is decent. There is also the fact that upgrading an npm package is a dice roll as you need to trust the semver or check update logs etc. At least with a static typed language you get to catch public api changes on your dependencies during compile time, not in runtime.
- Linq is good, Linq expressions are great. I don't really love ORMs but I tend to use Entity Framework Core on top of low level SQL access in .NET. Makes life easier.
I don't hate TypeScript though. I still use it on the frontend obviously and I'm fine with it but given the choices on backend, it does not make much sense for me anymore.
I know about 10 languages by now, and JS is one of the later ones I learned. Nah, it's the best at what it does. And if I drew a graph of every project that's moved from language A to B, it would have cycles.
How can you deploy a system where you are changing API types in a way that breaks the type checker?
It seems like in almost all cases, you want to evolve in a forward compatible manner, with a very slow deprecation process.
Interestingly (relevant to the linked article), you can also do this in Rust.
There are legions of languages that can be transpiled into JS. Use any of them both for back and front-end and suddenly, not only can you use the same types but also the same functions.
Title should really be "Rust Is Eating JavaScript Tooling".
Except for a nod to WASM, all the examples are about the JavaScript toolchain.
This is where Rust shines, CLI tools where a ton of processing needs to happen and execution time is extremely important. For almost every other problem, the amount of computation is much lower and/or the execution time isn't as important.
Indeed, no sane JS dev would jump to Rust bandwagon, even if he’s very fond of TS.
Besides Bun is not Rust even though Deno and some tools are. The JS crowd generally does not care about coding Rust, though would welcome faster tools which are sometimes rust based. Also Go based and even Zig based.
Additionally if one cares about performance, I would much rather write C++ than Rust, as that is directly supported by V8 tooling, without adding even more additional layers to debug.
I'm the author of one of the WASM-JS frameworks listed in the article. I now do frontends mainly in HTML + CSS + JS.
I think the future of JS is going to be a lot like Python - you write your code with JS libraries because of the ergonomics, but critical pieces of those libraries are implemented in WASM under the hood.
For example, you’ll still write your React components, but the React framework itself might be written in Rust and compiled down to WASM to make everything snappier (e.g. DOM diffing).
I personally really love this pattern because it strikes a balance between speed and DX. Not everything has to maximize performance, and not everything has to maximize productivity.
Like libsodium.js and pqcrypto.js. They're distributed as single self-contained JavaScript files, but under the hood have wasm embedded using the emscripten SINGLE_FILE flag with an asm.js fallback.
Clickbaity misleading title. Should read "Rust is Eating Javascript Tooling".
Rust is pretty good for command line tooling, news at 11.
Tbh I would much rather write utilities in Go. The advantages of Rust are minimal here and the disadvantages are an obstacle. Last time I wrote a CLI in Rust it was a search index builder you could pipe CSV to. Awful DX. Go is almost too easy for that kind of thing.
Yeah, you don't need/want manual memory management for most CLIs.
If anything I’ve actually seen people using the OS’s virtual memory as a garbage collector in C and C++. Not really portable everywhere, but close enough for most people. For short-lived executables that can’t really allocate unlimited memory, it’s perfectly fine.
I've done that. But in those cases, GC would also be fine. Might even end before it collects.
oh fer sure
It’s eating Python too - with Ruff, uv, and an upcoming alternative to Mypy:
https://bsky.app/profile/crmarsh.com/post/3lgvhzdfrps26
It's true, but the absence of adoption of these great tools in industry worries me. Most Python developers in industry don't seem to care one iota about handling corner cases of types, and so their code is full of problems. Most Python developers in industry are very untrained, and have no discipline when it comes to types. It makes me sad while working in such a setting.
> the absence of adoption of these great tools in industry worries me.
UV is a year and a day old. It's not surprising that there isn't huge industry adoption yet.
I sort of have the impression that Ruff does have a reasonable degree of industry adoption. Certainly linting does.
There mypy alternative doesn't yet exist in a usable state
I'm not seeing anything worrying here?
mypy and pyright have been out for so long, and they're in a pretty usable state. Ignoring to use them leads to buggy code that shows its ugly head as unhandled rare conditions begin to manifest themselves. The compounding effects of these unhandled rare conditions ultimately ends the project when the lead subject matter expert exits the team.
A large amount of important Python libraries are still missing a good amount of typing - and dealing with third party typesheds is not a good developer experience. The implementation of types in cpython has also been glacially slow and fragmented.
To add to the issue, a huge amount of Python in public repositories is untyped and unversioned- which means that LLMs are pretty bad at getting typing correcting in Python, so the debt is growing much faster than the solutions.
I honestly think that the most viable solution at this point for typing is a typescript-adjacent solution for Python. I’m kind of surprised Microsoft hasn’t put one out yet
I don't know, ruff and uv seem to do great on the adoption. Of course speed is the perceived killer feature, not "types".
Speed and types are different topics. Types are valued by mature programmers who recognize that maintainable and comprehensible projects require aggressive use of types. Short-term thinkers will not value types, and will lead to rapidly decaying and eventually unmaintainable dead projects.
I think what will happen is something like numba gets more use. Bad developers can keep writing as they do, but critical infrastructures and functions will be written in natively compiled numba/python code.
I don't think I could agree less. Numba has always had too many errors, bugs, and too inconsistent of a performance gain. Moreover, Python has always been a glue language where numerous packages interact together to form functionality, and this glue usage makes no sense with Numba.
Most of the article appears to be discussing Rust being adopted into the JavaScript toolchain as opposed to directly replacing it in web development.
So it is actually both eating and excreting Javascript.
Eating JS but excreting WASM, little bit of progress at least?
Babel, prettier, and oxidase for a few examples all output JS. JS -> WASM doesn't tend to be very useful as WASM can't hit the DOM or most APIs.
A better title would be "Rust is Eating JavaScript Tooling"
LOL, no. Rust is not eating javascript but COMPILED languges are, and only in the build pipeline. Rust does not matter, even Go is far more superior than anything in JS land.
Eg. My webpack builds in 35 seconds. The i try esbuild and it does the same job in 35ms. Insane! Ok now lets try rust, now i get 20ms. Wow!
Do i care about 35ms -> 20ms? Nope, not one bit. I just want it to compile under 1second.
This could use a (2021)
The article really needs a date too.
It talks about projects like Rome as if they're current when Rome was archived a year and a half ago: https://github.com/rome/tools
I think it used to have one but it was lost in a site redesign a few months ago: https://github.com/leerob/site/pull/727/files#diff-888ddb306...
Note that Biome https://github.com/biomejs/biome is alive and well.
Rust lacks major financial backers for the tooling ecosystem. This leads to a huge number of ambitious projects which are abandoned when folks get bored.
I have no inside knowledge but the speculation I’ve heard is that this was not about a lack of funding per se so much as what happened to the money.
E.g. https://news.ycombinator.com/item?id=35930310
A single startup with fickle founders/investors is not a reliable source of funding.
C/C++ developed thanks to the effort of hardware, kernel, and os makers who invested billions into its development. Development of the JVM once occupied the effort of 10k engineers at SUN. JavaScript has a complex history, but has received significant investment from Netscape, Mozilla, Facebook, Google, and Microsoft.
Rust needs one or two singular players with 5+ billion to spend supporting and improving devs lives. The nascent efforts I’ve seen so far are just that - nascent.
I don’t want to actually get into a “which is more” argument because I think historically in total you are correct, but Mozilla, Facebook, Google, and Microsoft are some of the largest financial backers of Rust.
Yes :) however Mozilla is in a mixed state today, FB/Google/MSFT are interested in Rust to modernize legacy code bases - but I don't see the same kind of Rust artifacts coming out of these firms as they produced for JS (React), or Java (Guice). Perhaps they are still tinkering on this point, but something doesn't add up.
Yeah it’s just early and different; Google gave the foundation a million dollars to work on rust <-> c++ interoperability last year, but that work is still ongoing. They do put out projects but they’re not as dominant in the ecosystem as React became in JS, for sure.
Not really: https://voidzero.dev/posts/announcing-voidzero-inc
It has been updated in 2023. What could be the correct one?
The bulk of the article was written in 2021. There's a short update section at the end that says "Update: 2023".
2023 is also fine. When I posted it did not say 2021 or 2023 which made it look recent.
God this comment thread is a series of unsubstantiated subjective opinions trashing languages that people don’t like and ignoring the faults of the languages they do….
Why must we rehash this type of post every few months?
the poll mentioned https://x.com/devongovett/status/1261379312898306048
was between (js) and (go/C/rust)
See the problem to me is that this comparison isn't nice. Javascript comes with a lot of its problems , so of course people would want go / C / rust
but Now the author thus concluding that people want "the fastest" out of go/C/rust is just wrong.
I love golang.
People like fast software but hate abandoned software even more . Yes there are rustaceans who would love the project but now hand anybody genuinely interested to contribute a rust project and ask them to learn rust and they would come hating at you.
And now ask them to learn go. They can actually much easily do that.
I stand with this opinion that go code can be read / written by anybody. There is very rare bad go code but rust code feels "magic" to people.
Admire simplicity. That being said , I use archlinux with paru instead of yay , I use a lot of rust tools as well.
To be honest , to me it doesn't matter that much , what matters is if its being maintained stable / has active community. It could be written in any language just make it easy to embed / provide bindings for major languages like python node golang etc. Or though this might come overkill but I wish if there was some sort of glue code which can bridge languages , most of these glue code libraries end up having so many use cases. so I like the idea of wasm but its just not that performant. If we can have insanely performant wasm ...
I learned golang and rust, and I can say that both have significantly different concepts from other "conventional" OOP languages that it's not just learn new syntax approach.
it's of course very subjective, but for me golang feels more magic, especially with importing GitHub repositories like local files.
The easiest language is of course the one you already know.
i would also argue that it's easier to write bad go code (I personally wrote some of it while learning) in rust usually if it compile and your are not using unsafe, it's at least ok quality and clippy is great with guiding you how to improve your code.
to be fair JavaScript also is weird and different than OOP languages but from some time it tries to feel more traditional with classes and this handling.
wasm is already fairly performant in comparison to native code, it might lack in come cases like simd (there are extensions already, but I'm not sure about adoption) but generally it's only about 20% slower than native binary.
I'm not sure how much wasi is practical for cli tools, but using was for plugins to allow any language someone might be comfortable with seems like no-brainer to me (also isolation will allow you to control potential memory leaks and crashes so your application will not get corrupted or anonymously destabilised)
> Admire simplicity
That would be nice. Instead we’re seeing all these JS/Python tools written in Rust - a complex language whose complexity comes providing memory safety without garbage collection.
Their authors are deliberately choosing to take on that complexity for programs where it’s unnecessary - programs which would work equally well with a GC.
The overwhelming majority of Rust borrowing complexity can be trivially solved by just doing .clone() which is basically all those GC languages like Go and Python are doing themselves anyway. You can avoid the borrow checker altogether if you want to, and a lot of people do. It will still be much faster than go or python just due to the lack of runtime overhead and GC
My impression is that the JS guru crowd is made of cool kids and very sensitive to what’s in fashion this week - and that’s definitely Rust.
Here on HN there is plenty of announces of new things “like X but in Rust” - even when X would be fine in Python or Bash.
This is inflammatory and myopic.
The reason Rust and Go tooling is getting popular is because they are appropriate for the job.
C and C++ are riddled with footguns and non-ideal for this kind of tooling, Ruby and Python provide only disadvantages compared to current JS tools, Haskell and OCaml are good but too niche. And so on.
And the reason Rust and Go are getting usage in WASM is because they have a good WASM story. They are static, compiled and born at the right time. Other than C and C++, they're the only ones that put the effort.
The reason people are making projects in Rust and Go is because they are accessible to those people. For me both hit a sweet spot that none of the languages above do.
C++ was also very popular and fashionable at some point. It also promised better type safety and better memory management than C. Now, 20 years later, it's easy see that C++ didn't deliver on all of its promises about better abstractions and object oriented productivity gains. RAII promised to make race conditions, memory leaks, and use-after-free bugs a thing of the past. The C++ hype was relentless and a very loud minority argued every C project should really adopt C++. Thankfully, a handful of grouchy naysayers stuck with C.
Fashion and hype has always played a big role in software and our industry has at times unwisely abandoned good technology in favor of the 'New hotness'. We gyrate between local apps and cloud apps, thin and thick clients, static and dynamic typing, micro-services and monoliths, relational databases and keyval stores. Our industry is not very rational and the best tools don't always win. Marketing and market effects (winners keep winning) play a big role.
Recognizing the role hype plays in our industry is not myopia.
I will keep calling it myopic and inflammatory, and I will add disrespectful to the list.
The things people are shipping in Rust are stuff Rust is good for. As far as JS goes: mostly tooling.
Notice how virtually nobody is shipping websites in Rust. Sure there's frameworks and async, but we're not there yet.
The fact people are building libraries for servers, websites, gamedev, etc, in it is something that is required for experimentation.
People don't deserve the disrespect shown here for exercising their curiosity and trying to advance the field.
I would not take the time to add my little voice to the ones that express their exasperation with rust, if not for the scornfull tone of your message.
We all know that rust has a lot of merits, in that it is trying to establish a different, ambitious new trade off wrt. safety ganranties vs expressive power, and as a result is one a the few serious contender to replace C++ in the very areas where C++ is king, trading just a bit of performance for a vastly more sane language and better static garanties.
But it is also fair to acknowledge that more often than not, in the many "old_thing but in rust" that are being posted on HN, the old_thing at hand does not actually fall in that very important but also very small subset of programs that can not tolerate automatic memory management.
In other words, rust was not the good choice from a technical stand point.
Maybe it's particularly obvious to me because I have tried to promote rust before it became cool? At that time my coleagues could only tolerate Python or Go. These days the same people probably program in rust (or are at least considering it), and that's not because rust improved that much, or because they have sudenly learned to use the right tool for the job.
I will keep calling this attitude negative and disrespectful, because it's belittling other people's work, curiosity and experimentation.
A lot of the things being posted in HN are not products but rather small-to-mid-size programs written by (quite often) experienced developers trying out a new language and somehow managing to scratch theirs or someone else's itch. On top of that, they are learning and we as a community are also learning from their hits and their misses.
A lot of things, such as WASM frameworks, are heavily experimental, and in this very thread there is an example of an author of those saying they're back to working JS. This is fine.
I would be totally fine with comments like "Rust is not good for this" or "Go is not good for that", and I have given some examples myself above. But this is clearly not what's happening here. It's ok to not want to participate on something, but the vitriol and flamewar-bait on those topics is not that.
Well, I agree to all of that, I just don't read the same thing as you do in those critiques. To me, they do not sound like belittling authors who post here (frankly, of all languages that are used just because they are trendy, I much prefer that it's rust than any of the many runtime typed evaluated languages that used to be popular in the past).
To me the actual target of those critical comments are not the projects at hand but rather that trend in our industry to let popularity lead our decisions, and how easily we form small chapels that fight each others instead of encouraging learning and practicing several competing techs. Not that it will change anything, though.
It's worse: the target is always the people, not even the projects. It would be fine if there were any actual criticism, but it's just name calling all the way.
And the top level comment about "cool kids" I answered to definitely doesn't have the nuance you suggest it has, nor does the flagged comment comparing it to a religion, or the comments calling people "hipsters". And this thread here is actually better than average.
Fair enough. I'm glad we have both made the effort to explain why we feel the way we feel.
As someone that was around for the C++ hype, it was designed as TypeScript for C, and many of the reasons why it didn't deliver was exactly those C refugees that kept writing C code, but now with a C++ compiler.
It is no different than those folks, now 20 years later, that adopt Typescript, but really the only thing they do is to rename the file extension, and keep writing plain old JavaScript as always.
Why not Java? Shouldn't it tick all the boxes?
JVM is like the Cologne Cathedral of the software world.
For a developer tool? Genuine question, how long does the JVM take to start? It used to be slow, but I don't know what it's like now. Check out the speed comparison of a few linters on this page -> https://astral.sh. Would the JVM start before the fastest one finished?
And supposing you took start time out of it, how long would an equivalent Java program take to run?
Memory isn't as much of an issue, but all other things being equal users do prefer the program that consumes less memory.
Zero-ish now.
Isn't Java a memory hog and historically also exceedingly verbose?
Performance and memory usage are worse than Rust/Go.
Worse than Rust, yes, worse than Go, not really.
Java doesn't do cooperative multitasking (sorta aka greenthreading). That's why there are all these promise/future/whatever frameworks that do it, vs Golang, Rust, and even JS where it's just part of the runtime.
Pretty sure JVM is also a lottt more overhead.
Yes it does, that is why originally there were green and red threads, the language specification doesn't require which kind exactly a JVM implementation should provide.
Also since Java Loom project, it has virtual threads.
Additionally, since at least a decade you could your own thread scheduling if feeling so inclined to do some low level coding, as the scheduling architecture is customisable.
Greenthreads were abandoned long ago and aren't present in any mainstream JVM. I don't know about Loom, seems recent (or upcoming?) and specific to OpenJDK.
It is specific to any JVM vendor implementing Java 21 (released 2023) and later. Java 24 is around the corner.
For CLI? Absolutely worse.
A skillset problem, not knowing the ecosystem.
Not really, with Go it’s braindead simple. Why would you want to jump through hoops to match performance of Go? For the sake of using Java (lol)?
I rather use tools not stuck in jurassic time of programming language design, again, Go's performance is behind most Java implementations.
That wouldn't be true for gccgo implementation, but then again, it is now abandoned in pre-generics Go, stuck at version 1.17, no one seems to care to update it.
You can build a CLI in Rust with a better performance and runtime guarantees with far less skill and have a better time doing it.
Java doesn't even have null safety or ergonomic algebraic data types.
Scala and Kotlin also exist, and Rust's place is for systems programming not CLI stuff.
Besides people here sometimes have a hard time understanding English, given that I acknowledged Rust being faster.
Your assertion that Rust isn’t well suited for command line programs contradicts reality, where developer tools for multiple languages are being rewritten in Rust. The new bundlers, linters and formatters for JavaScript and Python (the most popular languages by far) preferring Rust and gaining massive adoption tells me that Rust is pretty well suited to CLI programs.
And the success of ripgrep, mcfly/atuin, zoxide, hyperfine and starship, just reinforces the feeling that yeah, CLIs written in Rust can succeed.
So yeah, strongly disagree with you about Rust’s place.
But from your previous comments I also know you’re very knowledgeable about Rust so I’m surprised you came to this conclusion.
Don't mistake Rust Evangelism Strike Force, and joining the hype cycle, with the suitabitility for writing CLI developer tools there is nothing there that requires the use of borrow checker.
Depending on how many years into the past of HN headlines we would search for, it would be Go, Scala, Haskell, Ruby,...
Maybe all those Rust CLIs will be all being rewriting into Zig, as soon as version 1.0 gets out.
Roc language is already one of the first.
I've been on HN for a while, I saw the previous hype cycles. I have no doubt we'll see a Zig hype cycle as well.
One of the reasons Rust succeeded, especially in CLI was
1. Low fixed memory overhead (compared to most popular VM based language - Python, Ruby, Java).
2. Startup time is nearly instantaneous, compared to the same languages. Don't have to wait 50-100ms or so just to start executing code.
3. Run time is faster as well, especially so for programs like ripgrep that use SIMD.
4. Single static binary with no dependencies. Didn't need a VM or toolchain to be installed on the user's computer.
Having a great CLI library like clap.rs brought it all together.
If you think this is simply a cycle and Zig will replace Rust, I'm slightly skeptical. Rust had an easier time competing with the status quo because of the 4 advantages it had.
Zig however, will have to compete with Rust. Sure, you can start ziggrep, but it'll be about equal in all these 4 factors. So why would anyone adopt something that has fewer features than ripgrep and about the same performance, memory consumption and ease of use? Just hype? Some people will, but not enough to get the critical mass ripgrep has.
That's why I'm bullish about Rust - the performance of existing codebases means that in many cases, it's hard to migrate away from it, or replace Rust programs with reimplementations. You'd have to be getting something really unique that Rust doesn't offer. You said Roc, and Roc is actually a great example of benefiting from something unique. Roc plans to reuse the Zig compiler's library that emits LLVM bitcode. There's no Rust equivalent.
But I'd argue that that's pretty niche. How many other examples are there of Zig libraries that have no Rust equivalent? Something that would make Zig the no-brainer choice over Rust, even if you had to reimplement in Zig.
Again, I'm sure people will try to rewrite things in Zig. But I'll confidently assert -> the most popular toolchain for Python in 5 years will be Rust based, not Zig or any other language. $10 on that.
I think a really important benefit is going to be binary size. That's what initially made me dislike Rust quite a lot.
And for CLI tools, you need those to be tiny. You're going to many of them, and you'll want to build a whole distribution, which you'll want to be small (for small images, small containers, etc).
Another benefit (that Zig won't offer) is good shared library support, which distribution maintainers will always prefer. I don't think there's a good language for that, but if one will appear, it will definitely be favored.
As ripgrep's author, I think binary size is important, but I think it's simultaneously a niche concern. Saying that they need to be tiny is I think a pretty big overstatement. They might need to be tiny in specific use cases, i.e., niche. But the 99% use case is probably that most users don't care. ripgrep's binary size is already pretty meh (especially compared to similar tooling that relies more heavily on dynamic linking). My guess is that if its binary size doubled even from what it is today, few would notice and even fewer would care.
AFAIK, ripgrep's biggest deployment is through VS Code, by far. Nobody is going to notice that some part of VS Code is now using 8MB instead of 4MB (or whatever it is, I think it's around that). It's largely a non-issue from my perspective.
Now, compile times... That's a different story. I'll happily complain about that one.
> But the 99% use case is probably that most users don't care.
For 1 really good utility like ripgrep, yeah. You'll convince many people to use it based on its merits. You might even have 5 or 10 of these utilities, if they're really good.
But for Linux system builders, for the things that go into standard distributions, where you need hundreds of such utilities, Rust CLI binaries are simply not sustainable. Not for size, not for security, not for simplicity of bootstrapping, nor, as you said, for compiling an OS from sources.
You will be able to get ripgrep into many distributions, but it will be more unlikely to become one of the tools installed by default for that reason.
> You will be able to get ripgrep into many distributions, but it will be more unlikely to become one of the tools installed by default for that reason.
Oh I don't agree with that all. It might be a factor, but it isn't going to be installed by default because grep will already be there. Unseating a POSIX user land in a Linux distro is not going to be blocked just on binary size IMO.
I also think what you're saying is not inconsistent with what I'm saying. The default tools installed on a Linux distro is a niche use case. ripgrep doesn't need to be installed by default in any Linux distro in order to be successful.
If you're setting out to build tools to replace, say, a GNU user-land to fulfill POSIX (or provide an entirely different sort of user experience), then binary size is probably the least interesting thing to overcome. And if you "try" hard enough, Rust binary sizes can be reduced quite a bit. ripgrep being 4MB is the result of me not caring at all about binary size (beyond stripping debug info). But this is a niche goal IMO, and IMO does not support your initial claim:
> And for CLI tools, you need those to be tiny.
Notice how if you instead said:
> And for CLI tools that are installed by default on a Linux distro, you need those to be tiny.
then it takes almost all the air out of your comment.
Then you use Rust. shrug
Rust is for kernels and low level systems programming where a GC isn't allowed to play ball.
Oracle. It’s only a matter of time when its CEO decides he wants to buy another Hawaiian island and sics his army of lawyers after everyone using it.
Others have answered but: Java had its chance and it was demonstrated time and time again that it is much better at other things.
There is probably no language in existence that "ticks all the boxes". And this is good.
Well, Rust has a good WASM story, Golang doesn't.
I’m not sure if calling Rust “what’s in fashion this week” is accurate since it has been common for at least five years (if not longer) for posts that include “in Rust” to blow up on HN.
It has been the Most Loved/Most Admired language on Stack Overflow’s developer survey for 9 years in a row. I know that’s a relatively short amount of time for a programming language, but to me it seems like it has some serious staying power.
Maybe, just maybe, some of these "kids" know what they're doing and are preferring Rust for legitimate reasons other than fashion - such as performence, memory safety, and type safety.
Rust is legit for use cases typically served by C, C++, or maybe Java. I get more skeptical when someone's trying to shoehorn it into some other use case.
JS is an old and mainstream thing at this point, though.
This post is four years old!!!!!
JavaScript never should have been used for those things in the first place
Not sure if I agree with the article. I saw this YC company recently and I think their vision for NPM install "fullstack app" is compelling: https://www.ycombinator.com/launches/Lkp-freestyle-a-new-way...
I wish F# took off like Rust. I know they are very different. But it invokes same 'feel', and have a lot of same benefits.
Well, it always felt like Microsoft management has repented themselves to have added it to Visual Studio 2010.
Rust is great, but it's not like it's "fast" to develop in. JS, Python, and Go are all languages that can move a lot faster because you have less rules to follow. Maybe an _expert_ Rust eng can move just as fast, but you'll still move as slow as your slowest team member most likely
Heck even C can be quicker to write in than Rust if you don't care too much about safety and don't need the nice Rust libs. I've been there.
Just because a language doesn’t have a garbage collector doesn’t mean you don’t create any garbage to collect.
Not sure I understand what you mean by this. Rust doesn't create "garbage" in the technical sense. It has RAII. It's a different thing.
Parsing a JSON document for example will create an unknown amount of temporary heap allocated objects, that later will need to be freed up.
I think you're confusing "garbage" with just normal heap allocation. Rust will free that memory automatically when the JSON strings go out of scope. There's no "stop the world" thing that periodically scans and deletes stuff while your program is running like in Go or JavaScript. Because there's nothing to delete. There's no "garbage".
At least reference-counting is typically considered a form of garbage collection (e.g. using Rc<> or Arc<> in Rust, or std::shared_pointer in C++). Arguably, RAII calling destruction code at the end of a scope could also be considered garbage collection, the garbage is just very short lived ;)
I guess 'automatic memory management' is the less controversial term which covers both traditional GC and RAII, the downsides are very similar though.
It's different because the free() is deterministic, the instruction is encoded into the binary. Completely different than garbage collection where there is a whole runtime that has to periodically go figure out what can be safely deleted and what can't.
For one-shot programs like Babel, Prettier, Terser, etc. mentioned in this article, I don‘t see how the lack of a garbage collector is a strong argument for an alternative language.
Nobody is making this argument for JS tooling.
The article does mentions GC, but that's just demonstrating differences between JS and Rust.
The other popular JS-tooling alternative is esbuild, which is built in Golang, which has a GC.
If anything, the two most common arguments in favor of Rust for this specific use case are null-pointer safety and speed.
The article honestly doesn't make any sense. Even the title is wrong.
This is a strange distinction. So something is garbage because it is not used? In Rust, a Vec is only deallocated at the end of the function, regardless of when it is actually stopped being used. Are those garbage too?
At this point, garbage just means whatever does not follow RAII. And RAII is not the best solution either. For throughput reasons, GC languages can be siginificantly faster exactly because it doesn't have to clean those "garbage" at every step.
> GC languages can be siginificantly faster exactly because it doesn't have to clean those "garbage" at every step.
Which GC languages are significantly faster than Rust and C++?
It can happen in practice. For example, I see a lot of C++ code with extra string copying that would be hard to avoid. Like if some func takes a const vector<string>& and you have a string in any structure besides a vector, you're gonna copy that string.
(of course Java's pointers-everywhere approach has downsides and is generally slower, but there are scenarios where this works to your advantage)
So a theoretical GC language can hypothetically be faster than Rust or C++.
Which language? Does one exist?
It'd be Golang if anything. Java might have too much overhead to be faster than C++ without negligence, but that's not because of the GC.
You can avoid this with custom allocator in C++ for example, you don't have to actually do memory work at synchronous time (aka in destructor)
Thanks, this exactly my point.
Sure, what's the issue? Do you think that there is an algorithm that a) does not do this, b) can't be implemented in rust, but can be implemented in C or other language?
The issue is that GCed languages get a bad rep, while the amount of allocated and freed objects is the same in GCed and non-GCed languages.
Yes, but that is not garbage.
WebAssembly is still very limited and not a "first class" language in browser, not sure why..
…if there’s a “why”, maybe it’s because WASM can’t interact with the DOM and the debugging experience isn’t very good.
The DOM API is defined as a JavaScript API. The browser, JavaScript, and the DOM API have been evolving in parallel for over 20 years. If you want to interact with the DOM from WASM, what you can do is write a function in JavaScript that interacts with the DOM, and then import that function into your WASM module.
At least for now.
To further explain: the standard WASM ABI is essentially just a C ABI, so you can pass integers and pointers around, but you can't do much more; anything more complex needs to be built on top of that, which precludes binding to the DOM API directly.
The existing workarounds for this glue the JS DOM API to the guest language through glue on both sides, but this means that you have to pay the penalty of marshalling through JS for every single call you make.
There's a solution in the works to make direct interaction possible, but it's proven to be quite challenging to finalise: essentially, you need a high-level ABI that can provide a safe and fast interface between the host and whatever guest language, and defining that in a way that makes everyone happy is non-trivial.
For more information, see the Component Model [0] and WIT [1]; the idea is that you will eventually be able to compile your WASM to WASM Components, which can then interface with the host (or other WASM components) through the WIT IDL, including interacting with the browser's DOM.
[0]: https://github.com/WebAssembly/component-model [1]: https://github.com/WebAssembly/component-model/blob/main/des...
> you can pass integers and pointers around
No, not even that (the second thing, passing pointers)! WASM has a different address space (starting from 0), effectively indexing into the WASM module's linear memory. A pointer/reference from the outside env can not be dereferenced from within the WASM bytecode.
The multiple linear memory proposal can circumvent this (allowing you to build something somewhat similar to a simple MMU/address translation engine), but language support for that feature is sparse (AFAIK, Rust does not expose any way to access a different than the default linear memory for example).
There is various hacks around it, but sharing memory block-wise between WASM and outside env is involved already.
Yes, sorry, I should have clarified: pointers to the WASM memory, not host memory. You need to copy data into the memory in order to use it.
> The DOM API is defined as a JavaScript API.
It's defined via WebIDL (https://webidl.spec.whatwg.org/) which is theoretically language agnostic, but practically speaking the primary implementation target is JavaScript.
A triumph of hope over experience.
more like javascript eating rust
babel is so bad versus swc brought a 10 fold increase in speed on the frontend
It seems Zig is getting in on the game too now, with Bun leading the way.
> with Bun leading the way
Definitely leading the way in segfaults.
You left out Leptos!
by this logic, rust is eating python as well.
No, it is not!
[flagged]
False equivalence, shallow dismissal, and low effort.
Comparing Rust to blockchain is a level of cynicism that seems deeply self defeating
All three items i mentioned advertise themselves in the way a religion does.
Do religions send you LinkedIn messages?
So is Go, and so is Python. The LLM craze shifted the focus from JS to Python a while back, and I’m all for it.
That doesn’t mean I’m under the delusion that JS is going away anytime soon; at least from the FE. But its monopoly on the web took a big hit—and rightfully so.
JS is a terrible language, and people who only know that one language will fight tooth and nail with anyone who opposes them.
This gave birth to the awful trend of using JS in the backend. I understand that sometimes JS is the only option for frontend work, but keep that junk out of my sysarch. There are better languages your backend can benefit from—Go, Rust, Zig, Kotlin, Python—anything but JS/TS.
I’m glad the industry has learned from its mistakes. I’m seeing far fewer Node.js backend jobs and a lot more Python, Go, Rust, and C# roles.
Jobs are regional. Here in Estonia I see a lot more Node.js jobs YoY, very few Python gigs, zero Rust jobs, and very few C# jobs. Heck, PHP has more jobs than C#. Node/JS seems to compete with Java here for job popularity, according to local job boards, and most Java jobs also require Node.js/JS knowledge.
Europe is always playing catch-up with the US. Even so, the number of Node.js backend jobs has declined in both Berlin and Amsterdam.
I’m also seeing a ton of Java, C#, and Go jobs in London. At my workplace, Wolt/DoorDash, all new services are being spun up in Go, where Node.js used to be the default.
Plus, LLMs have gotten really good at Node.js and Python, driving backend salaries down quite a bit. In this age, being a one-trick pony just won’t cut it anymore.
Getting kind of tired of this Europe vs US trope. Europe is a huge place with each country having a rather unique economy, making a blanket statement like you just did entirely ignores that, and where does this constant need to compare one place on the planet with another place comes from? I don't live my life comparing everything about my country with another country, do you? Development trends themselves tend to also be cyclical.
As for LLM's, from what I see the languages that LLM's are most often used for are those with the lower barrier to entry / and those that UNI's and bootcamps teach, which would very much also include Java. However, what I see is actually my salary going up as the average candidate quality has been also decreasing, almost in correlation with the usage of LLM's. So while maybe the junior/mid-level salary goes down, the senior salary, in my observations, has not. And I keep hearing from companies how finding actually capable developers has become harder and harder, so I expect my salary to only go up.
Now, of course, being a one trick pony has never been a good thing, I agree on that (did you assume that I'm a just JS dev?), but I was just answering to your original comment.
> This gave birth to the awful trend of using JS in the backend.
Right, famous developer Ryan Dahl who knows only one language.
The new thing that gadget addicted males love because it's shiny and it's better and safer and the ultimate cool.
Come everyone. C is dead, Javascript is dying.
Also it is used by the bigdiks, like facebook who can't make a proper comment system, yet they market react as another shiny thing. And Apple who always turn your bluetooth back on after update. And google, who act like inbred mutants thanks to the incest that is going on there. A W S, the three letter magic thing also uses it. Plus cloud!
And the list goes on! Plus it has fugly syntax, but who cares, it is memory safe!
Jump onboard, this is the future!