Ask HN: Java or JVM based is the best choice for large projects. Prove me wrong
My experience (20+ yrs) at a variety of shops has led me to the belief that overall large corporate projects are best served by using Java (or JVM based language). Access to talent pool, IDE and tooling, type system, vendor support, vast opensource ecosystem are all factors. I don't think that Java is best for small/medium projects - I actually prefer Python for rapid development with small teams (1-5 people). But if 50 devs on a project then I am choosing Java. Willing to hear evidence otherwise. So prove me wrong :) [Genuinely interested - not looking for a flame war]
62 comments
My big problem with Java is the INSANELY bloated ecosystem where all actual business logic is hidden behind 17 different layers of abstraction. For example, if you want to see where a field of a given object originally gets its value, you may have to track that field back through 4 or five different files in order to find where the value originally came from. Its absolutely fucking maddening and makes the system as a while very difficult to reason about and makes bugs very obnoxious and time consuming (but not necessarily hard) to identify.
What's weird to me is that other languages have the exact same ability to suffer from this problem, but for whatever reason, they do not. Only Java seems to have this culture of circle jerking around patterns and idioms rhat solve problems you probably aren't or are never going to have.
What's weird to me is that other languages have the exact same ability to suffer from this problem, but for whatever reason, they do not. Only Java seems to have this culture of circle jerking around patterns and idioms rhat solve problems you probably aren't or are never going to have.
While it is definitely a thing in some legacy enterprise applications, there is plenty of applications not written in that style. Also, let’s add that the Java platform is unique in being written purely in Java almost entirely - so when you see a stacktrace (and I assume this “depth” feeling originates from those), you actually see everything that happens almost down to the CPU. While in many other programs’ case the platform looses track by passing the FFI boundary, so that libc/whatever part becomes invisible to you.
I don't like all the cursing/vulgarity but you are not wrong about the culture of Java encouraging some architect astronauts - however that's a problem that has been getting better (I blame EJBs for starting it)
Modern Java is much more terse and expressive.
> What's weird to me is that other languages have the exact same ability to suffer from this problem, but for whatever reason, they do not.
When you search long enough, you'll come across such programs. Even golang that's (falsely in my experience) claimed to be concise, I've come across monstrosities written in it. If you want an example in Python, look at gsutil's or gcloud storage's implementation and try to find how many levels deep you have to dig in to find out which gateway API call they make to do the actual transfers for commands like `cp`. The fact that Python has no types (yes type hints don't get you far) makes it a much more difficult task than if you're using a static language to navigate the code base.
> What's weird to me is that other languages have the exact same ability to suffer from this problem, but for whatever reason, they do not.
When you search long enough, you'll come across such programs. Even golang that's (falsely in my experience) claimed to be concise, I've come across monstrosities written in it. If you want an example in Python, look at gsutil's or gcloud storage's implementation and try to find how many levels deep you have to dig in to find out which gateway API call they make to do the actual transfers for commands like `cp`. The fact that Python has no types (yes type hints don't get you far) makes it a much more difficult task than if you're using a static language to navigate the code base.
I totally agree. In my experience Java just seems to have this problem more commonly.
And agreed on the Python thing. The lack of types can make debugging very painful. Also the overuse of Dict/arrays with no clear indications of the shape or keys can be brutal
And agreed on the Python thing. The lack of types can make debugging very painful. Also the overuse of Dict/arrays with no clear indications of the shape or keys can be brutal
Agreed. Look how Java enables collaboration on large projects like FizzBuzz: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Arguments against:
1. Google prefer Kotlin over Java for Android.
1. You're old so your opinion counts for less.
6. On the stackoverflow survey Java is less wanted than APL, bash and CSS.
2. Go has a cuter mascot.
3. Java just copied from Javascript's name as an easy way to gain popularity.
5. OOP hasn't been cool since the 90s.
(Some of these things might not be true but if you're just looking to argue pointlessly, I think they'll do)
1. Google prefer Kotlin over Java for Android.
1. You're old so your opinion counts for less.
6. On the stackoverflow survey Java is less wanted than APL, bash and CSS.
2. Go has a cuter mascot.
3. Java just copied from Javascript's name as an easy way to gain popularity.
5. OOP hasn't been cool since the 90s.
(Some of these things might not be true but if you're just looking to argue pointlessly, I think they'll do)
Just to avoid confusing other users: Javascript was the one copying from Java name to gain popularity, not the other way: https://m.youtube.com/watch?v=XOmhtfTrRxc&t=2m5s (link from Wikipedia)
1. is mostly for android, which is while easily larger than some whole other language niche, it is still just a smallish part of all the Java applications. Google itself likely has order of magnitude more Java server-side code than Kotlin’s presence in android.
2. I’m young, and I also think Java is a great blue-collar language for long running projects
6. Stackoverflow is biased, some languages have great presence there, others prefer different platforms. Also, many of the “low hanging fruit questions” for java has been answered and are replicated all over the internet, so there is not much need for beginners to post Java questions anymore.
2. I’m young, and I also think Java is a great blue-collar language for long running projects
6. Stackoverflow is biased, some languages have great presence there, others prefer different platforms. Also, many of the “low hanging fruit questions” for java has been answered and are replicated all over the internet, so there is not much need for beginners to post Java questions anymore.
It's mean to call someone old. Now where are my glasses.
Go _does_ have a cuter mascot! But Java's logo was in Wreck-It-Ralph Breaks The Internet, so Java's logo wins by default.
> 6. On the stackoverflow survey Java is less wanted than APL
Because some of us actually enjoy coding in APL, you know.
Because some of us actually enjoy coding in APL, you know.
If you've been using Java for 20+ years, you maybe have a slight bias towards Java over everything else.
And that's fine, fight for Java in your life because that's your mastered ecosystem.
Trying to argue which tech stack is best is a pretty annoyingly dead and unanswerable question. There are a few quantifiable-ish things like you mentioned (hiring pool, tooling maturity, etc) but everything else gets subjective and meaningless pretty quick IMO.
And that's fine, fight for Java in your life because that's your mastered ecosystem.
Trying to argue which tech stack is best is a pretty annoyingly dead and unanswerable question. There are a few quantifiable-ish things like you mentioned (hiring pool, tooling maturity, etc) but everything else gets subjective and meaningless pretty quick IMO.
Yes, I am biased but that's why I asked this question - really interested in learning what has worked for other people on large projects.
Maybe the bias is like religious schooling. Some people are believers because they went to a religious school, and other people are atheists because they went to a religious school.
Let me create some counter arguments with a InjectableCounterArgumentDecoratorFactoryImpl class
I can only agree. Have seen many systems and various tech being used and Java would be my choice for a large project as well.
I won't get into flamewar over Java vs others, but there are some ecosystems that are definitely better suited for large scale development.
The biggest concern for me and my shop is stability over time. We pick tools and vendors that can comfortably support B2B software contracts that are 5+ years long.
The biggest concern for me and my shop is stability over time. We pick tools and vendors that can comfortably support B2B software contracts that are 5+ years long.
JDK 8 came out in 2014 and has support from Oracle (and plenty other vendors as well) till 2030, the least. That, plus Java is highly backwards compatible. Which platform can even come remotely close to its stability? Remember, it runs on an abstract instruction set, so there is no hardware-lock in (which happened with those fortran behemoths from the previous century - some of which actually chug along in VMs nowadays) effectively allowing code written for the platform to always be runnable.
Genuinely interested in your thoughts, please expand. For instance, I hear lots of great stuff about .net core but I don't see as large of an opensource ecosystem to support it - but maybe I am missing something.
.NET ecosystem is very healthy. There is as always occasionally some drama (Identity Server, ImageSharp etc). In general for most of tasks there is almost always good library.
I see much more abandonware for Python and Java.
I see much more abandonware for Python and Java.
Would you mind sharing what ecosystems?
Probably .NET and he is not wrong. ;)
I have been working on 2 mil. LOC C# written by more than 100 developers over 15 years and it is really good experience.
I have been working on 2 mil. LOC C# written by more than 100 developers over 15 years and it is really good experience.
Isn’t microsoft pretty bad at committing to.. anything? Sure, they do make windows xp executables run even today, but they have revamped C# libs/platform so many times I have lost count.
Sure. Backwards compatibility on Windows is unmatched on other platforms.
>but they have revamped C# libs/platform so many times I have lost count.
What exactly do you mean? There was big migration towards .NET Core but full .NET will be supported forever. They even listened customers regarding WCF and helped a lot with CoreWCF.
>but they have revamped C# libs/platform so many times I have lost count.
What exactly do you mean? There was big migration towards .NET Core but full .NET will be supported forever. They even listened customers regarding WCF and helped a lot with CoreWCF.
Maybe it’s just in name, but .NET core to .NET, but if I’m not mistaken asp.net was pretty much rewritten from scratch? Then there is the gui churn where we get at least one new gui framework for every windows version (and if you are good enough you can open all kinds of them under the same system!). I mean things like that.
Oh and on top every major dependency being a copy of the java’s version, and only the microsoft version will be remotely maintained. But please do correct me if my flamewary knowledge on the topic is not accurate.
Oh and on top every major dependency being a copy of the java’s version, and only the microsoft version will be remotely maintained. But please do correct me if my flamewary knowledge on the topic is not accurate.
All your advantages of Java also apply to Python. Why would Java be the better choice compared to Python? Or to rephrase this question, why do you think that Python is only good for small teams (with an eye on all these massive billion dollar projects like Instagram which were built in python)?
Python is a pretty terrible language for large scale development.
The main reason is that it's effectively impossible to isolate code without physical separation. The upshot is that you end up heavily reliant on testing and byzantine development processes to keep your head above the water.
That's partly the reason why ideas like micro services have caught on. They offer the physical separation and they can have advantages that aren't easy to get elsewhere e.g. redundancy. But they also add a lot of overhead and complexity, which is fine if you're using them for their advantages, less so if you're using them for deficiencies in your language.
So, I too would argue that Java is a better language than Python for large scale system development. I wouldn't necessarily say it's the best, as other languages are often better in specific circumstances, but Python is pretty poor for big software.
Source: a lifetime designing, building and maintaining large and very large systems in Java, Python, C++, C#, Smalltalk, APL, and various niche languages that have disappeared into obscurity.
The main reason is that it's effectively impossible to isolate code without physical separation. The upshot is that you end up heavily reliant on testing and byzantine development processes to keep your head above the water.
That's partly the reason why ideas like micro services have caught on. They offer the physical separation and they can have advantages that aren't easy to get elsewhere e.g. redundancy. But they also add a lot of overhead and complexity, which is fine if you're using them for their advantages, less so if you're using them for deficiencies in your language.
So, I too would argue that Java is a better language than Python for large scale system development. I wouldn't necessarily say it's the best, as other languages are often better in specific circumstances, but Python is pretty poor for big software.
Source: a lifetime designing, building and maintaining large and very large systems in Java, Python, C++, C#, Smalltalk, APL, and various niche languages that have disappeared into obscurity.
I love Python and have been using it for 20+ yrs as well. I have seen a lot of pain on older Python projects (pre type hints). I think you need more discipline and tests and docs to keep a large Python project on track. Not saying you can't do it, it just takes more work than with a statically compiled lang. However as I said - type hints have (imho) a huge improvement for large scale Python projects.
as great as hints are they still don’t provide any compile time type checking nor even enforce the types. so they are exactly just hints. a statically typed python might be interesting
that's a good point but you do get warnings about issues (that you can block CI build on) and also much better IDE support
There were many MVPs built on Python that later gained popularity - but many of these (but not all!) have been rewritten in other languages at some point.
If I'd have to chose two reasons to answer your question, I'd pick up lack of static typing and relatively slow performance. Both can be alleviated (by things like MyPy, PyPy etc.) but it's not built in. You can build larger projects in Python, you just need more discipline and be realistic about potential bottlenecks.
If I'd have to chose two reasons to answer your question, I'd pick up lack of static typing and relatively slow performance. Both can be alleviated (by things like MyPy, PyPy etc.) but it's not built in. You can build larger projects in Python, you just need more discipline and be realistic about potential bottlenecks.
can't beat the JVM, python is great for many reasons and situations though
That would depend a lot on what kind of large project you are building. As an example, Java is unusable for any project that requires high speed processing or highly accurate timing.
Also, there's a HUGE overhead that comes from wiring together and maintaining the runtime environment. The extra hours that you need to spend to find the exact combination of frameworks, servers, JDK version, etc to just get the project to run is something quite unique to Java. And then you need to keep it all up to date and secure. Sometimes those hours are justified, but they can definitely be a factor when you are determining the best language for some particular project.
Also, there's a HUGE overhead that comes from wiring together and maintaining the runtime environment. The extra hours that you need to spend to find the exact combination of frameworks, servers, JDK version, etc to just get the project to run is something quite unique to Java. And then you need to keep it all up to date and secure. Sometimes those hours are justified, but they can definitely be a factor when you are determining the best language for some particular project.
> As an example, Java is unusable for any project that requires high speed processing or highly accurate timing.
That is absolutely false. There is a huge list of already existing high-performance projects written in Java, used from HFT to distributed computations. Code using primitives (and thus actually comparing apples to apples) JIT compile down to just as efficient and performant code as what you would get with C. Applications reliant on dynamic allocations may very well come out ahead low-level languages due to its killer GCs vs mallocing left and right. (And no, not everything is replaceable with strict nested lifetimes a la Rust, and (atomic) reference counting is slow as hell. Nor is everything replaceable with arenas).
> Also, there's a HUGE overhead that comes from wiring together and maintaining the runtime environment
Do you even talk about Java? You literally just download a jdk and run the program. That works for 90% of the time (you can literally download 20 years old jars from some long-dead university professor’s website and it will just work). There are minor nits, but if you use the same jdk version it was meant to be used with it is literally dirt-easy. I don’t see how dynamic libs dependency hell is any easier to manage.
That is absolutely false. There is a huge list of already existing high-performance projects written in Java, used from HFT to distributed computations. Code using primitives (and thus actually comparing apples to apples) JIT compile down to just as efficient and performant code as what you would get with C. Applications reliant on dynamic allocations may very well come out ahead low-level languages due to its killer GCs vs mallocing left and right. (And no, not everything is replaceable with strict nested lifetimes a la Rust, and (atomic) reference counting is slow as hell. Nor is everything replaceable with arenas).
> Also, there's a HUGE overhead that comes from wiring together and maintaining the runtime environment
Do you even talk about Java? You literally just download a jdk and run the program. That works for 90% of the time (you can literally download 20 years old jars from some long-dead university professor’s website and it will just work). There are minor nits, but if you use the same jdk version it was meant to be used with it is literally dirt-easy. I don’t see how dynamic libs dependency hell is any easier to manage.
Nice condesending tone you have there.
Where Java will never be seen: - equipment in hospital operating rooms - aircraft flight control systems - anywhere where you need clock cycle level precision (e.g. scientific measurement) - any system where there can be inopportune moments when garbage collection absolutely can't start
You mentioned speed of dynamic allocation. First of all, there are standards which prohibit any kind of dynamic memory allocation. Car computers are a popular example. Second of all, what do you think JVM uses under the hood? Magic?
That last paragraph kind of suggests to me that you have never needed to develop any kind of large Java EE project. For any team that I've worked with, it has usually taken from weeks to months to first research and then configure an acceptable stack that actually plays well together. Think Apache Web Server, JBoss (that shipped with some version of Hibernate), DB connection pooling, all kind of caching, dependency injection, interfacing with the outside world, web frontend tech, socket connections; and whatever build tools happened to be in fashion at that time (mvn, gradle and there plugin ecosystems). And then the truckload of XML that goes with getting it all to work together.
And then you have to sort out all the "The server JVM has run out of PermGen space", and "totally getting crushed under CPU load when the garbage collector decided to fire away at the worst possible instant", and the "weird exceptions under the hood that give you absolutely no clue why they are happening", and the "JNDI DB pool isn't releasing connections", and the "requests aren't getting distributed to workers correctly" and all the other fun stuff to work out. Usually when there are 10000 users hitting your service all at once, and after 3 hours of googling you find out that you needed to put ncvd:if="cfrog" instead of ncvd:fi="frogc" in mfnbooblah.xml, which by the way since version 47 or gobbldygook needs to be put in the app folder instead of the resources folder. Because that's obviously more betterer and enterprisier.
Do you even talk about Java?
Where Java will never be seen: - equipment in hospital operating rooms - aircraft flight control systems - anywhere where you need clock cycle level precision (e.g. scientific measurement) - any system where there can be inopportune moments when garbage collection absolutely can't start
You mentioned speed of dynamic allocation. First of all, there are standards which prohibit any kind of dynamic memory allocation. Car computers are a popular example. Second of all, what do you think JVM uses under the hood? Magic?
That last paragraph kind of suggests to me that you have never needed to develop any kind of large Java EE project. For any team that I've worked with, it has usually taken from weeks to months to first research and then configure an acceptable stack that actually plays well together. Think Apache Web Server, JBoss (that shipped with some version of Hibernate), DB connection pooling, all kind of caching, dependency injection, interfacing with the outside world, web frontend tech, socket connections; and whatever build tools happened to be in fashion at that time (mvn, gradle and there plugin ecosystems). And then the truckload of XML that goes with getting it all to work together.
And then you have to sort out all the "The server JVM has run out of PermGen space", and "totally getting crushed under CPU load when the garbage collector decided to fire away at the worst possible instant", and the "weird exceptions under the hood that give you absolutely no clue why they are happening", and the "JNDI DB pool isn't releasing connections", and the "requests aren't getting distributed to workers correctly" and all the other fun stuff to work out. Usually when there are 10000 users hitting your service all at once, and after 3 hours of googling you find out that you needed to put ncvd:if="cfrog" instead of ncvd:fi="frogc" in mfnbooblah.xml, which by the way since version 47 or gobbldygook needs to be put in the app folder instead of the resources folder. Because that's obviously more betterer and enterprisier.
Do you even talk about Java?
> Also, there's a HUGE overhead that comes from wiring together and maintaining the runtime environment.
Yes the runtime bugs me too, but I think your complaints are about dependencies in general, not just Java dependencies.
Yes the runtime bugs me too, but I think your complaints are about dependencies in general, not just Java dependencies.
In theory, yes, but in practice Java EE is more complex than anything else by orders of magnitude. (We were talking about large projects, I believe.)
I think you've proven the opposite in your post. You probably shouldn't have 50 devs working on a project. Better to split it up into 3-4 small/medium projects of 13-18 devs.
I agree for the simple reason that the JVM community pays a lot of attention to backwards compatibility. This alone means if you're working on an investment thats going to be around for more than 2-3 years, it's a solid choice. Contrast that with the NPM/Node community, where they regularly break backwards compatibility every couple of months because it needed to be redesigned.
Yes, but:
C# is just as good as Java on all accounts.
Rust is just as good as Java except the talent pool is yet growing.
C++ is just as good as Java except the language has no ceiling and the talent pool is shrinking.
C# is just as good as Java on all accounts.
Rust is just as good as Java except the talent pool is yet growing.
C++ is just as good as Java except the language has no ceiling and the talent pool is shrinking.
Rust and C++ are low level languages, making low level detail leak into its module contracts. This will make refactors/faster code changes slower. Depending on the application niche, this tradeoff is not worth it, e.g. I wouldn’t write a CRUD app in Rust/C++ —- Java (and C#, and the litany of other managed languages) implementations will be much more maintainable and fast to create.
This is automatic memory management’s greatest “gift”.
This is automatic memory management’s greatest “gift”.
Have you tried Rust?
Garbage collection is over-valued.
CRUD in Rust is not as low-level as in C.
> making low level detail leak into its module contracts
There is the risk, yes. Design a good API, and it won't happen. Onboard 50 people who don't care, and you'll have all sorts of low-level thinking when it isn't appropriate. This is the risk of a language having no ceiling: Suddenly someone is spending the "novelty budget" without asking.
Garbage collection is over-valued.
CRUD in Rust is not as low-level as in C.
> making low level detail leak into its module contracts
There is the risk, yes. Design a good API, and it won't happen. Onboard 50 people who don't care, and you'll have all sorts of low-level thinking when it isn't appropriate. This is the risk of a language having no ceiling: Suddenly someone is spending the "novelty budget" without asking.
It’s not a risk, it is always there. Rust just cleverly hides it behind syntactic sugar, but in reality every single API mandates the what lifetime each parameter should have (they are just generic to lifetimes, and it can be inferred more often than not). This is in stark contrast to any managed languages’ function signatures, and one will have to change to accommodate bigger changes and the other doesn’t.
And I’m talking strictly about memory management here, sure Rust is a very cool language (it is my go to choice for low-level programming) and has a strong enough type system to actually make these refactors safe, but it doesn’t change the fact that this is simply of no concern with automatic memory management.
And I’m talking strictly about memory management here, sure Rust is a very cool language (it is my go to choice for low-level programming) and has a strong enough type system to actually make these refactors safe, but it doesn’t change the fact that this is simply of no concern with automatic memory management.
None of the languages/ecosystems you mentioned have anything resembling the JVM's JFR for continuous profiling. I've seen some commercial offerings, but then (1) they're not free, and (2) you're bound to the provider.
Java's GCs are superior to what C# offers by the way (and I like both languages).
Java's GCs are superior to what C# offers by the way (and I like both languages).
> None [...] have anything resembling JVM's JFR for continuous profiling
You could say a similar thing for Erlang and its Dialyzer.
Yet other ecosystems manage.
The point I want to make is:
While that's an argument in favor of Java, it's not an argument against everything but Java.
You could say a similar thing for Erlang and its Dialyzer.
Yet other ecosystems manage.
The point I want to make is:
While that's an argument in favor of Java, it's not an argument against everything but Java.
C# is just as good from a technical stand point I think, but there is a significant financial cost attached from the licenses. Large server installations with dev, stage, prod & load test envs tend to get expensive with .net.
Small nitpick about C++ — tooling there is atrocious. Despite heroic efforts the language itself is a boss monster that evolves new moves every few years. Standard committee lives in a parallel universe, where writing compilers and editors is not a valid concern, yet pretending to support C source and single-pass parsing somehow is.
C++ should be something of a last resort, especially when you are given a choice.
C++ should be something of a last resort, especially when you are given a choice.
I agree that Java has the best ecosystem for large systems. But, as others pointed out, in 2022 it is impossible to get in. I was lucky to have been one of the earliest adopters, back then when Java was only for applets and have followed its evolution up to Java 8. If I were a developer who tries now to start with Java, I'd probably despair.
Having done both Java and .NET Projects I’d personally pick .NET over Java every day of the week.
I’m not sure what the talent pool is like for them but that might also be regional. But that comparison is only made because they are very similar platforms. For a lot of protect types I might pick Rust these days too.
Java Dev here.
I dislike its type system.
I don't know what all its wonderful tooling is.
Vendor support? The vendor (Oracle) will sue you.
JIT compilation produces fast code, so fast in fact, that it's only beaten by its one alternative - AOT compilation.
The JVM and its libraries are great, but I prefer the M.
Talent pool? People who are locked into it, like me.
I dislike its type system.
I don't know what all its wonderful tooling is.
Vendor support? The vendor (Oracle) will sue you.
JIT compilation produces fast code, so fast in fact, that it's only beaten by its one alternative - AOT compilation.
The JVM and its libraries are great, but I prefer the M.
Talent pool? People who are locked into it, like me.
> I dislike its type system
Fair, it is not the best thing under the Sun (pun intended), but it is pragmatic and sufficiently strong (actually, with generics it is quite expressive, you can do almost everything besides actual Monads in it)
Come on, it has very good debuggers, you can get very detailed runtime data with basically zero overhead even in production, you can display the number of instances of all the objects and where were they created, and due to the language being uniquely big in both academia and industry it has so many niche tools that you can probably find everything for it. (You can literally statically prove a sort function with JML for example).
That Oracle part is just bullshit — oracle open-sourced the whole platform, made OpenJDK the reference implementation and there are more vendors available for that to choose from than I care to list. What other language can just go on as is if the main corporation behind it would disappear tomorrow?
Your sarcasm is not warranted regarding JIT compilation, for code that does the same thing it will be competitive with AOT compiled code.
And regarding talent pool, there are more java devs than people living in my country. I’m sure for every “locked in” one there is someone on the other end of the Gauss distribution.
Fair, it is not the best thing under the Sun (pun intended), but it is pragmatic and sufficiently strong (actually, with generics it is quite expressive, you can do almost everything besides actual Monads in it)
Come on, it has very good debuggers, you can get very detailed runtime data with basically zero overhead even in production, you can display the number of instances of all the objects and where were they created, and due to the language being uniquely big in both academia and industry it has so many niche tools that you can probably find everything for it. (You can literally statically prove a sort function with JML for example).
That Oracle part is just bullshit — oracle open-sourced the whole platform, made OpenJDK the reference implementation and there are more vendors available for that to choose from than I care to list. What other language can just go on as is if the main corporation behind it would disappear tomorrow?
Your sarcasm is not warranted regarding JIT compilation, for code that does the same thing it will be competitive with AOT compiled code.
And regarding talent pool, there are more java devs than people living in my country. I’m sure for every “locked in” one there is someone on the other end of the Gauss distribution.
Java has relatively recently gotten algebraic types with pattern matching + records. I find myself missing this feature anytime I use a language that doesn't support it.
> I don't know what all its wonderful tooling is.
Excellent refactoring tools by IDEs. Second to none profiling and monitoring (JFR, etc). Excellent debugging tools, profilers, etc.
Nothing else comes close frankly. C# it a not so close second.
OpenJDK is free. Oracle will not sue you.
> I don't know what all its wonderful tooling is.
Excellent refactoring tools by IDEs. Second to none profiling and monitoring (JFR, etc). Excellent debugging tools, profilers, etc.
Nothing else comes close frankly. C# it a not so close second.
OpenJDK is free. Oracle will not sue you.
[deleted]
Unit testing sets off the footguns earlier than later. Any language that makes unit testing harder than easier is bound to have problems.
This is true with Python/Java/Go etc.
Anyone who says "If it compiles, it just usually works..." is bound for trouble, particularly on large scale projects -- golang being the obvious example of this.
This is true with Python/Java/Go etc.
Anyone who says "If it compiles, it just usually works..." is bound for trouble, particularly on large scale projects -- golang being the obvious example of this.
I don't get why you're singling out Go - you can certainly test your Go code just like in any other language (and Go's tools for it are probably better anyway).
> and Go's tools for it are probably better anyway
Trying to detect nil pointer panics in go is a fucking nightmare. The compiler doesn't warn about it, and just lets it fly.
Trying to detect nil pointer panics in go is a fucking nightmare. The compiler doesn't warn about it, and just lets it fly.
OSes.
Browsers.
Games.
Browsers.
Games.
yes