10 ms·

The jvm is a pretty insane beast. It will do usage based recompilation, escape analysis for memory, so non heap allocation is super fast, has great memory safet

The jvm is a pretty insane beast. It will do usage based recompilation, escape analysis for memory, so non heap allocation is super fast, has great memory safety... But a lot of people use it with spring/spring boot, a technology designed to work around the complexities of a particular type of middleware software in the late 90s and early 2000s. It's cargo cult programming of the highest order. In the OP, the author is comparing apples with oranges, with a bit of misunderstanding that java/jvm means spring boot, and while that is true for a lot of people and certainly a lot of stuff on the internet implies that 'this is the way', it's not required. Startup times of ~100ms are absolutely standard for a big program, similarly unit tests taking 1ms. I prefer to write kotlin rather than java, as it's a nicer language ,IMHO, but still those bytecodes run on Jvm and same stuff applies. Edit: im not advocating writing 'ls' in java, and I would also agree that java uses more memory for small programs, so its not a systems programming language probably. Just use new() it's pretty fast.

khana 2y ago
[dead]
okeuro49 2y ago
> But a lot of people use it with spring/spring boot, a technology designed to work around the complexities of a particular type of middleware... No, people use it because we don't want to reinvent the wheel. Spring is well documented and Spring Boot gives you a set of dependencies that all work together. Then you don't have to spend time messing around with things like OAuth and authentication, you can just write the application.
- anthropodie 2y ago
  > Then you don't have to spend time messing around with things like OAuth and authentication, you can just write the application. It sounds good but in reality people end up spending time messing around with config files and annotations.
  - gf000 2y ago
    Like, what other option is there? There is either a proper, battle-tested solution which requires some configuration so that it works as you want, or you start from scratch and create something specifically for your own usecase. In the latter case, it may actually mean a significant amount of development orders of magnitude more than looking up how to configure stuff, constant maintainance, etc.
    - whstl 2y ago
      > Like, what other option is there? For this specific case there's plenty... You can use the battle-tested libraries wrapped by Spring directly. For OAuth specifically, Spring does very little. You can use other frameworks that also have those features, in Java or in other languages. You can use a paid authentication services. You can use an open source authentication services.
      - gf000 2y ago
        I was talking more abstractly, in that understanding a given feature to be able to configure it properly is not optional (besides asking someone else to handle some part of the complexity e.g. third party authentication services in this case).
        deleted 2y ago
        [deleted]
        whstl 2y ago
        But in none of those you "end up spending time messing around with config files and annotations", which was the problem mentioned by the grandparent. So yes: there are other options.
      - okeuro49 2y ago
        > You can use the battle-tested libraries wrapped by Spring directly. For OAuth specifically, Spring does very little. Then you have to work to make the libraries all work together. And deal with updates. Spring Boot allows to to update all libraries together, and know that they work together.
- optician_owl 2y ago
  > Spring Boot gives you a set of dependencies that all work together. But spring boot deps is infamous meme. > Then you don't have to spend time messing around with things like OAuth and authentication Yeah. The funny thing is reality is quite complicated and spring supports a lot of (almost) documented cases. But 99% javaspring developers do not care. I met quite a lot of experienced devs and only 2 of them know how to optimize application start or which errors Kafka wrapper would not retry and so on. Half of the non-default situations are solved via reinventing the wheel because of a lack of understanding of nuances. I can't say people are dumb, many of those devs are smart. I tend to say that ultra-framework kills people's expertise and in the long term hardly saves resources.
  - okeuro49 2y ago
    > I tend to say that ultra-framework kills people's expertise and in the long term hardly saves resources. You can use as much of Spring or as little as you want. Don't want Hibernate? Use JDBC template. I have noticed that people who don't use a framework, just end up inventing their own bespoke framework, which unlike Spring, is not documented and has no help available online.
    - nprateem 2y ago
      It's a paradox as old as time itself. Otherwise intelligent devs assume they can do a better job without all the "complication" and "bloat", but then just end up with homegrown unmaintainable crap that does half of what the frameworks offer for significantly more effort. It's either stupidity or arrogance.
      - optician_owl 2y ago
        > all the "complication" and "bloat", but then just end up with homegrown unmaintainable crap that does half of what the frameworks offer for significantly more effort. I don't see how you deduct the conclusion of reinventing wheels is the only solution of overcomplex and far from ideal frameworks. But you can categorise this deduction also.
      - 2y ago
