3 ms·

Late? For what? Lightweight threads weren’t a reason to move to Node or Go. The Loom fibers are very special in that the blocking syntax doesn’t change, there’s

by jmaker 3y ago

Late? For what? Lightweight threads weren’t a reason to move to Node or Go. The Loom fibers are very special in that the blocking syntax doesn’t change, there’s no apparent coloring, and you can easily adapt your blocking calls to the lightweight dispatched non-blocking style now. Asynchrony is different from fibers. The .NET team has been pondering introducing fibers when it became obvious that Loom gained significant traction. I don’t think there’s any “lost ground” but simply a healthy competition. It’s not all about the merits of a particular language I think but more about the people behind the ecosystems, the compute platforms and the job market. As for phasing out reactive streams and Graal, I don’t see why one would ever tread that path. Why do you think that “isomorphism” is important? Besides, Kotlin Multiplatform, ScalaJS, Vaadin all give you that option. As for your third paragraph, I think it’s again more of a cultural and job market issue than a purely merits-based technological one. The Node and Go ecosystems gained enough traction to pull in many production apps. The agility story is different with them too. Experienced engineers are very reluctant to changing languages, relearning and rewriting their production apps. Management might prefer to follow whatever they perceive as the present trend but whether they can do their due diligence and justify such a decision financially is a different story. Juniors might be curious enough to rewrite their apps on a different stack. But established software follows different standards. And for the majority of Java software you don’t need the most recent features, it works just fine. Since Java has always been so huge, there’s been a lot of badly designed software (in absolute figures), whose maintainers might be tempted to “rewrite” it in a different stack. But it’s rarely a sane decision. With the new feature set one can now simply opt into certain enhancements, but it’s not an ultimate solution to questionable architectural and design decisions either. But what do you mean by “Node-style efficiency”? It’s not very performant and is quite a resource hungry platform. I know a couple companies that decided to move from a legacy Spring stack to a modern Node stack. Their argument was like “Java is old and boring, we want to rejuvenate our software by using TypeScript, and one of our principals decided that’s the right call.” Not kidding. In reality though they over-hired JS devs for their frontends and now believe they can profit from that “isomorphy”. There’s so much expertise behind Java and its ecosystem, most problems solved long ago, something all other platforms can only dream of.

nvm0n2 3y ago
I think we're in agreement :-) I'm talking about how those languages/platforms pitched themselves to get users. In the early days, Node pushed itself as about performance. Write in a high level scripting language like Python or Ruby that you already know, but with a really advanced VM behind you, and with fully async everything so you can handle a bazillion requests simultaneously. That was a winning strategy for them. Isomorphism was then the other selling point of Node as other platforms caught up. Have one team that can write frontend and backend code, easily share code, easily hire. Yes nowadays you can do that with Kotlin but that's a very new capability (and note: not Java, not Loom). As you say yourself, real companies factor this into their decision making. Loom solves the performance argument and without losing usability, which is a significant win. But it doesn't help with the other factors and companies like the ones you mention already made their decisions, so, this is what I mean by "late". Those companies probably aren't going to migrate from TypeScript back to Spring are they.
- jmaker 3y ago
  Oh, I wasn’t aware Node had originally pitched performance. Was it only in the context of single-threaded IO? Yes, from the hiring perspective that “isomorphism” makes a lot of sense on paper. Pardon me, in your third paragraph, what “other factors” are you referring to? As for the companies that made such a move, well, it’s their choice. There’s always a reason, it boils down in the end just to whether it was well justified at the moment. Time will tell. A reasonable argument in my decision making was Spring’s huge memory footprint in a microservices architecture deployed to public cloud. Go’s profile was nigh of 100m peak RSS for a given payload, while Spring’s was 1.5g, per instance. I could just take one commodity nano VM at $5 a month instead of multiple 1g-4g VMs at $50-150 a month each. FinOps. It’s a common theme, suppose you have a service mesh with many tiny services, it does sound right to have them utilize just as few resources and be spawnable instantaneously on-demand. So a mixture of Java and Go services comes up quite frequently. But then you need to factor in a lot of other costs and the fact that Go’s GC will hiccup anyway and potential goroutine leaks could bring down the entire cluster. And so on. That’s just to say that—on paper—it might look assertive, while in reality you would get to realize that there’s so much opaque minute detail behind the Spring or Quarkus APIs that once you realize that it’s missing in your Go or Node code base and get to reintroduce it (wasting hours), you end up with something that need not perform just as well. The more stuff you plug into your Go or Node lightweight frameworks, the more integrational complexity is on you and the less agile you get. It’s all their choice. There are ways to minimize JVM resource utilization. And you don’t need to always use Spring, and you can have instantaneous start-up times with persisted app state. To me, it’s getting harder and harder to justify Go or Node on the backend.

by jmaker 3y ago

nvm0n2 3y ago

I think we're in agreement :-) I'm talking about how those languages/platforms pitched themselves to get users. In the early days, Node pushed itself as about performance. Write in a high level scripting language like Python or Ruby that you already know, but with a really advanced VM behind you, and with fully async everything so you can handle a bazillion requests simultaneously. That was a winning strategy for them. Isomorphism was then the other selling point of Node as other platforms caught up. Have one team that can write frontend and backend code, easily share code, easily hire. Yes nowadays you can do that with Kotlin but that's a very new capability (and note: not Java, not Loom). As you say yourself, real companies factor this into their decision making. Loom solves the performance argument and without losing usability, which is a significant win. But it doesn't help with the other factors and companies like the ones you mention already made their decisions, so, this is what I mean by "late". Those companies probably aren't going to migrate from TypeScript back to Spring are they.

jmaker 3y ago
Oh, I wasn’t aware Node had originally pitched performance. Was it only in the context of single-threaded IO? Yes, from the hiring perspective that “isomorphism” makes a lot of sense on paper. Pardon me, in your third paragraph, what “other factors” are you referring to? As for the companies that made such a move, well, it’s their choice. There’s always a reason, it boils down in the end just to whether it was well justified at the moment. Time will tell. A reasonable argument in my decision making was Spring’s huge memory footprint in a microservices architecture deployed to public cloud. Go’s profile was nigh of 100m peak RSS for a given payload, while Spring’s was 1.5g, per instance. I could just take one commodity nano VM at $5 a month instead of multiple 1g-4g VMs at $50-150 a month each. FinOps. It’s a common theme, suppose you have a service mesh with many tiny services, it does sound right to have them utilize just as few resources and be spawnable instantaneously on-demand. So a mixture of Java and Go services comes up quite frequently. But then you need to factor in a lot of other costs and the fact that Go’s GC will hiccup anyway and potential goroutine leaks could bring down the entire cluster. And so on. That’s just to say that—on paper—it might look assertive, while in reality you would get to realize that there’s so much opaque minute detail behind the Spring or Quarkus APIs that once you realize that it’s missing in your Go or Node code base and get to reintroduce it (wasting hours), you end up with something that need not perform just as well. The more stuff you plug into your Go or Node lightweight frameworks, the more integrational complexity is on you and the less agile you get. It’s all their choice. There are ways to minimize JVM resource utilization. And you don’t need to always use Spring, and you can have instantaneous start-up times with persisted app state. To me, it’s getting harder and harder to justify Go or Node on the backend.