Ask HN: Why do startups avoid Java?
Based on: https://www.workatastartup.com/companies?role=eng&role_type=be
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
Can you elaborate on the difficulty of .NET? (Purely curious!)
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.
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 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
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...
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.
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'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
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!
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 :)
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.
I’ve seen startups use almost every language under the sun, including the boring ones like Java, C, and PHP.
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. :)
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.
Deliver great software that solves a problem that people will pay you for?
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.
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".
For everything else, I would have a hard time making an argument against C#.
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 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.
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".
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.
Also, it’s not like people just click on exes anymore, desktop apps are a tiny niche.
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.
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.
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.
Also VSCode with Rust Analyzer works decently as an IDE.
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.
* 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)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.
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.
Edit: remove unnecessary snark
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.
Python, has so much syntactical sugar that it can get really messy.
That being said, it wouldn't be the worst thing for me to start with Java
We're talking about Oracle here.
I've worked one two database systems written in JVM tech and the performance was good.
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.
Still, having one language that's good at all of these does sound attractive. The excessive boilerplate is annoying, though.
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.
All of this is also true about Go, but it's on the high tide on the hype cycle.
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.
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.
>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
A level talent is a bottleneck as they will move on for better opportunities. I wouldn't focus my company around that either.
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.
Java has excellent package management and there is a giant ecosystem and excellent libraries for almost everything you can think of.
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).