- whstl 2y ago
  I don't see how writing "one more OAuth client" or "one more login thing" using Spring Boot is not reinventing the wheel in itself. If you really care about "not reinventing the wheel" there are ready-made paid solutions such as Auth0 and Cognito, plus self-hostable open-source options like Keycloak, Authelia, and Dex. Also, Spring Boot itself uses third-party libraries for OAuth and Authentication, like Ninbus, which people can drop-in in their non-Spring Java apps.
- smrtinsert 2y ago
  Don't know why this is down voted its absolutely true. When our tech leadership reviewed the numbers we changed auth design without touching the application code base really. Saved a ton of work considering we have many microservices. Spring rocks.
- cies 2y ago
  I found String (Boot) a horror to work with. Annotation based devt with super weird errors. The great thing was that most errors where run into by many before me so could be solved by a simple web search/ Stack Overflow article. To me being able to CTRL-click my way into the libraries is very important. Overuse of annotations (a.k.a. magic) breaks that. It is what monkey patching is for Ruby. The beginning of the downfall IHMO of an otherwise great language. Luckily Kotlin's culture avoids this.
procaryote 2y ago
Yep. Java is really good. Java developer culture is awful. If you instead of spring boot just pick a few dependencies you really need, you don't throw the whole Design Patterns book at it just because you can, and you don't try to make everything changeable without recompiling or redeploying, it's pretty nice to work with
- cies 2y ago
  Like the article I hear Spring Boot here mentioned again. I also really hate the annotation culture. This is big in Spring Boot, and more common in Java since it is so damn verbose. It is not inherent in Java though, and the Kotlin "developer culture" seems to be much more annotation averse (as we all should be).
  - gf000 2y ago
    You do realize that Java is objectively less verbose than Go? Even on a vanilla language to vanilla language basis, but let alone against something like Spring Boot that does almost everything for you in a typical CRUD application. Annotations are declerative shorthands. How is a trivial spring boot endpoint with methods with a single @GET line above them denoting the endpoint verbose? What about a single SQL query in an annotation above an interface method's name? Will your whole implementation of connect to db, execute query, iterate over the resulting rows, and convert them to some native object/struct shorter than.. 2 lines?
    - FrustratedMonky 2y ago
      "Annotations are declerative shorthands." OR. Are annotations a crutch for something that should be in the language. Just generally, if some tool has to use annotations, then that is indicator of something that should be in the language.
      - gf000 2y ago
        So which language has native REST endpoints? Session-aware security? Like, this is just standard metaprogramming, if you don't have it you will just reach for dumber tools like non-language aided code generation.
smusamashah 2y ago
At work we work on a Java code base 20 years old and it is written like C. No dependency injection or other Java Web development like shenanigans. Almost every lib etc has been built in-house. It runs an MMO, it's fast. Its just way more productive/faster to work and implement something in the Java codebase than a C++ codebase that we have. Someone shared a Job posting which asked for "no java experience". It was funny.
- watt 2y ago
  If you write Java just like you would write Go - meaning, no reflection shenanigans, use Jigsaw to cut out unneeded JVM stuff, or use GraalVM and compile natively (which you will be able to, because you did not use any of JVM reflection magic), Java will absolutely be competitive.
  - wvh 2y ago
    In the end it all boils down to higher-level logic compiling down to machine code that has to run. A language's culture and philosophical choices are tied to the language itself as much as syntax or compiler, so maybe the largest difference between languages like Java and Go is really the whole developer attitude and aesthetic choices.
- theshrike79 2y ago
  It's kinda understandable. I've seen "Java coders" write Python for example. The first thing they do is create a class and maybe even a Factory or Interface. You can see instantly where their experience is from and it's hard to unlearn.
  - kuschku 2y ago
    Java developers may write verbose python, but that doesn't compare to the crimes actual python devs commit. Currently trying to modernize a python project that doesn't use modules, just executable python files that import each other with custom sys.path hackery, which is also used for globals, no type annotations, GLib used for everything including math and string to int parsing.
dominicrose 2y ago
I tried truffleruby for the adventofcode challenges. Almost everything ran faster with normal ruby. I got a stack too deep error in truffleruby that I didn't get in normal ruby. I don't recall having more problems with memory with one or the other. There was one case where truffleruby was really useful though. Thus I'm with you that it's not a systems programming language. It seems good for processes that stay ON, like servers. But then when compared with PHP, during development you don't need to worry about the server, it just takes the most recent version of your code. Surely hot-reload can be a solution with java, but in practice it's a complication, especially if you're part of a team/project where there is no hot-reload support.
- HumanOstrich 2y ago
  I don't follow. Seems like the issues you had were due to truffleruby and how it implements ruby's internals on the JVM. That's not a Java/Kotlin/JVM issue.
