9 ms·

Irrational Fear of Java is one of the most confusing things among startup stage companies.

by jpgvm 4y ago

re-thc 4y ago
It's not just startups where this happens. In older companies you have older "leaders" that claim to have been hit by Java 5-10 years ago so don't trust it. Yet they've never tried it again since.
hombre_fatal 4y ago
You can tell when a programming language conversation has become toxic when negative qualities are assigned to the people who choose (or apparently don't choose) someone's favorite language. In this case, it's an "irrational fear" of Java to have preferences beyond Java.
jjav 4y ago
> Irrational Fear of Java is one of the most confusing things among startup stage companies. This so much. It's exhausting to experience startups shoooting themselves in the foot by not using Java where it's best simply because it's not hip. Golden rule for startups, spend your innovation capital on your product not on trendy (unproven, immatue) implementation technologies. Use boring (aka mature, high performance, best tooling) technology.
flippinburgers 4y ago
Not fear. Disgust.
- peterashford 4y ago
  that's a ridiculous attitude.
junon 4y ago
Yeah. Java isn't particularly sexy. But it gets the job done. I'd even settle for Java 7 still, it was more than enough to get the job done, especially when you are a startup trying to get an MVP out the door that can still be refactored and maintained somewhat easily when you bring in more skilled developers.
TurboHaskal 4y ago
It's not the language that gave me PTSD but the userbase, "best practices" and culture around it. Java itself is great these days.
- adgjlsfhk1 4y ago
  IMO, Java won't be decent until Valhalla is completed. The broken type system is a really big downside compared to C#.
- Cthulhu_ 4y ago
  I was going to say, Java is fine, it's the architectures and mountains of code spread across loosely coupled architectures that does it for me. I wouldn't mind a modern day Java project, as long as it's free of the 20+ year old dogmatic practices. I'd have to unlearn a lot of those myself, probably.
  - polotics 4y ago
    Also the culture of those that stuck to Java because they didn't have the curiosity to learn anything else...
    - marginalia_nu 4y ago
      Well yeah...? That's a big part of why I mostly use Java, so I don't have to constantly figure out basic stuff in whatever language/framework that's hot this week. The language is just a tool. It's not an ends in itself. I can spend that time building things instead. If I have an idea I can implement it. Downstream dependencies are rock solid, and the language changes at a manageable pace. Like I did some stuff in python the other week, and every other line I wrote had to stop several minutes and figure out basic syntax stuff. Just a pain in the ass. Like I probably could take the time and freshen up on python and be up to speed in a few weeks, but that's a few weeks I'm not moving toward my goals.
esafak 4y ago
It's not. Java programmers I've seen don't use the latest idioms; they use pre-8.0 Enterprise Edition-ware because that's what they've been taught. It's a hideous sight and it has a lot of inertia. That's why I prefer kotlin.
- re-thc 4y ago
  What does this have to do with Java? As in there are no Javascript developers that use Promises instead of async/await? There's always legacy and people that live with it. It's a feature that there's no history now? And soon we're going to cry about Kotlin developers that don't use the latest idioms... oh give it a few years...
  - afavour 4y ago
    It’s all relative, though. One of the biggest complaints people have about the JS ecosystem is the lack of legacy: people do move from Promises to async quickly, when React switches to hooks everyone switches quickly, etc etc. For better or worse you can’t say the same about Java.
    - re-thc 4y ago
      > people do move from Promises to async quickly, when React switches to hooks everyone switches quickly, etc etc On Reddit or HN? Definitely in not the real world. Plenty of projects and even recently created 1s don't always use these new ways of working. Even on Reddit when I see a new project getting posted it doesn't have this trait you mention. And lots of companies are still on Node 14/16 or even older :( only forced to move by e.g. AWS lambda runtime requirements... And Node developers are still using ExpressJs and promote it all the time. Guess when Express 4 was released? 5 has been in beta forever with no updates. Yet, most promote it and ignore the other options. Lack of legacy? This thing is 10+ years old. It's barely maintained... what's the difference?
datadeft 4y ago
I am not sure there is fear against Java as much as there are better alternatives for many use cases.
- kaba0 4y ago
  I would argue the “many”, especially when we talk about regular old CRUD apps most startups are.
jve 4y ago
Can you compile so that JRE is bundled with the program? I'm a C# developer and I also have a kind of resistance of java - having to install JRE and now the minefield Oracle made with the JRE, I'm hoping not only that I don't have to code in it, but that I don't have to use ANY Java program just to avoid the runtime or have to choose between different versions of it. And then the .jar files and how you execute them in command line is different (java -jar), maybe it is simple, but it is different than a plain executable file.
- kaba0 4y ago
  Yes, there is in fact not even a JRE for quite some years now. Also, Oracle being a minefield is just bullshit - they are the ones that open-sourced the platform completely to the point that their paid version is only marginally different, but OpenJDK is the reference implemented. They are surprisingly good stewards of the language.
  - jve 4y ago
    Our employer actively tracks runtime usage and makes sure we have no O in it. > The quantity of licenses is determined by the total number of employees, not the number of employees using the programs https://www.infoworld.com/article/3686611/oracle-per-employee-java-pricing-causes-concern.html https://www.infoworld.com/article/3686611/oracle-per-employe... > Employee for Java SE Universal Subscription: is defined as (i) all of Your full-time, part-time, temporary employees, and (ii) all of the full-time employees, part-time employees and temporary employees of Your agents, contractors, outsourcers, and consultants that support Your internal business operations. The quantity of the licenses required is determined by the number of Employees and not just the actual number of employees that use the Programs. https://www.oracle.com/us/corporate/pricing/price-lists/java-se-subscription-pricelist-5028356.pdf https://www.oracle.com/us/corporate/pricing/price-lists/java... Excuse me, but isn't that a minefield? Another point I don't want to use java: Now I have to understand what is Java SE and if the runtime falls under it or the development tools or how my users use the software, whether we now how to license every user that won't even use that program and even any people that interacts with our business. Pure maddness.
tehbeard 4y ago
Java has the lingering shadow of Oracle hanging over it. That legalistic hydra is enough to make you second guess using it.
- jjav 4y ago
  > Java has the lingering shadow of Oracle hanging over it. This myth needs to be dispelled. OpenJDK is Java, and is open source under GPL. https://en.wikipedia.org/wiki/OpenJDK https://en.wikipedia.org/wiki/OpenJDK https://github.com/openjdk/jdk/blob/master/LICENSE https://github.com/openjdk/jdk/blob/master/LICENSE
- lenkite 4y ago
  Would you ditch Linux, because Canonical has been making concerning decisions with Ubuntu ?
  - tehbeard 4y ago
    False equivalence. Canonical doesn't own the Linux trademark, nor have the litigation history.
tecleandor 4y ago
Sysadmin here. It's true Java still smells like "corporate" and "slow". And when I say "slow", I don't mean the runtime speed, but the company speed ;) Until not a long time ago I've been maintaining a bunch of Sun|Oracle|J9 Java 6 + JBoss 4.2.3 + AIX|Linux + PPC|x86_64 ... That was not fun, and the task of moving it to more modern platforms was insurmountable to us. No wonder Azul has support for Java 6 until 2027. But it's true the platform has changed greatly in every way: The VM, the ecosystem... are so different now. And although as a language, it still feels strange to me (I just use Python), now that I manage a fleet of modern Java and Scala microservices, I don't get scared when I hear the name "Java" :)
- jpgvm 4y ago
  Yeah fair. Old JVM land and Modern JVM land really are worlds apart.
throwaway74567 4y ago
I see Java/Kotlin as a secret weapon for startups. Too often I read about startups that struggle with immature libraries, smaller eco systems and reinventing basic functionality. Problems that they would not have if they chose a mature technology. These blog posts mentions a company that has to write their own database library, auth services or other basic functionality. Sometimes they fix so many issues with the core language that they become close partners with the core developers of the programming language. I can't help wonder if the competition also reads the post and just smiles before they go back to actually solving a business problem. To me it's a symptom of choosing the wrong stack, even though working on non-business related problems may be more rewarding to the individual.
- erik_seaberg 4y ago
  I’m reminded of “Fire and Motion:” > Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET—All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features.
the_gipsy 4y ago
Irrational Fear is actually what is waged on the Java front. People doing mental gymnastics to avoid touching anything non-Java. Cargo-culting. I've witnessed Java devs proposing changing an existing Go project's build system to maven because "that's what they know well". Straight insanity. People that avoid Java don't do it because of some stigma, but because they have been burned before. Remember that a typical Java project is not the latest version and uses a mix of dependencies that make using newer features impossible. Then, there is no point in updating, you might as well rewrite it. That is the reality.
- peterashford 4y ago
  I work in a Go shop and we try to get rid of non-Go parts of our stack to make things simpler and more consistent.
black3r 4y ago
Startup stage companies work on smaller codebases and primarily need to go as fast as possible from nothing to a working prototype without the need to use many advanced features.... Java is a good language, but the community around it, whether it's experienced developers or libraries are built for enterprises, who work on huge codebases and their primary concerns are security, performance, scaling, testing, all of which are secondary in most startup environments and usually only start to matter years after the startup codebase is created...
- jjav 4y ago
  > security, performance, scaling, testing, all of which are secondary in most startup environments I've done quite a few startups by now and I can say that in all of them the initial quick-n-dirty MVP codebase lasted well into the era where things like "security, performance, scaling, testing" became a priority. Unless you are absolutely committed to throwing away the MVP (and I don't see how you could because as soon as sales team sees it they start selling it and you won't have time to throw it away), your best early move is to use technologies that will take you to the long haul because you will be stuck with that initial code for a very long time. (This doesn't mean architecting the whole system for scale you won't hit in years, mind you. Just to use technologies that will make the transition to a mature engineering team easier. Such as Java, given the topic of this conversation.)
- jpgvm 4y ago
  In my experience the zero to something stage lasts way longer than people think and the cost of using immature and badly suited stacks like Typescript/etc bites way sooner than people think. They just keep pushing through it and telling themselves this is faster and everyone else is doing it so it can't be wrong. Case and point I built a new service recently in Kotlin on JVM. It's a SQL translation gateway that maps an internal representation of simplified relational query model onto other databases so you can connect your own MySQL, PostgreSQL, Oracle, SQL Server, etc. Because Java has such a deep ecosystem in this area I was able to leverage JDBC and jOOQ to deliver support for all the require database types in only a few days of work with very clean code and full test coverage that tests compatibility with all the target databases. Imagine trying to do that in Typescript. You don't have a standardised interface to database drivers so you would need to first choose that abstraction and implement it yourself + adapters for each driver you need to support (i.e re-inventing JDBC). Then you need to handle the different SQL dialects as they all have different quoting rules, different LIMIT/OFFSET syntax, different supported LIKE/ILIKE/etc, there is no library for handling this in Typescript, especially not with support for commercial DBs like Oracle, SQL Server and -definitely- not for more esoteric stuff like HANA and Informix, etc. Just writing a dialect agnostic query builder abstraction is weeks of work, actually handling all the dialects and emulating anything that isn't native for your targets is much longer. So you might say, "but that is just libraries"... however that -is- the entire point. When you buy JVM you are buying the ecosystem of libraries primarily. The very nice runtime/GC/languages is really just icing. Same way that when you buy Python you are really buying numpy/pandas/PyTorch/etc, the language itself isn't the important part. Or you could say this is just a problem uniquely suited for JVM and you wouldn't be wrong but isn't that also the point? Use the right tool for the job. JVM is to business logic and solving business problems what Python is to data science and machine learning. The big epiphany I had recently was that when I build on JVM I don't write much code. I make a design, assemble some libraries in the correct way, iterate on it by refactoring until the abstraction is clean and then turning it on. There is very little mechanical coding involved because everything fits together very cleanly with only business logic being surfaced in actual "code". I feel more like an architect, less like a code monkey and I can ship results way faster because I don't have to work on code that doesn't directly solve the problem. i.e there are much less yaks to shave.
eptcyka 4y ago
Irrational fear of Oracle is actually a perfectly valid factor in my opinion.
- jjav 4y ago
  > Irrational fear of Oracle is actually a perfectly valid factor in my opinion. Fear of Oracle is rational though, unlike fear of Java.

Irrational Fear of Java is one of the most confusing things among startup stage companies.

by jpgvm 4y ago

Irrational Fear of Java is one of the most confusing things among startup stage companies.

It's not just startups where this happens. In older companies you have older "leaders" that claim to have been hit by Java 5-10 years ago so don't trust it. Yet they've never tried it again since.

hombre_fatal 4y ago

You can tell when a programming language conversation has become toxic when negative qualities are assigned to the people who choose (or apparently don't choose) someone's favorite language. In this case, it's an "irrational fear" of Java to have preferences beyond Java.

jjav 4y ago

> Irrational Fear of Java is one of the most confusing things among startup stage companies. This so much. It's exhausting to experience startups shoooting themselves in the foot by not using Java where it's best simply because it's not hip. Golden rule for startups, spend your innovation capital on your product not on trendy (unproven, immatue) implementation technologies. Use boring (aka mature, high performance, best tooling) technology.

flippinburgers 4y ago

Not fear. Disgust.

peterashford 4y ago
that's a ridiculous attitude.

junon 4y ago

Yeah. Java isn't particularly sexy. But it gets the job done. I'd even settle for Java 7 still, it was more than enough to get the job done, especially when you are a startup trying to get an MVP out the door that can still be refactored and maintained somewhat easily when you bring in more skilled developers.

TurboHaskal 4y ago

It's not the language that gave me PTSD but the userbase, "best practices" and culture around it. Java itself is great these days.

adgjlsfhk1 4y ago
IMO, Java won't be decent until Valhalla is completed. The broken type system is a really big downside compared to C#.
Cthulhu_ 4y ago
I was going to say, Java is fine, it's the architectures and mountains of code spread across loosely coupled architectures that does it for me. I wouldn't mind a modern day Java project, as long as it's free of the 20+ year old dogmatic practices. I'd have to unlearn a lot of those myself, probably.
- polotics 4y ago
  Also the culture of those that stuck to Java because they didn't have the curiosity to learn anything else...
  - marginalia_nu 4y ago
    Well yeah...? That's a big part of why I mostly use Java, so I don't have to constantly figure out basic stuff in whatever language/framework that's hot this week. The language is just a tool. It's not an ends in itself. I can spend that time building things instead. If I have an idea I can implement it. Downstream dependencies are rock solid, and the language changes at a manageable pace. Like I did some stuff in python the other week, and every other line I wrote had to stop several minutes and figure out basic syntax stuff. Just a pain in the ass. Like I probably could take the time and freshen up on python and be up to speed in a few weeks, but that's a few weeks I'm not moving toward my goals.

esafak 4y ago

It's not. Java programmers I've seen don't use the latest idioms; they use pre-8.0 Enterprise Edition-ware because that's what they've been taught. It's a hideous sight and it has a lot of inertia. That's why I prefer kotlin.

re-thc 4y ago
What does this have to do with Java? As in there are no Javascript developers that use Promises instead of async/await? There's always legacy and people that live with it. It's a feature that there's no history now? And soon we're going to cry about Kotlin developers that don't use the latest idioms... oh give it a few years...
- afavour 4y ago
  It’s all relative, though. One of the biggest complaints people have about the JS ecosystem is the lack of legacy: people do move from Promises to async quickly, when React switches to hooks everyone switches quickly, etc etc. For better or worse you can’t say the same about Java.
  - re-thc 4y ago
    > people do move from Promises to async quickly, when React switches to hooks everyone switches quickly, etc etc On Reddit or HN? Definitely in not the real world. Plenty of projects and even recently created 1s don't always use these new ways of working. Even on Reddit when I see a new project getting posted it doesn't have this trait you mention. And lots of companies are still on Node 14/16 or even older :( only forced to move by e.g. AWS lambda runtime requirements... And Node developers are still using ExpressJs and promote it all the time. Guess when Express 4 was released? 5 has been in beta forever with no updates. Yet, most promote it and ignore the other options. Lack of legacy? This thing is 10+ years old. It's barely maintained... what's the difference?

datadeft 4y ago

I am not sure there is fear against Java as much as there are better alternatives for many use cases.

kaba0 4y ago
I would argue the “many”, especially when we talk about regular old CRUD apps most startups are.

jve 4y ago

Can you compile so that JRE is bundled with the program? I'm a C# developer and I also have a kind of resistance of java - having to install JRE and now the minefield Oracle made with the JRE, I'm hoping not only that I don't have to code in it, but that I don't have to use ANY Java program just to avoid the runtime or have to choose between different versions of it. And then the .jar files and how you execute them in command line is different (java -jar), maybe it is simple, but it is different than a plain executable file.

kaba0 4y ago
Yes, there is in fact not even a JRE for quite some years now. Also, Oracle being a minefield is just bullshit - they are the ones that open-sourced the platform completely to the point that their paid version is only marginally different, but OpenJDK is the reference implemented. They are surprisingly good stewards of the language.
- jve 4y ago
  Our employer actively tracks runtime usage and makes sure we have no O in it. > The quantity of licenses is determined by the total number of employees, not the number of employees using the programs https://www.infoworld.com/article/3686611/oracle-per-employee-java-pricing-causes-concern.html https://www.infoworld.com/article/3686611/oracle-per-employe... > Employee for Java SE Universal Subscription: is defined as (i) all of Your full-time, part-time, temporary employees, and (ii) all of the full-time employees, part-time employees and temporary employees of Your agents, contractors, outsourcers, and consultants that support Your internal business operations. The quantity of the licenses required is determined by the number of Employees and not just the actual number of employees that use the Programs. https://www.oracle.com/us/corporate/pricing/price-lists/java-se-subscription-pricelist-5028356.pdf https://www.oracle.com/us/corporate/pricing/price-lists/java... Excuse me, but isn't that a minefield? Another point I don't want to use java: Now I have to understand what is Java SE and if the runtime falls under it or the development tools or how my users use the software, whether we now how to license every user that won't even use that program and even any people that interacts with our business. Pure maddness.

tehbeard 4y ago

Java has the lingering shadow of Oracle hanging over it. That legalistic hydra is enough to make you second guess using it.

jjav 4y ago
> Java has the lingering shadow of Oracle hanging over it. This myth needs to be dispelled. OpenJDK is Java, and is open source under GPL. https://en.wikipedia.org/wiki/OpenJDK https://en.wikipedia.org/wiki/OpenJDK https://github.com/openjdk/jdk/blob/master/LICENSE https://github.com/openjdk/jdk/blob/master/LICENSE
lenkite 4y ago
Would you ditch Linux, because Canonical has been making concerning decisions with Ubuntu ?
- tehbeard 4y ago
  False equivalence. Canonical doesn't own the Linux trademark, nor have the litigation history.

tecleandor 4y ago

Sysadmin here. It's true Java still smells like "corporate" and "slow". And when I say "slow", I don't mean the runtime speed, but the company speed ;) Until not a long time ago I've been maintaining a bunch of Sun|Oracle|J9 Java 6 + JBoss 4.2.3 + AIX|Linux + PPC|x86_64 ... That was not fun, and the task of moving it to more modern platforms was insurmountable to us. No wonder Azul has support for Java 6 until 2027. But it's true the platform has changed greatly in every way: The VM, the ecosystem... are so different now. And although as a language, it still feels strange to me (I just use Python), now that I manage a fleet of modern Java and Scala microservices, I don't get scared when I hear the name "Java" :)

jpgvm 4y ago
Yeah fair. Old JVM land and Modern JVM land really are worlds apart.

throwaway74567 4y ago

I see Java/Kotlin as a secret weapon for startups. Too often I read about startups that struggle with immature libraries, smaller eco systems and reinventing basic functionality. Problems that they would not have if they chose a mature technology. These blog posts mentions a company that has to write their own database library, auth services or other basic functionality. Sometimes they fix so many issues with the core language that they become close partners with the core developers of the programming language. I can't help wonder if the competition also reads the post and just smiles before they go back to actually solving a business problem. To me it's a symptom of choosing the wrong stack, even though working on non-business related problems may be more rewarding to the individual.

erik_seaberg 4y ago
I’m reminded of “Fire and Motion:” > Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET—All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features.

the_gipsy 4y ago

Irrational Fear is actually what is waged on the Java front. People doing mental gymnastics to avoid touching anything non-Java. Cargo-culting. I've witnessed Java devs proposing changing an existing Go project's build system to maven because "that's what they know well". Straight insanity. People that avoid Java don't do it because of some stigma, but because they have been burned before. Remember that a typical Java project is not the latest version and uses a mix of dependencies that make using newer features impossible. Then, there is no point in updating, you might as well rewrite it. That is the reality.

peterashford 4y ago
I work in a Go shop and we try to get rid of non-Go parts of our stack to make things simpler and more consistent.

black3r 4y ago

Startup stage companies work on smaller codebases and primarily need to go as fast as possible from nothing to a working prototype without the need to use many advanced features.... Java is a good language, but the community around it, whether it's experienced developers or libraries are built for enterprises, who work on huge codebases and their primary concerns are security, performance, scaling, testing, all of which are secondary in most startup environments and usually only start to matter years after the startup codebase is created...

jjav 4y ago
> security, performance, scaling, testing, all of which are secondary in most startup environments I've done quite a few startups by now and I can say that in all of them the initial quick-n-dirty MVP codebase lasted well into the era where things like "security, performance, scaling, testing" became a priority. Unless you are absolutely committed to throwing away the MVP (and I don't see how you could because as soon as sales team sees it they start selling it and you won't have time to throw it away), your best early move is to use technologies that will take you to the long haul because you will be stuck with that initial code for a very long time. (This doesn't mean architecting the whole system for scale you won't hit in years, mind you. Just to use technologies that will make the transition to a mature engineering team easier. Such as Java, given the topic of this conversation.)
jpgvm 4y ago
In my experience the zero to something stage lasts way longer than people think and the cost of using immature and badly suited stacks like Typescript/etc bites way sooner than people think. They just keep pushing through it and telling themselves this is faster and everyone else is doing it so it can't be wrong. Case and point I built a new service recently in Kotlin on JVM. It's a SQL translation gateway that maps an internal representation of simplified relational query model onto other databases so you can connect your own MySQL, PostgreSQL, Oracle, SQL Server, etc. Because Java has such a deep ecosystem in this area I was able to leverage JDBC and jOOQ to deliver support for all the require database types in only a few days of work with very clean code and full test coverage that tests compatibility with all the target databases. Imagine trying to do that in Typescript. You don't have a standardised interface to database drivers so you would need to first choose that abstraction and implement it yourself + adapters for each driver you need to support (i.e re-inventing JDBC). Then you need to handle the different SQL dialects as they all have different quoting rules, different LIMIT/OFFSET syntax, different supported LIKE/ILIKE/etc, there is no library for handling this in Typescript, especially not with support for commercial DBs like Oracle, SQL Server and -definitely- not for more esoteric stuff like HANA and Informix, etc. Just writing a dialect agnostic query builder abstraction is weeks of work, actually handling all the dialects and emulating anything that isn't native for your targets is much longer. So you might say, "but that is just libraries"... however that -is- the entire point. When you buy JVM you are buying the ecosystem of libraries primarily. The very nice runtime/GC/languages is really just icing. Same way that when you buy Python you are really buying numpy/pandas/PyTorch/etc, the language itself isn't the important part. Or you could say this is just a problem uniquely suited for JVM and you wouldn't be wrong but isn't that also the point? Use the right tool for the job. JVM is to business logic and solving business problems what Python is to data science and machine learning. The big epiphany I had recently was that when I build on JVM I don't write much code. I make a design, assemble some libraries in the correct way, iterate on it by refactoring until the abstraction is clean and then turning it on. There is very little mechanical coding involved because everything fits together very cleanly with only business logic being surfaced in actual "code". I feel more like an architect, less like a code monkey and I can ship results way faster because I don't have to work on code that doesn't directly solve the problem. i.e there are much less yaks to shave.

eptcyka 4y ago

Irrational fear of Oracle is actually a perfectly valid factor in my opinion.

jjav 4y ago
> Irrational fear of Oracle is actually a perfectly valid factor in my opinion. Fear of Oracle is rational though, unlike fear of Java.