Ask HN: Why do startups avoid Java?
Based on: https://www.workatastartup.com/companies?role=eng&role_type=be
117 comments
I worked for 2 that used it.
Speed.
The majority of the talent pool prefers newer tools and frameworks and these are for the most part Javascript based.
So you're able to implement faster, hire faster, pivot quicker.
Performance, mostly. It’s in the middle. Why do anything in the middle?
This isnt true. Java can be extremely high performing. Nasdaq runs on java.
In Java you can write correct multithreaded code that is highly scalable if you use the basic primitives and avoid snake oil like parallel streams, fork/join, etc. People wish you could write reliable and scalable parallel code with a small set of primitives but it just isn't true.
Agreed. I wish people didn't assume GC means slow - Java has the most sophisticated GC out there. There are points when not being able to stack allocate objects hurts performance, but JVM performance is good.
I've worked one two database systems written in JVM tech and the performance was good.
I've worked one two database systems written in JVM tech and the performance was good.
Relative to what, though? It’s a garbage collected language running on a virtual machine. At the end of the day, if I want high level ergonomics I’ll use Python and if I want performance I’ll use C. If I want both at the same time I’ll use rust. I don’t see where Java fits in this outside of some case where I’m forced to use it due to some library requirement or deployment constraint.
Java was a mediocre language made primarily to be optimized for midsized companies and aimed to be learnable by mid level engineers. There's a lot of boilerplate and ceremony to do even basic things and a type system that takes time to learn while not providing much benefit.
I've heard its gotten better in recent years but why bother?
- you want the jvm libraries? kotlin is a much cleaner syntax that also runs on android and can be compiled to js.
- need speed? rust is hot and has a lot of mindshare going into it as we speak.
- Need cheap devs you can rotate out on your pivot cycle till you land on a viable business model? javascript lets you build your whole stack in the same language with a large pool of junior to senior talent.
- need websocket or realtime? elixir wins the day there.
- ml? you night have a contender here. jvm based projects like spark and hadoop use the jvm. extensively. That said, scala seems more widely used in production there but its not a field I'm super close to so I could be mistaken.
I guess what I'm trying to say is that java isn't particularly bad but it doesn't have an edge either. there's nothing compelling in it thats going to give you an edge in delivering value to the users.
I've heard its gotten better in recent years but why bother?
- you want the jvm libraries? kotlin is a much cleaner syntax that also runs on android and can be compiled to js.
- need speed? rust is hot and has a lot of mindshare going into it as we speak.
- Need cheap devs you can rotate out on your pivot cycle till you land on a viable business model? javascript lets you build your whole stack in the same language with a large pool of junior to senior talent.
- need websocket or realtime? elixir wins the day there.
- ml? you night have a contender here. jvm based projects like spark and hadoop use the jvm. extensively. That said, scala seems more widely used in production there but its not a field I'm super close to so I could be mistaken.
I guess what I'm trying to say is that java isn't particularly bad but it doesn't have an edge either. there's nothing compelling in it thats going to give you an edge in delivering value to the users.
I thought Python was the language of choice for ML.
Still, having one language that's good at all of these does sound attractive. The excessive boilerplate is annoying, though.
Still, having one language that's good at all of these does sound attractive. The excessive boilerplate is annoying, though.
I wrote this thing using Python years ago
https://ontology2.com/essays/ClassifyingHackerNewsArticles/
I am thinking of firming it up to make something general for long-term use against RSS feeds. I have a blast writing websockets-based applications w/ asyncio in Python for my own personal use but I'd be loathe to put one of those where they get used heavily. On the other hand I have a lot of faith in the ability of Java-based servers that take heavy hits because I've done it for years.
That logistic regression classifier would be easy to port to Java but if I used Python it would be easy to add new algorithms, particularly I want to add a dimension reducer (papers I read suggest it would cut the error rate in half) and a clustering engine, with scikit-learn I get a good choice of high-performance and tested algos. On the other hand, I find it easy to write state-machine code, parsers and such in Java that chew efficiently through large volumes of text.
https://ontology2.com/essays/ClassifyingHackerNewsArticles/
I am thinking of firming it up to make something general for long-term use against RSS feeds. I have a blast writing websockets-based applications w/ asyncio in Python for my own personal use but I'd be loathe to put one of those where they get used heavily. On the other hand I have a lot of faith in the ability of Java-based servers that take heavy hits because I've done it for years.
That logistic regression classifier would be easy to port to Java but if I used Python it would be easy to add new algorithms, particularly I want to add a dimension reducer (papers I read suggest it would cut the error rate in half) and a clustering engine, with scikit-learn I get a good choice of high-performance and tested algos. On the other hand, I find it easy to write state-machine code, parsers and such in Java that chew efficiently through large volumes of text.
> aimed to be learnable by mid level engineers. There's a lot of boilerplate and ceremony to do even basic things and a type system that takes time to learn while not providing much benefit.
All of this is also true about Go, but it's on the high tide on the hype cycle.
All of this is also true about Go, but it's on the high tide on the hype cycle.
Number of possible candidates is also quite a nice factor. Even though you might benefit from more special languages and better devs because people learning haskell are most of the times better devs than most java devs due to their drive and passion.
On the flip side to what you’re saying, Java can do absolutely all the things you’ve listed and unifying around one language is far more beneficial to productivity than e.g. the small speed benefit you’ll get from using Rust. It and Elixir are fascinating but I think the list of startups that would benefit from adopting either are very, very small.
That said I think “why Java over JS” is the core question you’ve raised. I know everyone hates it but JS has mindshare, available potential employees and can do more or less anything you need it to (including run in the browser, which is a unique benefit). If you use TypeScript you can get a pretty sane, workable Node codebase that’ll work for most startups.
That said I think “why Java over JS” is the core question you’ve raised. I know everyone hates it but JS has mindshare, available potential employees and can do more or less anything you need it to (including run in the browser, which is a unique benefit). If you use TypeScript you can get a pretty sane, workable Node codebase that’ll work for most startups.
> unifying around one language is far more beneficial to productivity than e.g. the small speed benefit you’ll get from using Rust
Is it? I've found that using multiple languages has a negligible effect on productivity (especially if they're being used for separate projects and there's no need for FFI), but that using a poor one has a big effect.
Is it? I've found that using multiple languages has a negligible effect on productivity (especially if they're being used for separate projects and there's no need for FFI), but that using a poor one has a big effect.
IMO it depends on company size. If we’re talking startup startup then it’s beneficial. Once you’re big enough that you don’t need engineers to switch between different contexts/services so much it isn’t as important.
[deleted]
you named 4 different languages that are specialized for certain areas or you can just find a team of java devs that accomplish all of that in one language.
>Java was a mediocre language made primarily to be optimized for midsized companies and aimed to be learnable by mid level engineers
This is exactly what a startup should be optimizing for. cheap labor that can use a single language that can move fast enough to push product. When they all leave another group can step right in and continue the work
>Java was a mediocre language made primarily to be optimized for midsized companies and aimed to be learnable by mid level engineers
This is exactly what a startup should be optimizing for. cheap labor that can use a single language that can move fast enough to push product. When they all leave another group can step right in and continue the work
while I agree with the need to move fast enough to push a product. "cheap labor" in every startup I've seen has always been a bottleneck. The aim really should be picking a stack that allows A level talent to maximize their time delivering value, Not protecting junior engineers from cutting themselves.
>allows A level talent to maximize their time delivering value
A level talent is a bottleneck as they will move on for better opportunities. I wouldn't focus my company around that either.
A level talent is a bottleneck as they will move on for better opportunities. I wouldn't focus my company around that either.
A better question maybe. What is the edge of using java over others? 20 years back it was about cross platform support, but which language is not cross platform nowadays?
The problem with java is it needs a correctly installed, configured, and versions JVM installed to run the code. All the other languages will just spit out a exe that will just run if you click it. Java is the least cross platform language in existence.
Eh, a new hot language typically needs llvm to be available on a platform before it can spit out a binary for it. So it’s really just a matter of reach.
There is not even a JRE anymore - the standard way to package java apps is to bundle them with a specifically optimized JRE for your app, for exactly this reason.
Also, it’s not like people just click on exes anymore, desktop apps are a tiny niche.
Also, it’s not like people just click on exes anymore, desktop apps are a tiny niche.
How is that different to Python, Ruby, Node, etc? There is at least jlink which creates standalone app directories, and native-image, which makes AOT compiled native (standalone) binaries.
> Java is the least cross platform language in existence.
That's extremely hyperbolic. Try writing a cross OS program in C or C++ and tell me how it goes. #ifdefs everywhere.
Running a Java program through maven or gradle is very straight forward. Versioning works really well. Not to mention the excellent cross platform handling implementations built into the JVM.
That's extremely hyperbolic. Try writing a cross OS program in C or C++ and tell me how it goes. #ifdefs everywhere.
Running a Java program through maven or gradle is very straight forward. Versioning works really well. Not to mention the excellent cross platform handling implementations built into the JVM.
I agree, Java is just really good at being cross-platform. Python and sometimes even JS will have some non-portable dependency through FFI, while Java can truly be developed and deployed on anything, really (due to the platform being very pure, FFI is almost nonexistent unless absolutely necessary)
At this point I feel like C# exists in pretty much the same space but solves the same problems better. Java doesn’t seem to solve a unique problem any more or solve common problems better than other languages.
The only thing I am missing in C#/.NET is more GC options. Java lets you DIY, or completely turn it off.
For everything else, I would have a hard time making an argument against C#.
For everything else, I would have a hard time making an argument against C#.
You can do some weird stuff to GC in C#. I haven't looked at it in several years, but I'm pretty sure there's a way to suspend GC at runtime. There's definitely a mechanism to force immediate GC, and functions to exempt an object from GC.
C# is a lot more flexible than people give it credit for, I've seen some absolutely amazing things built this way. Of course, manipulating C# in unexpected ways is an absolute nightmare, but with enough determination you can do about anything
C# is a lot more flexible than people give it credit for, I've seen some absolutely amazing things built this way. Of course, manipulating C# in unexpected ways is an absolute nightmare, but with enough determination you can do about anything
I believe you can be notified when a collection is imminent. I saw a service use that to remove instances from the load balancer before that happened - super useful for higher-percentile latencies.
I looked into all of this, and still have a use case where it doesn't quite work out as well as it could with Java.
I can almost make it work with some pretty aggressive hackarounds, such as subdividing my service into multiple, smaller processes that each operate w/ workstation GC mode. GC runs pretty fast when object count is reasonable. Something like 1 process per latency-sensitive client is where I am at with .NET right now.
I can almost make it work with some pretty aggressive hackarounds, such as subdividing my service into multiple, smaller processes that each operate w/ workstation GC mode. GC runs pretty fast when object count is reasonable. Something like 1 process per latency-sensitive client is where I am at with .NET right now.
Is there a Unix backend official runtime part certified and enterprise-level supported for it? Most corporation require this and no CTO will risk going for anything less.
Kestrel works on UNIX.
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/s...
To me, this is an interesting discussion. I can't see a single argument for Java anymore except "devs knows it".
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/s...
To me, this is an interesting discussion. I can't see a single argument for Java anymore except "devs knows it".
Better observability tools, much much bigger ecosystem (this alone probably wins the argument — there is a tendency on .NET’s side to just copy famous java libs, but worse.), better GC (sure, C# has a potentially lower performance floor due to value types/pointers/etc, but when you do have to use GC (which is most server side app), there is no match for Java’s)
[deleted]
I worked at a startup that used it. Great performance, easy to hire for, library for everything. This was 5 years ago so the .net core story wasn't as good then.
I have used it in a startup.
We're using it (ok, but converted a big bunch of it to kotlin haha). Depends on the sector I guess.
Same boat. Not sure I'd pick in case we could start over. Quite happy it was picked over, say, PHP, JS/Node, Python...
Yeah, same! I kind of favor golang, but as we're building a fintech SaaS I'm not sure I would want to write that in golang without the nifty OOP/functional stuff in Kotlin.
You can do everything better in either TypeScript (for cognitively simple things) or Rust (for complex things that need to work correctly and be fast).
There is certainly cases where Java is better than Rust (gasp I said it!)
Purely from a productivity standpoint, Java is faster to write than Rust (you don't have to think about memory lifetimes and compile times are faster, I think IDEs for Java are better than Rust LSP), and you only need to optimize hot codepaths, not your whole program. Dynamic dispatch and GC give you a lower ceiling, but in the majority of systems you don't need that last bit of performance.
Purely from a productivity standpoint, Java is faster to write than Rust (you don't have to think about memory lifetimes and compile times are faster, I think IDEs for Java are better than Rust LSP), and you only need to optimize hot codepaths, not your whole program. Dynamic dispatch and GC give you a lower ceiling, but in the majority of systems you don't need that last bit of performance.
But those are instances where you can use TypeScript/node.js which is less verbose than Java and has better native async support. Also easier to write tests for.
Also VSCode with Rust Analyzer works decently as an IDE.
Also VSCode with Rust Analyzer works decently as an IDE.
Certainly not knocking rust analyzer – it's great! I think the missing piece of node versus Java is Java has first class support for threading, so I guess it depends if your system is IO or CPU bound, but for CPU bound systems, Java is certainly better than node. My naive understanding of Java's Jit and nodes jit is that Java's has more optimizations for CPU bound workloads, where a lot of v8s optimizations have gone into faster parsing and initial loading because that's an important use case for the web compared to Java which is mostly optimizing for the server use case at this point.
We've built a huge stack in it. (Well, Kotlin). Love it, and hiring is easy.
I feel like if you're using Kotlin, then you count as avoiding Java for the purposes of this discussion.
OP here. Actually, no, I mistitled the question, should have included Kotlin. I do consider Java and Kotlin to be part of the same ecosystem that is being avoided.
Kind weird perception. I did a startup 6 years ago that was Kotlin all the way.
cus it sux
Because startups are negotiating with employees for sub-standard pay, usually.
So you need to do things to convince the hotshots to come work for you, and Java is boring corporate coding, it's not the latest hotshit like Rust is.
And conversely, they're also negotiating with VCs for funding, and customers. Being able to describe the hotshot language helps differentiate as to why "this startup will make it work".
So you need to do things to convince the hotshots to come work for you, and Java is boring corporate coding, it's not the latest hotshit like Rust is.
And conversely, they're also negotiating with VCs for funding, and customers. Being able to describe the hotshot language helps differentiate as to why "this startup will make it work".
I dunno, Java 17 is like "ML, the good parts" Particularly in JDK 19 with the preview flags, it is a blast using pattern matching and other new features to write compilers and similar things. It's not like Scala which compiles line noise just fine.
If a startup avoids Java, it’s because the first few coders don’t use Java. That’s it.
I’ve seen startups use almost every language under the sun, including the boring ones like Java, C, and PHP.
I’ve seen startups use almost every language under the sun, including the boring ones like Java, C, and PHP.
Yep. The majority of startups in biotech use python mainly because it is much easier to find python programmers. Many of them have messy code base. They could probably do much better with Java IMHO.
warning opinion ahead...
C boring? Never a dull moment with C.
PHP has a whole sub-reddit devoted to the fun that can be had with it https://www.reddit.com/r/lolphp/
Java, I do consider boring. But in a good sense. :)
C boring? Never a dull moment with C.
PHP has a whole sub-reddit devoted to the fun that can be had with it https://www.reddit.com/r/lolphp/
Java, I do consider boring. But in a good sense. :)
This is the most boring possibility so it is probably the correct guess :-)
Because it’s not “cool” anymore and it was left to languish for many years? In addition, many, and better, languages have come out since it was cool. The de facto replacement for Java is Kotlin, or at least it was until Oracle started caring about it again.
IMO, the biggest reason is how broken the Java ecosystem is. Java-the-language is mostly okay, Java-the-toolchain (JVM) is pretty great, but Maven/Gradle/etc. are awful.
Java is one of the few ecosystems that provides a software distribution ecosystem that doesn't allow distribution of sources alongside binaries. Additionally, it is a lot more common for Java dependencies to be a game of Jenga. Take for example, Gradle. Gradle literally cannot be built from source[1] because it relies on a binary cache of dependencies held by Gradle to build Gradle. There are many other examples of this. As a consequence, the Java ecosystem has become a security and maintenance nightmare that other ecosystems simply aren't.
As bad as Nodejs is, it doesn't do this. As difficult as .NET has been, the dependency hygiene is better there. As annoying as Go and Rust are, they provide better guarantees in their ecosystems than Java does. While Python and Ruby are "slower" than Java, they both make it up in developer productivity and transparent, well-reasoned tooling compared to Java.
[1]: https://twitter.com/decathorpe/status/1250048390228041729
Java is one of the few ecosystems that provides a software distribution ecosystem that doesn't allow distribution of sources alongside binaries. Additionally, it is a lot more common for Java dependencies to be a game of Jenga. Take for example, Gradle. Gradle literally cannot be built from source[1] because it relies on a binary cache of dependencies held by Gradle to build Gradle. There are many other examples of this. As a consequence, the Java ecosystem has become a security and maintenance nightmare that other ecosystems simply aren't.
As bad as Nodejs is, it doesn't do this. As difficult as .NET has been, the dependency hygiene is better there. As annoying as Go and Rust are, they provide better guarantees in their ecosystems than Java does. While Python and Ruby are "slower" than Java, they both make it up in developer productivity and transparent, well-reasoned tooling compared to Java.
[1]: https://twitter.com/decathorpe/status/1250048390228041729
> As difficult as .NET has been
Can you elaborate on the difficulty of .NET? (Purely curious!)
Can you elaborate on the difficulty of .NET? (Purely curious!)
> Java is one of the few ecosystems that provides a software distribution ecosystem that doesn't allow distribution of sources alongside binaries.
This is wrong, source distribution is a standard in maven.
> Gradle literally cannot be built from source[1] because it relies on a binary cache of dependencies held by Gradle to build Gradle.
This is wrong as well as pointed out in the thread.
> As a consequence, the Java ecosystem has become a security and maintenance nightmare that other ecosystems simply aren't. As bad as Nodejs is, it doesn't do this.
This is almost hilarious. I'm working at a company at the moment guiding security updates for java and node.js backends. The java backends are not an issue. The node.js backends are almost impossible to upgrade, the javascript-frontends are even closer to impossibility.
This is wrong, source distribution is a standard in maven.
> Gradle literally cannot be built from source[1] because it relies on a binary cache of dependencies held by Gradle to build Gradle.
This is wrong as well as pointed out in the thread.
> As a consequence, the Java ecosystem has become a security and maintenance nightmare that other ecosystems simply aren't. As bad as Nodejs is, it doesn't do this.
This is almost hilarious. I'm working at a company at the moment guiding security updates for java and node.js backends. The java backends are not an issue. The node.js backends are almost impossible to upgrade, the javascript-frontends are even closer to impossibility.
As a Java developer, sort of, who uses Maven (not Gradle) but spends more time fixing UI stuff (because that's where everything breaks), I don't recognise this at all.
I can't say I'm a Maven cheerleader but I find nodejs, sorry npm, with webpack, or yarn, babel, gulp, or... to be a confusing soup of incompatibility. Most of which moves on so quickly that whatever works this week is dead next week.
I can't say I'm a Maven cheerleader but I find nodejs, sorry npm, with webpack, or yarn, babel, gulp, or... to be a confusing soup of incompatibility. Most of which moves on so quickly that whatever works this week is dead next week.
I'd say it is the opposite. C# is a better language but the open source ecosystem is crippled because too many .NET developers believe "Microsoft, wrong or right"
I'd grant that Gradle is problematic but Maven is better than either pip or npm in most respects.
Unlike pip, Maven has a correct algorithm for resolving dependencies and the language is not full of footguns like
I'd grant that Gradle is problematic but Maven is better than either pip or npm in most respects.
Unlike pip, Maven has a correct algorithm for resolving dependencies and the language is not full of footguns like
pip --user
python
pip --user
Why would this be a problem? In what world would I care to build gradle on my own?
I only ever heard concerns about it from Guix people who are hard on bootstrappability (they literally have a few hundred kb C-subset compiler which can compile a whole-C compiler written in that subset which will be able to compile a normal C compiler, etc). But most platforms are not made for easy bootstrappability and it is not a concern in itself.
I think there are lots of valid barbs to throw the way of Java and the JVM ecosystem, but I'm slightly baffled that you'd choose tooling and maintainability. I've had a very happy, quiet 15 years or so on top of Maven and it's never ruined my day. In the meantime, the situation with Python and Ruby has been so thoroughly and reliably awful that basically the entire industry had to move to Docker to be able to get anything done.
> the Java ecosystem has become a security and maintenance nightmare that other ecosystems simply aren't.
What? NodeJS ecosystem with npm was a nightmare to every security team I've worked with. Java is much the opposite, you run a local Artifactory to cache your dependencies, you run security checks against the cached dependencies to guarantee everything your org is actually depending on doesn't have major holes, you can block dependencies from being pulled through your Artifactory proxy. Hell, your org can even provide a BOM/root POM describing exactly the supported versions for dependencies across the board.
I've been working as a SWE for almost 20 years, on my languages toolbelt for applications I've developed and maintained in production I have ASP 3.0, PHP, Ruby, Python, Go, JavaScript, Scala, Clojure and Java; from all of these ecosystems the one I've consistently been the most productive is the JVM and even Java itself I'd say.
I don't even like Java the language, I just think it's a great tool for a lot of jobs (even more if maintainability over the long-term is a must), but I sincerly can't see a single one of your points against Java materialised in my work experience...
What? NodeJS ecosystem with npm was a nightmare to every security team I've worked with. Java is much the opposite, you run a local Artifactory to cache your dependencies, you run security checks against the cached dependencies to guarantee everything your org is actually depending on doesn't have major holes, you can block dependencies from being pulled through your Artifactory proxy. Hell, your org can even provide a BOM/root POM describing exactly the supported versions for dependencies across the board.
I've been working as a SWE for almost 20 years, on my languages toolbelt for applications I've developed and maintained in production I have ASP 3.0, PHP, Ruby, Python, Go, JavaScript, Scala, Clojure and Java; from all of these ecosystems the one I've consistently been the most productive is the JVM and even Java itself I'd say.
I don't even like Java the language, I just think it's a great tool for a lot of jobs (even more if maintainability over the long-term is a must), but I sincerly can't see a single one of your points against Java materialised in my work experience...
This is one of the most ignorant comment I recently read on HN.
NPM dep system is a security nightmare. Try to publish something on maven central vs npm.
I don't remember last time I had a problem with maven, when we have daily with package.json / package-lock.json.
Python is a joke. Really. Tried using an airflow api for days. Having no static types, you have to rely on documentation, so good luck. python is ok for scripting, fee dozens LoC, not for serious enterprise dev.
In the enterprise world Java/jvm is THE way to go, there's just too many choices and possibilities. You don't like spring? No problem, there's endless other frameworks.
Python is a joke. Really. Tried using an airflow api for days. Having no static types, you have to rely on documentation, so good luck. python is ok for scripting, fee dozens LoC, not for serious enterprise dev.
In the enterprise world Java/jvm is THE way to go, there's just too many choices and possibilities. You don't like spring? No problem, there's endless other frameworks.
Among many reasons I think one is that it has a poor amount of open libraries/frameworks when you stack it up against other languages. The culture is much more DIY so there isn't a lot to help you get started with a new application.
I've never been a Java dev, but as I understand the package manager story is/was really bad. I've always wondered if that's part of the reason why you see so few open source efforts compared to other languages.
I've never been a Java dev, but as I understand the package manager story is/was really bad. I've always wondered if that's part of the reason why you see so few open source efforts compared to other languages.
When I was a Java dev I never had a problem with package management (except everyone bundling Log4J with different version dependencies).
When I've used Scala, package management was hell. When I've used Node, there were a million warnings about the dependencies of my dependencies whenever I installed something. Upgrading often broke things contrary to Java. Plus many dependencies went dead over night. When I've used JS libraries in TS, many integrations/adaptors where half baked and underdocumented.
I'd say the best dependency management I've used is from Rust, but Java was no problem, even with Maven.
The ecosystem might have changed since I've left, but there were many well maintained libraries and frameworks for Java, Apache, Spring and many more. What Java lacked were some higher level frameworks back than, E.g. ready to use payment frameworks (you had to use lower level frameworks like E.g. what Stripe supplied as a library).
When I've used Scala, package management was hell. When I've used Node, there were a million warnings about the dependencies of my dependencies whenever I installed something. Upgrading often broke things contrary to Java. Plus many dependencies went dead over night. When I've used JS libraries in TS, many integrations/adaptors where half baked and underdocumented.
I'd say the best dependency management I've used is from Rust, but Java was no problem, even with Maven.
The ecosystem might have changed since I've left, but there were many well maintained libraries and frameworks for Java, Apache, Spring and many more. What Java lacked were some higher level frameworks back than, E.g. ready to use payment frameworks (you had to use lower level frameworks like E.g. what Stripe supplied as a library).
I have to disagree here. For all it's faults there is a very robust ecosystem of libraries to choose from.
Java is one of the top 3 languages. It likely has as much open-source libs as, say, all the other languages combined down from the top 6.
Java has its technical issues, but for a startup its biggest liability is that its vibe is the polar opposite of how startups want to see themselves and be seen by others. It's reliable, stodgy, boring, conventional. How are you going to convince people that your project is "disruptive" if you aren't willing to embrace a younger, edgier tech stack?
This is the best explanation I have seen.
> How are you going to convince people that your project is "disruptive" if you aren't willing to embrace a younger, edgier tech stack?
Easy: Use Kotlin, which is extremely hip and compiles to the JVM. You can use the JVM then, and mix in java-support should you need it.
Easy: Use Kotlin, which is extremely hip and compiles to the JVM. You can use the JVM then, and mix in java-support should you need it.
> How are you going to convince people that your project is "disruptive" if you aren't willing to embrace a younger, edgier tech stack?
Deliver great software that solves a problem that people will pay you for?
Deliver great software that solves a problem that people will pay you for?
The people being convinced in this scenario are VCs, not customers, and the point is that VCs want to hear how your tech stack is going to morph into the second coming of crypto so they can get a huge exit. It has nothing to do with actually getting customers.
From a Devops perspective, I think people are accustomed to staring at a screenful of yaml or json output when something goes wrong, but not a screenful of XML. But at the sams time, a lot of places still use Jenkins, which is now the mature, legacy product. If you've been in the industry for more than a decade, this comes across as ironic, but no one knows what the next thing will be, that will finally put yaml in the rear-view mirror where it belongs.
1. Because they confuse Java with the standard hibernate/springboot backends that are used everywhere in the industry. Hibernate/springboot is the reason why there are so many monoliths out there that are almost impossible to refactor.
It's not Javas fault, it's Springs fault.
2. They believe Java is slow, but fail to realize that the JVM has actually one of the most optimized runtimes under the sun and can be fast than (unoptimized) C in many cases.
Long story short: Because they have no clue about Java and follow advice without researching it first.
It's not Javas fault, it's Springs fault.
2. They believe Java is slow, but fail to realize that the JVM has actually one of the most optimized runtimes under the sun and can be fast than (unoptimized) C in many cases.
Long story short: Because they have no clue about Java and follow advice without researching it first.
Very subjective reasons from one or two decades ago - possibly outdated now:
* lack of user-friendly UIs in the end product
* super frustrating *NullPointerException* showed to confused users in (almost) all java programs they get close to - despite java enthusiasts assuring that good programs should not feature that.
* annoying frequent update popup shown to end users, with bloated process pushing to install other unrelated stuff
* creating a super tiny dependency program in java results in a hundreds-megabytes distributable because (??)
* heavy and bloated IDEs
* confusing JRE / JDK required installs
* licensing confusion once Oracle made Oracle Java SE paid
* supposed to be multi-platform but tricky to make it work well on some versions of linux (painful memories using pentaho or gephi, finding the right file where to set-Xms<memory> -Xmx<memory> flags after a crash)These were outdated even in the 2000s.
Java is great fit for large teams, but personally feels less productive than Python or JS. Startups do start with small teams. The Java overhead doesn’t make sense.
Very much disagree. Your argument seems like a static typing vs not and unless you're writing a small trivial thing, having types very quickly bear fruit. Also most of the good code I read these days are data oriented programs (which is largely inspired by functional programming and see rules 5 here http://users.ece.utexas.edu/~adnan/pike.html) and types are very important to get the transformations correct in these systems.
Both Python and JS have static typing.
Edit: remove unnecessary snark
Edit: remove unnecessary snark
Strong typing maybe? Depends on what you define these terms to be. For me. Static typing is a compiler that verifies your types are correct. Neither Python nor JavaScript has this. Python allows for type annotations, which is very different. It has no (builtin) enforcement. JavaScript has no type pins whatsoever, TypeScript does. There is a proposal to add types to JavaScript but that's not approved AFAIK
Right, when I said JS with static typing, I meant TypeScript. Python has type checkers, see mypy and pyright, and I use them regularly. Most bugs that could be found by static type checker no longer make it into test or production for me.
Out of fashion.
But I've worked in two startups, one sold for $600M and one sold for $200M and both were Java based (The startup I co-founded used Scala (never again ;-) on the JVM eco system and was also successfully sold, though for less than $200M)
Technologies come and go (and sometimes come back like Python). When I started Java in the 90s it was replacing often Perl on the server, as the first apps were writen by Unix admins who used Perl, which went out of fashion.
But I've worked in two startups, one sold for $600M and one sold for $200M and both were Java based (The startup I co-founded used Scala (never again ;-) on the JVM eco system and was also successfully sold, though for less than $200M)
Technologies come and go (and sometimes come back like Python). When I started Java in the 90s it was replacing often Perl on the server, as the first apps were writen by Unix admins who used Perl, which went out of fashion.
Java has a bad reputation for being bloated and/or slow. I find Java and Go to be fairly similar (both GC'd, both fairly high performance, both statically typed), and yet Go has a reputation for being compact and fast.
Java isn't particularly fun or thrilling to write. If you're a founding CTO or a founding team of engineers, of course you're going to choose something more "interesting" for a greenfield project.
Java isn't as quick and dirty as other languages. I think this almost fully explains the prevalence of node, because after being stuck in the node ecosystem for two years, I truly can't imagine why anyone would choose to build anything substantial in node.
Java isn't particularly fun or thrilling to write. If you're a founding CTO or a founding team of engineers, of course you're going to choose something more "interesting" for a greenfield project.
Java isn't as quick and dirty as other languages. I think this almost fully explains the prevalence of node, because after being stuck in the node ecosystem for two years, I truly can't imagine why anyone would choose to build anything substantial in node.
The funny thing is that Go is more verbose than Java, while this is never mocked in Go.
More verbose but easier to read and reason about in my opinion. A trade-off I’ll happily make.
I don’t know, Java is a more expressive language which allows for more abstractions. This can be abused, but I think Java does strike a good balance here. You can express something like the Stream API (which is imo much more readable than deeply nested loops), while most of your code will still be ordinary method calls on objects. There certainly is an enterprise style of Java, but that is not inherent in the language, and modern Java really tries to grow away from it.
I think a big part of it is cultural. Java is a great language with tons of supporting frameworks, build systems, etc. But it's mostly geared towards larger enterprise companies. For a startup that is trying to be quick and nimble to get started, it doesn't attract the right type of talent or workflows. It can definitely be used for a startup and some do, but the hacker-y startup devs tends to lean towards other solutions.
I can work much faster on Python than Java and I know both pretty well. I'm not aiming for scalability in the initial stages of my imaginary startup.
That being said, it wouldn't be the worst thing for me to start with Java
That being said, it wouldn't be the worst thing for me to start with Java
Personally I find it much much MUCH easier to bootstrap a project with Python, Go or even JavaScript than Java, especially when third-party libraries are involved. (I hate dealing with Maven or Gradle.)
Kotlin and Scala are different from what I understand.
Also, from what I can gather, most developers entering the industry come with JavaScript and Python experience. So there's that to consider.
Kotlin and Scala are different from what I understand.
Also, from what I can gather, most developers entering the industry come with JavaScript and Python experience. So there's that to consider.
What's the point of a JVM when your server environment is using the x86 instruction set and running Linux? The world today is very different from the world of the early 90's when Java was being developed. You want garbage collection, high performance, a vibrant ecosystem, and good build and distribution tools? Then you want Go.
As many others in this thread have said, using a newer (Go is 10 years old) stack is appealing to VC's, and the hotshot programmers you're trying to attract and trade salary for stock options. This is the best strategy.
If you really need to use the JVM for some reason then consider using another language on top of it such as Kotlin or Clojure. In 2022 saying your hot new startup is using Java is pretty much equivalent to saying you're using Cobol. Don't be surprised if it doesn't generate much interest from investors or developers.
As many others in this thread have said, using a newer (Go is 10 years old) stack is appealing to VC's, and the hotshot programmers you're trying to attract and trade salary for stock options. This is the best strategy.
If you really need to use the JVM for some reason then consider using another language on top of it such as Kotlin or Clojure. In 2022 saying your hot new startup is using Java is pretty much equivalent to saying you're using Cobol. Don't be surprised if it doesn't generate much interest from investors or developers.
Go’s GC is a generation behind Java’s, and while value types can alleviate the need of a good GC to a degree, long-living server applications do predominantly have very varying object lifetimes, so a GC is non-negotiable — Java usually has better performance in these use cases (it is not an accident that huge servers with terabytes of RAM running core internet services most often use Java, like Alibaba, AWS, many Google servers). Also, you sure know that Java spends most of its time executing native machine code for the architecture at hand, so your first paragraph is meaningless. On top, java’s ecosystem is much bigger than Go’s, and it has much better observability tools to monitor even prod instances.
Python is simpler than Java. This might not be a very important factor in software engineering of large products, but it is very important for prototyping.
Also, a lot of research in ML is done in Python, and there are quite a lot of startups doing ML, so Python is a natural choice. Same for data science.
Also, a lot of research in ML is done in Python, and there are quite a lot of startups doing ML, so Python is a natural choice. Same for data science.
Simpler is very subjective. Java is a good language for large enterprises is because its so standardized. Almost anyone at various levels can pretty much pick up and start contributing.
Python, has so much syntactical sugar that it can get really messy.
Python, has so much syntactical sugar that it can get really messy.
Is it? Sure, some basic code probably is. But there is much more magic happening in Python than in Java, even with Spring’s dynamic class creation and whatnot.
This is harsh, but as someone that has done a lot of enterprise Java development, the only reason to avoid Java is the developers. Specifically, the enterprise priests of Spring.
Java is fine language and the JVM is a great runtime, but unfortunately the language itself is like a bug zapper light for graybeard enterprise devs who are not so much "Java developers" as they are "Spring engineers" (though they often refer to themselves as architects). They usually have a flair for overly complex abstraction and an encyclopedic knowledge of a couple decades worth of Spring spells, er, annotations.
They typically don't build as much as they just hook shit together with Spring. Every solution is always, "oh just use yadda yadda Spring annotation/plugin." Sometimes it works, often you end up spending the day learning about yet another convoluted hunk of shit that your project just absorbed. Every Spring project turns into a myriad of black boxes where everything happens everywhere else and you're always just a few plugins short of having what you need.
For enterprises this works... okay. They're big and they have a lot of money, so they usually prefer slow, complex, and consistent over rapid development dice rolls. For startups, a seasoned Java enterprise dev is like a rat. If you let one get in the door you're going to be dealing with a fucking mess in no time.
Java is fine language and the JVM is a great runtime, but unfortunately the language itself is like a bug zapper light for graybeard enterprise devs who are not so much "Java developers" as they are "Spring engineers" (though they often refer to themselves as architects). They usually have a flair for overly complex abstraction and an encyclopedic knowledge of a couple decades worth of Spring spells, er, annotations.
They typically don't build as much as they just hook shit together with Spring. Every solution is always, "oh just use yadda yadda Spring annotation/plugin." Sometimes it works, often you end up spending the day learning about yet another convoluted hunk of shit that your project just absorbed. Every Spring project turns into a myriad of black boxes where everything happens everywhere else and you're always just a few plugins short of having what you need.
For enterprises this works... okay. They're big and they have a lot of money, so they usually prefer slow, complex, and consistent over rapid development dice rolls. For startups, a seasoned Java enterprise dev is like a rat. If you let one get in the door you're going to be dealing with a fucking mess in no time.
>They typically don't build as much as they just hook shit together with Spring.
>They're big and they have a lot of money, so they usually prefer slow, complex, and consistent over rapid development dice rolls.
These two statements seem contradictory to me. The entire point of using Spring is to be able to not worry about the cumbersome and gain efficiencies in development. Spring is no different than rails, a framework thats highly regarded for fast development
>They're big and they have a lot of money, so they usually prefer slow, complex, and consistent over rapid development dice rolls.
These two statements seem contradictory to me. The entire point of using Spring is to be able to not worry about the cumbersome and gain efficiencies in development. Spring is no different than rails, a framework thats highly regarded for fast development
I'm sure it is highly regarded... My own (admittedly limited) experience is it is a hell hole of abstraction, vast stack traces, obscure error messages and grindingly slow performance.
Apparently the things I want to do are either impossible or require so much indirection it's easier to rip it out and just write it yourself...
You may have detected I'm not a fan!
Apparently the things I want to do are either impossible or require so much indirection it's easier to rip it out and just write it yourself...
You may have detected I'm not a fan!
Yes, it takes time to learn a complex framework.
With Spring Boot a lot has been simplified, I never used Spring before that because I had similar thoughts as you.
Nowadays when I have to work without Spring (my current job doesn't use it, for example) I keep yearning for it as there's just so much productivity gains after you know the framework.
It's funny because I have said in the past the exact same arguments as you, it just comes from lack of experience. I recommend stop hating it and sincerely give a try on properly learning and using it for a while, I still have some reservations and grievances with Spring but not these shallow ones :)
With Spring Boot a lot has been simplified, I never used Spring before that because I had similar thoughts as you.
Nowadays when I have to work without Spring (my current job doesn't use it, for example) I keep yearning for it as there's just so much productivity gains after you know the framework.
It's funny because I have said in the past the exact same arguments as you, it just comes from lack of experience. I recommend stop hating it and sincerely give a try on properly learning and using it for a while, I still have some reservations and grievances with Spring but not these shallow ones :)
I don't really disagree with you. I'm sure it's possible to be really productive in it. It has a steep learning curve of course.
Having said that, I stand by my performance criticism. I have done some detailed profiling on spring and non spring versions of code (I didn't write the spring parts, a spring expert did). It really does add a lot of overhead to start up and transactions vs. straightforward POJOs and JDBC code.
Having said that, I stand by my performance criticism. I have done some detailed profiling on spring and non spring versions of code (I didn't write the spring parts, a spring expert did). It really does add a lot of overhead to start up and transactions vs. straightforward POJOs and JDBC code.
Was this profiling done while using `JdbcTemplate`? To be honest I don't use much more than that for querying RDBMSs, I don't like any kind of ORM and actively avoid them.
No, just straight JDBC, no Spring classes at all.
It used to be hip and trendy but then Oracle came.
In principle there's nothing wrong with Java but every Java shop I've worked at has made me sad. Lots of dynamic stuff glued together by plugins, DI, crazy configs, weird XML meta languages, runtime NPEs, stuff falling over at all hours, everyone on-call, etc...
Python shops weren't much better. Enormous products of complexity, plugin frameworks to config other plugins...
Go is not without its problems but at least it reins in much of the dynamic complexity (although systems like K8S built above it seem to add it back). For a lot of things it's better than Java or Python.
I haven't yet worked at a Rust shop but I've used it on a few small things of my own and it seems to strike a good balance and Rust/Wasm looks really promising.
So if I have the choice I'll go with a Rust startup, a Go startup, a Python/Java startup in that order.
Python shops weren't much better. Enormous products of complexity, plugin frameworks to config other plugins...
Go is not without its problems but at least it reins in much of the dynamic complexity (although systems like K8S built above it seem to add it back). For a lot of things it's better than Java or Python.
I haven't yet worked at a Rust shop but I've used it on a few small things of my own and it seems to strike a good balance and Rust/Wasm looks really promising.
So if I have the choice I'll go with a Rust startup, a Go startup, a Python/Java startup in that order.
What are the legal implications of using Java / the JVM in a commercial project these days?
We're talking about Oracle here.
We're talking about Oracle here.