- gf000 2y ago
  Why would you expect any speedup for programs that run for a split of a second?
  - dominicrose 2y ago
    Indeed, nothing really surprising. truffleruby+graalvm started to be useful for programs that took roughtly 15s or more to run.
- Twirrim 2y ago
  The JVM doesn't attempt to compile a method until a method has reached 10,000 executions. So it's extremely likely your code ran the entire time in interpreted mode. Even if a method did get flagged as hot, you've then got the time taken to do the actual compilation to native code to contend with. If you're trying to write systems code and want to use the JVM, GraalVM can do full ahead-of-time compilation and will get you almost instant start up with all methods natively compiled.
unscaled 2y ago
I think we can sum it this way. The blog post writer's intuition was correct: if you write two equivalent Go and and JVM programs, the Go program would use less heap memory and have faster startup times. What they are incorrect about is the extent of these claims. It is obvious that most of the memory and startup overhead in their software comes from Spring, rather than the JVM. The JVM is probably not an ideal platform for writing an Kubernetes infra tool like operator or a sidecar (mostly due to heap size and more a complex binary packaging story), but using Spring Framework for writing these kind of tool is a bigger problem. If they just wrote their initial tool in Kotlin without using Spring framework at all, it would be much faster. They could even have kept Dependency Injection with a lightweight framework like Koin or Dagger (even a reflection-based framework like Guice performs worlds better than Spring). I would probably still prefer Rust for writing most infrastructure projects nowadays. GraalVM Native Images has similar memory footprint to Go and solve the slightly troublesome JAR deployment story, but with the complex license terms for the enterprise edition (where most of the performance optimizations are), I don't feel safe using it. I also prefer Rust's concurrency model and I find cargo to be a far more pleasant experience than either Maven or Gradle, but in the end of the day, you will not see serious issues if you use Kotlin in a sane way, and you can even save on some Go boilerplate.
- AYBABTME 2y ago
  Rust has its uses but why would you write infra code in Rust when Go is used for most of it, and is just much more ergonomic and fast to work with. The iteration times with Rust are quite detrimental. On the other hand, most of k8s' ecosystem is in Go. I don't like commenting in language-war territory things but I found your comment surprising. "Rust or JVM" for infra isn't a dichotomy I would expect.
  - sn9 2y ago
    Discord had a pretty famous transition from Go to Rust [0]. [0] https://discord.com/blog/why-discord-is-switching-from-go-to-rust https://discord.com/blog/why-discord-is-switching-from-go-to...
    - 2y ago
itsthecourier 2y ago
yeah, this author reminds me of the guys who think simpler is better because they haven't read the whole documentation on why the thing is complex in first place, do they end up reinventing the wheel badly as they start to grow and discover problems already solved in mature frameworks the lack of specific mention of scenarios and features beyond dependency injection suggests ignorance IMHO
- CharlieDigital 2y ago
  I find this very common when working with JS backends. Once you get serious, you end up replicating a lot of the complex concepts of frameworks like Spring or .NET
zerr 2y ago
Do you suggest to use vanilla Java instead of Spring?
coldtea 2y ago
>Edit: im not advocating writing 'ls' in java, and I would also agree that java uses more memory for small programs, so its not a systems programming language probably. I dunno, some databases and things like Lucene are written in Java.
renegade-otter 2y ago
https://notes.ericjiang.com/posts/751 https://notes.ericjiang.com/posts/751 "PayPal and Wal-Mart have also had high-profile switches to Node.js. Of course, they’re comparing two completely different things to make Node.js look better. In these too-good-to-be-true stories, they’re switching from a gigantic enterprisey codebase to a Node.js app written from scratch. Is there any question that it wouldn’t have been faster? They could have switched to pretty much any anything and gotten a performance gain. In LinkedIn’s case, they had proxies running on Mongrel with a concurrency of 1. It’s like switching from using one finger to type on a QWERTY keyboard to using ten fingers on a Dvorak keyboard and giving all the credit to Dvorak for a better keyboard layout." P.S.: Google became so awful that a search for even the direct title of the article does not land it in the top results - just references to it.
boreas7878 2y ago
Yep, he is comparing the most bloated enterprise framework to lean Go apps. This article is so wrong in confusing Java with their particular monster project. You can definitively AoT-compile in Java, there are modern lightweight frameworks like Javalin, and I think the language itself now allows to write web services without any library.
725686 2y ago
"cargo cult" really? Have you ever built maintained big a Java codebase? Spring is a marvel that sprang out of the experience of very, very talented people. It can be misused, of course, like any other technology, but it is a huge productivity booster.
- cies 2y ago
  You are joking right? "Spring is a marvel that sprang out of the experience of very, very talented people." --> sounds very culty to me. And yes I maintain both Spring and non-Spring JVM projects.

