5 ms·

You can sub JVM for something else but you should probably stick with PG and k8s. What I am saying is the highest quality tools are still the best and will rem

by jpgvm 3y ago

You can sub JVM for something else but you should probably stick with PG and k8s. What I am saying is the highest quality tools are still the best and will remain that way. As other things come and go they absorb the best ideas from the new stuff without losing what makes them good. Sometimes the new stuff survives (Node/TS/Go/Rust) sometimes it doesn't (Clojure, Scala, arguably Ruby), some we are waiting to find out. But betting on JVM and .NET has been winning strategy from a technical perspective for a long time now. Also worth mentioning no, PHP probably doesn't work here because it's not "general purpose" enough IMO. JVM can handle almost any workload shape, the main one it doesn't do well in is memory constrained environments (though it's possible if you really want to). PHP, Node/TS, Python, Ruby all suffer from being single threaded so can't take advantage of properly large machines without a ton of extra complexity and you pay a high memory overhead for most of those strategies. Go is OK, I hate writing it but it can do all the things so if that floats your boat go for it. Rust is also perfectly fine, I just find it is actually pretty slow to write because changing requirements often mean changing structure which can be harder to manage in Rust vs Java/Kotlin/C#. Anyways, wasn't meant to be a thing about languages. Just pick a good runtime or AoT lang of choice, write everything in it, stick to conventional frameworks, choose PostgreSQL, run the lot on k8s. That is the core takeaway.

foffoofof 3y ago
Agreed re: jvm and .net. It’s easy to imagine a resurgence in the future.
- re-thc 3y ago
  Java by all accounts and if jvm include Kotlin is 1 of the most widely used. Do you still want a resurgence? :)
Tainnor 3y ago
I mean, I currently work on the JVM, I just have enough experience with different languages (including Ruby, which I don't think is quite dead yet) and tech stacks to know that they all suck in their own way. The JVM, and specifically Java, and even more specifically Spring, have a lot of annoying warts, it's just that other languages have different warts. I agree that you shouldn't try to rewrite everything in an obscure, untested technology, but beyond that, there's a number of options with enough tradeoffs. But it seems we're largely in agreement there. I don't necessarily agree with the "keep everything in one language / stack" sentiment. There's certainly companies that overdo it, having 20 different languages at the same time. But there's also valid reasons for keeping certain tech stacks separate (e.g. having to do ML / data analysis stuff in Python). In the worst case, the "use only a single language" mindset leads to disasters like GWT, which is something that my current company unfortunately still uses because some Java developers (that don't work for the company any more) thought that JavaScript was beneath them. I also wouldn't choose PHP, for the record. I would like to trash it here, but I've never actually been forced to use it, so I can't even comment on it. I'm not so sure about k8s. I think you can get away with much simpler deployment models, too. At some point the overhead of having to manage everything manually (or a need for zero-downtime deployments) might make the added complexity of k8s more bearable, but it's certainly added complexity and not necessary everywhere and all the time. I 100% agree about postgres, it's so good and feature-rich that you should probably really only ever use another database if you have very specific needs (except maybe also adding redis as a cache, because redis is also very good).
- DanHulton 3y ago
  Quarkus also has a lot of annoying warts, as does just plain ol' Java. Lord, if I never see another Builder pattern again in my life, I may die a happy man.
  - cutler 3y ago
    Agreed. Builder.build() wtf!!?
  - Tainnor 3y ago
    I haven't yet used Quarkus, but in my opinion the solution to Spring's problems with startup times isn't to run everything in GraalVM, it's to declare dependencies statically instead of creating a mess of annotations that have to be interpreted at runtime. Kotlin IMHO provides ways of doing that rather elegantly.
cutler 3y ago
I don't know about absorbing the best ideas. Java, even after the introduction of raw string literals, still can't handle a regex without escaping metacharacters. Perl had that one solved in the 90s.

by jpgvm 3y ago

foffoofof 3y ago

Agreed re: jvm and .net. It’s easy to imagine a resurgence in the future.

re-thc 3y ago
Java by all accounts and if jvm include Kotlin is 1 of the most widely used. Do you still want a resurgence? :)

Tainnor 3y ago

I mean, I currently work on the JVM, I just have enough experience with different languages (including Ruby, which I don't think is quite dead yet) and tech stacks to know that they all suck in their own way. The JVM, and specifically Java, and even more specifically Spring, have a lot of annoying warts, it's just that other languages have different warts. I agree that you shouldn't try to rewrite everything in an obscure, untested technology, but beyond that, there's a number of options with enough tradeoffs. But it seems we're largely in agreement there. I don't necessarily agree with the "keep everything in one language / stack" sentiment. There's certainly companies that overdo it, having 20 different languages at the same time. But there's also valid reasons for keeping certain tech stacks separate (e.g. having to do ML / data analysis stuff in Python). In the worst case, the "use only a single language" mindset leads to disasters like GWT, which is something that my current company unfortunately still uses because some Java developers (that don't work for the company any more) thought that JavaScript was beneath them. I also wouldn't choose PHP, for the record. I would like to trash it here, but I've never actually been forced to use it, so I can't even comment on it. I'm not so sure about k8s. I think you can get away with much simpler deployment models, too. At some point the overhead of having to manage everything manually (or a need for zero-downtime deployments) might make the added complexity of k8s more bearable, but it's certainly added complexity and not necessary everywhere and all the time. I 100% agree about postgres, it's so good and feature-rich that you should probably really only ever use another database if you have very specific needs (except maybe also adding redis as a cache, because redis is also very good).

DanHulton 3y ago
Quarkus also has a lot of annoying warts, as does just plain ol' Java. Lord, if I never see another Builder pattern again in my life, I may die a happy man.
- cutler 3y ago
  Agreed. Builder.build() wtf!!?
- Tainnor 3y ago
  I haven't yet used Quarkus, but in my opinion the solution to Spring's problems with startup times isn't to run everything in GraalVM, it's to declare dependencies statically instead of creating a mess of annotations that have to be interpreted at runtime. Kotlin IMHO provides ways of doing that rather elegantly.

cutler 3y ago

I don't know about absorbing the best ideas. Java, even after the introduction of raw string literals, still can't handle a regex without escaping metacharacters. Perl had that one solved in the 90s.