khana 2y ago

[dead]

okeuro49 2y ago

> But a lot of people use it with spring/spring boot, a technology designed to work around the complexities of a particular type of middleware... No, people use it because we don't want to reinvent the wheel. Spring is well documented and Spring Boot gives you a set of dependencies that all work together. Then you don't have to spend time messing around with things like OAuth and authentication, you can just write the application.

anthropodie 2y ago
> Then you don't have to spend time messing around with things like OAuth and authentication, you can just write the application. It sounds good but in reality people end up spending time messing around with config files and annotations.
- gf000 2y ago
  Like, what other option is there? There is either a proper, battle-tested solution which requires some configuration so that it works as you want, or you start from scratch and create something specifically for your own usecase. In the latter case, it may actually mean a significant amount of development orders of magnitude more than looking up how to configure stuff, constant maintainance, etc.
  - whstl 2y ago
    > Like, what other option is there? For this specific case there's plenty... You can use the battle-tested libraries wrapped by Spring directly. For OAuth specifically, Spring does very little. You can use other frameworks that also have those features, in Java or in other languages. You can use a paid authentication services. You can use an open source authentication services.
    - gf000 2y ago
      I was talking more abstractly, in that understanding a given feature to be able to configure it properly is not optional (besides asking someone else to handle some part of the complexity e.g. third party authentication services in this case).
      - deleted 2y ago
        [deleted]
      - whstl 2y ago
        But in none of those you "end up spending time messing around with config files and annotations", which was the problem mentioned by the grandparent. So yes: there are other options.
    - okeuro49 2y ago
      > You can use the battle-tested libraries wrapped by Spring directly. For OAuth specifically, Spring does very little. Then you have to work to make the libraries all work together. And deal with updates. Spring Boot allows to to update all libraries together, and know that they work together.
optician_owl 2y ago
> Spring Boot gives you a set of dependencies that all work together. But spring boot deps is infamous meme. > Then you don't have to spend time messing around with things like OAuth and authentication Yeah. The funny thing is reality is quite complicated and spring supports a lot of (almost) documented cases. But 99% javaspring developers do not care. I met quite a lot of experienced devs and only 2 of them know how to optimize application start or which errors Kafka wrapper would not retry and so on. Half of the non-default situations are solved via reinventing the wheel because of a lack of understanding of nuances. I can't say people are dumb, many of those devs are smart. I tend to say that ultra-framework kills people's expertise and in the long term hardly saves resources.
- okeuro49 2y ago
  > I tend to say that ultra-framework kills people's expertise and in the long term hardly saves resources. You can use as much of Spring or as little as you want. Don't want Hibernate? Use JDBC template. I have noticed that people who don't use a framework, just end up inventing their own bespoke framework, which unlike Spring, is not documented and has no help available online.
  - nprateem 2y ago
    It's a paradox as old as time itself. Otherwise intelligent devs assume they can do a better job without all the "complication" and "bloat", but then just end up with homegrown unmaintainable crap that does half of what the frameworks offer for significantly more effort. It's either stupidity or arrogance.
    - optician_owl 2y ago
      > all the "complication" and "bloat", but then just end up with homegrown unmaintainable crap that does half of what the frameworks offer for significantly more effort. I don't see how you deduct the conclusion of reinventing wheels is the only solution of overcomplex and far from ideal frameworks. But you can categorise this deduction also.
    - 2y ago
whstl 2y ago
I don't see how writing "one more OAuth client" or "one more login thing" using Spring Boot is not reinventing the wheel in itself. If you really care about "not reinventing the wheel" there are ready-made paid solutions such as Auth0 and Cognito, plus self-hostable open-source options like Keycloak, Authelia, and Dex. Also, Spring Boot itself uses third-party libraries for OAuth and Authentication, like Ninbus, which people can drop-in in their non-Spring Java apps.
smrtinsert 2y ago
Don't know why this is down voted its absolutely true. When our tech leadership reviewed the numbers we changed auth design without touching the application code base really. Saved a ton of work considering we have many microservices. Spring rocks.
cies 2y ago
I found String (Boot) a horror to work with. Annotation based devt with super weird errors. The great thing was that most errors where run into by many before me so could be solved by a simple web search/ Stack Overflow article. To me being able to CTRL-click my way into the libraries is very important. Overuse of annotations (a.k.a. magic) breaks that. It is what monkey patching is for Ruby. The beginning of the downfall IHMO of an otherwise great language. Luckily Kotlin's culture avoids this.

procaryote 2y ago

Yep. Java is really good. Java developer culture is awful. If you instead of spring boot just pick a few dependencies you really need, you don't throw the whole Design Patterns book at it just because you can, and you don't try to make everything changeable without recompiling or redeploying, it's pretty nice to work with

cies 2y ago
Like the article I hear Spring Boot here mentioned again. I also really hate the annotation culture. This is big in Spring Boot, and more common in Java since it is so damn verbose. It is not inherent in Java though, and the Kotlin "developer culture" seems to be much more annotation averse (as we all should be).
- gf000 2y ago
  You do realize that Java is objectively less verbose than Go? Even on a vanilla language to vanilla language basis, but let alone against something like Spring Boot that does almost everything for you in a typical CRUD application. Annotations are declerative shorthands. How is a trivial spring boot endpoint with methods with a single @GET line above them denoting the endpoint verbose? What about a single SQL query in an annotation above an interface method's name? Will your whole implementation of connect to db, execute query, iterate over the resulting rows, and convert them to some native object/struct shorter than.. 2 lines?
  - FrustratedMonky 2y ago
    "Annotations are declerative shorthands." OR. Are annotations a crutch for something that should be in the language. Just generally, if some tool has to use annotations, then that is indicator of something that should be in the language.
    - gf000 2y ago
      So which language has native REST endpoints? Session-aware security? Like, this is just standard metaprogramming, if you don't have it you will just reach for dumber tools like non-language aided code generation.

smusamashah 2y ago

At work we work on a Java code base 20 years old and it is written like C. No dependency injection or other Java Web development like shenanigans. Almost every lib etc has been built in-house. It runs an MMO, it's fast. Its just way more productive/faster to work and implement something in the Java codebase than a C++ codebase that we have. Someone shared a Job posting which asked for "no java experience". It was funny.

watt 2y ago
If you write Java just like you would write Go - meaning, no reflection shenanigans, use Jigsaw to cut out unneeded JVM stuff, or use GraalVM and compile natively (which you will be able to, because you did not use any of JVM reflection magic), Java will absolutely be competitive.
- wvh 2y ago
  In the end it all boils down to higher-level logic compiling down to machine code that has to run. A language's culture and philosophical choices are tied to the language itself as much as syntax or compiler, so maybe the largest difference between languages like Java and Go is really the whole developer attitude and aesthetic choices.
theshrike79 2y ago
It's kinda understandable. I've seen "Java coders" write Python for example. The first thing they do is create a class and maybe even a Factory or Interface. You can see instantly where their experience is from and it's hard to unlearn.
- kuschku 2y ago
  Java developers may write verbose python, but that doesn't compare to the crimes actual python devs commit. Currently trying to modernize a python project that doesn't use modules, just executable python files that import each other with custom sys.path hackery, which is also used for globals, no type annotations, GLib used for everything including math and string to int parsing.

dominicrose 2y ago

I tried truffleruby for the adventofcode challenges. Almost everything ran faster with normal ruby. I got a stack too deep error in truffleruby that I didn't get in normal ruby. I don't recall having more problems with memory with one or the other. There was one case where truffleruby was really useful though. Thus I'm with you that it's not a systems programming language. It seems good for processes that stay ON, like servers. But then when compared with PHP, during development you don't need to worry about the server, it just takes the most recent version of your code. Surely hot-reload can be a solution with java, but in practice it's a complication, especially if you're part of a team/project where there is no hot-reload support.

HumanOstrich 2y ago
I don't follow. Seems like the issues you had were due to truffleruby and how it implements ruby's internals on the JVM. That's not a Java/Kotlin/JVM issue.
gf000 2y ago
Why would you expect any speedup for programs that run for a split of a second?
- dominicrose 2y ago
  Indeed, nothing really surprising. truffleruby+graalvm started to be useful for programs that took roughtly 15s or more to run.
Twirrim 2y ago
The JVM doesn't attempt to compile a method until a method has reached 10,000 executions. So it's extremely likely your code ran the entire time in interpreted mode. Even if a method did get flagged as hot, you've then got the time taken to do the actual compilation to native code to contend with. If you're trying to write systems code and want to use the JVM, GraalVM can do full ahead-of-time compilation and will get you almost instant start up with all methods natively compiled.

unscaled 2y ago

I think we can sum it this way. The blog post writer's intuition was correct: if you write two equivalent Go and and JVM programs, the Go program would use less heap memory and have faster startup times. What they are incorrect about is the extent of these claims. It is obvious that most of the memory and startup overhead in their software comes from Spring, rather than the JVM. The JVM is probably not an ideal platform for writing an Kubernetes infra tool like operator or a sidecar (mostly due to heap size and more a complex binary packaging story), but using Spring Framework for writing these kind of tool is a bigger problem. If they just wrote their initial tool in Kotlin without using Spring framework at all, it would be much faster. They could even have kept Dependency Injection with a lightweight framework like Koin or Dagger (even a reflection-based framework like Guice performs worlds better than Spring). I would probably still prefer Rust for writing most infrastructure projects nowadays. GraalVM Native Images has similar memory footprint to Go and solve the slightly troublesome JAR deployment story, but with the complex license terms for the enterprise edition (where most of the performance optimizations are), I don't feel safe using it. I also prefer Rust's concurrency model and I find cargo to be a far more pleasant experience than either Maven or Gradle, but in the end of the day, you will not see serious issues if you use Kotlin in a sane way, and you can even save on some Go boilerplate.

AYBABTME 2y ago
Rust has its uses but why would you write infra code in Rust when Go is used for most of it, and is just much more ergonomic and fast to work with. The iteration times with Rust are quite detrimental. On the other hand, most of k8s' ecosystem is in Go. I don't like commenting in language-war territory things but I found your comment surprising. "Rust or JVM" for infra isn't a dichotomy I would expect.
- sn9 2y ago
  Discord had a pretty famous transition from Go to Rust [0]. [0] https://discord.com/blog/why-discord-is-switching-from-go-to-rust https://discord.com/blog/why-discord-is-switching-from-go-to...
  - 2y ago

itsthecourier 2y ago

yeah, this author reminds me of the guys who think simpler is better because they haven't read the whole documentation on why the thing is complex in first place, do they end up reinventing the wheel badly as they start to grow and discover problems already solved in mature frameworks the lack of specific mention of scenarios and features beyond dependency injection suggests ignorance IMHO

CharlieDigital 2y ago
I find this very common when working with JS backends. Once you get serious, you end up replicating a lot of the complex concepts of frameworks like Spring or .NET

zerr 2y ago

Do you suggest to use vanilla Java instead of Spring?

coldtea 2y ago

>Edit: im not advocating writing 'ls' in java, and I would also agree that java uses more memory for small programs, so its not a systems programming language probably. I dunno, some databases and things like Lucene are written in Java.

renegade-otter 2y ago

https://notes.ericjiang.com/posts/751 https://notes.ericjiang.com/posts/751 "PayPal and Wal-Mart have also had high-profile switches to Node.js. Of course, they’re comparing two completely different things to make Node.js look better. In these too-good-to-be-true stories, they’re switching from a gigantic enterprisey codebase to a Node.js app written from scratch. Is there any question that it wouldn’t have been faster? They could have switched to pretty much any anything and gotten a performance gain. In LinkedIn’s case, they had proxies running on Mongrel with a concurrency of 1. It’s like switching from using one finger to type on a QWERTY keyboard to using ten fingers on a Dvorak keyboard and giving all the credit to Dvorak for a better keyboard layout." P.S.: Google became so awful that a search for even the direct title of the article does not land it in the top results - just references to it.

boreas7878 2y ago

Yep, he is comparing the most bloated enterprise framework to lean Go apps. This article is so wrong in confusing Java with their particular monster project. You can definitively AoT-compile in Java, there are modern lightweight frameworks like Javalin, and I think the language itself now allows to write web services without any library.

725686 2y ago

"cargo cult" really? Have you ever built maintained big a Java codebase? Spring is a marvel that sprang out of the experience of very, very talented people. It can be misused, of course, like any other technology, but it is a huge productivity booster.

cies 2y ago
You are joking right? "Spring is a marvel that sprang out of the experience of very, very talented people." --> sounds very culty to me. And yes I maintain both Spring and non-Spring JVM projects.