20 ms·

So with this, the last thing Go had going for it over Java is gone, right? Java has an obviously better type system, while Java originated the billion dollar m

So with this, the last thing Go had going for it over Java is gone, right? Java has an obviously better type system, while Java originated the billion dollar mistake, Java also at this point has much better practices around handling nulls than Go, Java's jars are more portable than go's binaries, Java's GC performs better, Java has a more mature ecosystem and more libraries... Java has better IDE support and comparable compile times. I guess at this point the only major difference is that you can teach a 3 year old to write Go more easily, so ChatGPT produces correct Go more easily than Java, and the dependency management story differs a little (though I don't think you can really call a winner or loser on that one, it's just different)

the-alchemist 4y ago
The "original billion dollar mistake" is lack of runtime bounds checking (in the creator's words), not the idea of a null/nil/undefined generally.
lightbendover 4y ago
> the billion dollar mistake Eh, a billion dollars isn't too bad.
Mawr 4y ago
This is missing the forest for the trees. Languages are very complex, you will not get a good picture of their overall strengths and weaknesses if you limit yourself to a very zoomed-in view, like comparing a few features of the languages themselves. As an example, consider the digital camera market vs the cameras in smartphones. The digital camera is a clear winner! So many features. The quality of photos taken is objectively better in every metric too. And yet the digital camera market is dying, completely killed by smartphones. But why, the features are cleary better right?! Because we're looking at it wrong, we're tunnel-visioned on the "camera" part. We need to look at what actually matters. Thankfully, that's simple to answer and is the same for every product in existence. All that matters is the user experience. Nobody wants extra features on their camera, nobody wants a camera in the first place, nobody wants to take photos either. What people actually want is to preserve the moment of their first born child taking their first steps. The technology is irrelevant as long as it lets the user do what they really want. Why would I want a digital camera when my smartphone has a decent enough one that is effectively free and always available? A low quality camera on you is infinitely more valuable than the professional camera at home. Programming languages are no different, just that "users" in this case are programmers, which seems to be confusing to some. What is the developer experience of using Java vs Go? - that's the real question you need to answer to get to the bottom of this. Start a new project and write some code in both languages, compare the experiences. Be wary of biases, if you have pre-existing experience in one of the languages it's going to shadow your judgement (the curse of knowledge). Pay attention to aspects of good design - how many pointless decisions do you have to get through before actually shipping code? Go eliminates whole areas of pain points: - Dependency management? Go modules. - Tests? Built-in. - Code formatting? Built-in autoformatter. - Compilation time? As fast as it gets. - Distribution? Single binary. - Writing code? Minimal ceremony, just make a function. - Performance? The idiomatic code you write will naturally perform well due to value types, explicit pointers, a culture of straightforward code with no needless indirection. If you need to optimize, the profiling tooling is great and the optimizations themselves straightforward due to intuitive language and GC semantics - just reduce allocations. - GC? A single implementation, good enough for 99% of cases. Two whole knobs available if you really need to tune it. Performs well due to the language not getting in its way. - Standard library? Excellent, good balance between batteries-included and bloat. The built-in HTTP server is suitable for 80%+ of workloads. - Concurrency? Core to the language - syntactically supported green threads. The entire language and its ecosystem are built with it in mind. - Linting? Community-made linter runner with a curated list of good linters. - Found a bug in a library? No problem, the library is written in straightforward Go, the same flavor of Go you've been writing. It's of course autoformatted as well. There you go, a single go-to solution to each problem. The language's designers have gotten all the pointless details out of the way for you. You get to focus on writing code. Now compare the above points with Java. Go was designed for developers, with the same philosophy Steve Jobs designed Apple products for users. Java wasn't. Simple as.
ape4 4y ago
ALGOL originated null
- TheDong 4y ago
  In ALGOL it was more like a thousand dollar mistake. It didn't become a billion dollars until Java caused NPEs on 3 billion devices
  - marginalia_nu 4y ago
    Java's got like the safest most soft-punching NPEs in any language that's got them though. They're so safe you can use them as flow control devices.
    - another2another 4y ago
      yes, but please don't - there's a good dear.
      - marginalia_nu 4y ago
        try { return true; } finally { return false; }
  - ajuc 4y ago
    I'm pretty sure nulls in C and C++ caused more problems than in Java :)
hintymad 4y ago
My experience in small companies told me that younger generation didn’t choose Go because Go is objectively better than Java, but because they actively hate Java for it being out of fashion.
- jpgvm 4y ago
  Irrational Fear of Java is one of the most confusing things among startup stage companies.
  - 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
marginalia_nu 4y ago
I think there are still a few changes in the pipe before Java is quite what it could be in terms of performance. Project Valhalla, and the foreign function and memory APIs in particular.
- MrBuddyCasino 4y ago
  I'm not sure Project Panama will have a large performance influence on most Java deployments. Native interop is rare.
  - marginalia_nu 4y ago
    Big part of why native interop is rare because it's slow and awful and generally not worth it. I don't expect a lot of code to actually use these features, but the code that does will be the low level stuff that lets the higher level stuff really perform.
    - kaba0 4y ago
      FFI makes cross-platform usage more questionable (have a look at python or node breaking a build on windows vs linux, this is very very rare in case of Java builds), and Java is more than fast enough for most use cases that it simply doesn’t need FFI for speed (like Python for example). Also, this is a huge advantage of the system, you don’t shallowly depend on a ton of C libraries, you can be confident that your whole application to the last bit is properly abstracted (plus can be debugged and observed with the same great tooling).
      - marginalia_nu 4y ago
        Eh, Java leaves quite a lot of performance on the table compared to C or Fortran. It's not as bad as Python, but if you really want to go fast, it's not quite able to compete with fine tuned native code. The Vector API might help a bit, but I don't think it will go all the way.
        4y ago
quanticle 4y ago
while Java originated the billion dollar mistake By the "billion dollar mistake", are you referring to null references [1]? But null references were introduced in 1965 in Algol, by Tony Hoare. They long predate Java. [1]: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/ https://www.infoq.com/presentations/Null-References-The-Bill...
- self_awareness 4y ago
  I don't think it's about the existence of null references, but how Java is using them. Null references can be a useful, e.g. Kotlin has converted them to be useful (with nullable types).
  - Cthulhu_ 4y ago
    Using nulls in Java is mostly a choice on the part of developers; even if you can't migrate to a JVM-targeted language like Scala, you can still adopt practices like null objects [0]. [0] https://en.wikipedia.org/wiki/Null_object_pattern https://en.wikipedia.org/wiki/Null_object_pattern
- saurik 4y ago
  Speaking of Go and Algol... http://cowlark.com/2009-11-15-go/ http://cowlark.com/2009-11-15-go/
the-smug-one 4y ago
> So with this, the last thing Go had going for it over Java is gone, right? No. Go does containerized microservices better because of its lower memory footprint. If you can use GraalVM then that might not matter.
- threeseed 4y ago
  This is based on outdated advice. Java stacks like Quarkus [1] have memory as low as 12MB and JVMs like OpenJ9 natively support CRIU for instant startup. [1] https://quarkus.io https://quarkus.io [2] https://blog.openj9.org/2022/10/14/openj9-criu-support-a-look-under-the-hood/ https://blog.openj9.org/2022/10/14/openj9-criu-support-a-loo...
  - PlutoIsAPlanet 4y ago
    Yet with Go you don't need to worry about comparing Java Stacks, changing your tooling, testing them etc, the binaries "just work" out the box in a near perfect condition.
    - junon 4y ago
      Not really. We saw overall performance speed up when we limited the number of system threads for goroutines to 1. This was with Docker and Kubernetes (albeit several years ago). This was configured, if memory serves, by an environment variable. So no, it's not as simple and perfect in my opinion.
      - aktau 4y ago
        Performance increasing when setting `GOMAXPROCS=1` sounds like an (interesting) edge case for the scheduler. If you ever encounter this again, it would be great to file an upstream issue about this. Go has plenty of built in observability tools (I imagine runtime/trace would be good here) so it'd be easy to get the developers the data they'd need.
        4y ago
vardump 4y ago
"So with this, the last thing Go had going for it over Java is gone, right?" You can deploy Go app with a single binary, no runtime required. No runtime configuration.
- foepys 4y ago
  Nowadays you don't deploy a global JRE on machines anymore. Each application has its own JRE bundled.
darthrupert 4y ago
Java will always have Java syntax, though. And its runtime will remain rather heavy compared to language implementations that compile down to machine code. Go's benefit's will probably always be there. Java can be taught to 2-year olds so Go seems to have a slight disadvantage there. ;)
- jbverschoor 4y ago
  Java Card on smart cards?
- kaba0 4y ago
  Very subjective, but having Java syntax is an advantage compared to goddamn Go — like I have seen my fair share of languages and can generally “read” a new language’s code sample just fine, but go was honestly quite hard the first time with their stupid type, “receiver” etc notation. And I have honestly no problem with Haskell/Lisp/C/etc notation at allz
FooBarWidget 4y ago
As someone who recently developed in Java (for developing a Jenkins plugin) after not having done so for a long time (~15 years), I feel that Java nowadays is technologically quite interesting with many interesting libraries and tooling. IDE code navigation and debugging support is excellent. At the same time, the ecosystem can feel messy and overwhelming. There are multiple @Nonnull annotation libraries and it's not clear what the difference is. There are many different testing libraries (some TDD, some BDD) but it seems everybody picks a different one. There are multiple advanced concurrency libraries and concepts, but again not much consensus and everybody uses a different one. Lots of deprecations all over the place. It's even worse in the Jenkins-specific ecosystem where nearly every plugin uses some deprecated aspect of either Java or Jenkins, and hunting for what the "right" way is supposed to be is a bit of a daunting task. There are like 20 different JDKs, not sure why. On the other hand, startup time and memory usage still seems to be a big issue. Starting Jenkins takes forever even with JVM in client mode and with bytecode verification disabled. And when started it uses a huge amount of memory. To date I've never seen one non-hello-world Java app that isn't like that.
- mike_hearn 4y ago
  Hi there ;) Knowing you, I'm sure you've got it all figured out by now but for any others who are reading: - Nonnull annotations: you can pick any. Tooling doesn't care and tends to just accept any annotation with a name like @Nullable or @Nonnull regardless of namespace. There was an attempt to standardize this years ago which failed for reasons that are hard to understand from the outside, something to do with lack of agreement on the exact semantics and use cases. No, me neither. Or just write in Kotlin where it's all integrated with the type system and the compiler understands / hides from you the Java annotation mess. - Testing libraries: it's been quite a long time since I encountered anything except JUnit 4 or 5, but they interoperate so that's no big deal. JUnit 5 is great and very standard so you can't go wrong by picking it. - Concurrency libraries/concepts: yes this is a problem but it's one found in other ecosystems, and it's one the new virtual threads are designed to solve. The hope is (and I guess we'll see) that everyone can forget about coroutines and reactive programming now, at least where performance matters, and go back to writing old fashioned ordinary threaded code. I guess they'll stick around in Jetpack Compose GUI programming. - Lots of different JDKs. That is indeed new and unfortunate. They don't actually vary much, mostly in how long major versions remain supported. Amazon is a sort of default choice unless you're doing GUI work, in which case JetBrains Runtime has lots of desktop specific patches. - Startup time/memory usage. There are simple things that can be done to improve this (see AppCDS). Some of it is cultural however, the people who write CI servers probably don't care about startup time. IntelliJ for example starts pretty fast in the latest versions, because they care to optimize it. For memory usage, be aware that the JVM will default to using most of your free system RAM even if it doesn't need to. It figures hey, the RAM is free, so why waste CPU time and energy on garbage collecting if I don't have to. If you planned to use the RAM for something else, or conclude that this is the "natural" level of RAM usage, it can be annoying however. You can give it a limit or in recent versions set a flag that'll cause it to regularly run GC when the app is idle, to give back memory to the OS.
pizza234 4y ago
What's the modern startup time of JARs? I haven't used Java in a long time, but long ago, the relatively slow startup time was a dealbraker for using java to write small tools.
- mike_hearn 4y ago
  Depends what the JARs do of course. Some desirable libraries are unfortunately slow. PicoCLI for argument parsing is one. It's got every feature you might ever want, but, it adds a couple hundred msec to startup. There is a HotSpot feature called AppCDS. It improves startup time by about 30% in my experiments. However you have to turn it on. Just running `java -jar` won't do it. Then there is GraalVM Native Image. It can compile JARs to native code ahead of time. They start as fast or faster than the equivalent C program, so it's the big hammer for CLI tools. However, it can't cross compile so you have to compile for the target system on the target system. There can also be compatibility issues with some libraries, though that's getting better rapidly. So those are the options. Still, even without those extra features, startup time is usually good enough.
  - kaba0 4y ago
    > PicoCLI for argument parsing is one Doesn’t it generate every additional code at compile time? I didn’t notice it slowing down my startup times, it’s mostly every other lib (which you usually have, as what’s the point of a hello world cli app)
    - mike_hearn 4y ago
      I've timed it, it's very slow because it uses reflection to generate the model. The annotation processor doesn't let you avoid this step unfortunately. Native images do.
      - kaba0 4y ago
        But that step only has to run as part of building it. It doesn’t have to run at every invocation. How did you try to run it? From the documentation: > The picocli-codegen module includes an annotation processor that can build a model from the picocli annotations at compile time rather than at runtime. > Enabling this annotation processor in your project is optional, but strongly recommended. Use this if you’re interested in I think you didn’t use it.
pharmakom 4y ago
C# already had all the advantages of Go (more or less) and more, yet Go is still growing. This has nothing to do with the technical capabilities of the languages.
- andresp 4y ago
  C# GC, MS and external libraries, build, docs, tools support (especially for Linux) are all worse than Java.
  - jayd16 4y ago
    MSBuild is actually really nice, haha. I wish Gradle was that simple.
  - pharmakom 4y ago
    How so? Linux is a first class citizen in .NET these days.
    - pjmlp 4y ago
      A first class citzen would have support for MAUI, and something better than VSCode like macOS gets VS4Mac.
      - jayd16 4y ago
        Does Java even have a MAUI equivalent? There are other open source frameworks for GUI apps. This feels like goal post shifting.
        kaba0 4y ago
        The point is cross-platformness and windows does have MAUI, so not having it on linux means it is not a first-class target.
        metaltyphoon 4y ago
Kwpolska 4y ago
I would say that Go's error handling is a billion dollar mistake as well. The JVM is very impressive and a great thing to build upon. The Java standard library is vast and the developers actually care about it (unlike the Python folks, who gave up on having a sane HTTP client library built-in and instead defer to the third-party requests library). The Java language is not as great, lacking some quality-of-life features (properties and operator overloading, for example). It often suffers from design-by-committee (e.g. https://openjdk.org/jeps/430 https://openjdk.org/jeps/430 ). And then you get to the web frameworks. The most popular one is Spring, and it's a pain, with abuse of reflection and magic, bad docs, and other issues.
- kaba0 4y ago
  > The most popular one is Spring, and it's a pain, with abuse of reflection and magic, bad docs, and other issues How is it any different from something like RoR or Django, both of which are well-liked?
  - tm-guimaraes 4y ago
    Depends if they are talking about Spring the framework, or Spring Boot, the "conventions bootstrapper" Both of them do not have bad docs, maybe some sub project might have, but compared to RoR (sorry never used Django), Spring's projects docs are magnificent. Their problem could be navigation for someone new to it, or in the case of Spring Framework, just too much concepts. So, Spring Framework is basically "make everything configurable extensible etc", its code if full of old java patterns for generic stuff (the infamous "AbstractSingletonProxyBeanFactory" , ye, not great), to not only have a very feature full dependency injection, but to allow stuff like AOP and setting up via xml and many other things. This is the base of spring so you will have to kinda deal with its concepts if you hit an issue. Ruby on Rails was a reaction to things like Spring, it's philosophy is "convention over configuration" in contrast to Spring's unparalleled configuration options. And so Spring Boot is born as a reaction to Rails. Spring Boot is at its core 2 things * an annotation engine for Spring configuration, instead of using all those hellish factories or XML * Sane Defaults for Spring Framework There were also many other projects under its umbrella to streamline with those 2 things other components of the Spring ecosystems, from Http Apis to Repository patterns Ok so reflection and magic: * Both are full of reflection. That's how it keeps being very generic at its core. * Magic is an issue of Boot, you just put some annotation and it would do who knows what. Still way less magic than Rails, as at least you see the annotations, and search for it in the docs. Framework isn't really "magic", as you would have to explicitly configure everything in either XML or through its classes. ( Spring Data does have weird magic, worse that Rails, generating full SQL queries from method names? C'mon) Nowadays, modern java (server side) either uses Spring Boot (due to easily supporting most kind of infra you might use from persistence to messaging), something specific for their use case (quarkus makes it easy for small image and quick startup) or not use a DI framework at all, as most servers nowadays are fine, and language has plenty of features to not need some management of Injected. I actually see no value now to "minimal DI frameworks", because manually wiring is not actually hard except when you have a circular dependency, which you should not have anyway. (The codebases I had better time working with were either on Boot or had no managed DI) Spring Boot and Framework new releases actually require Java17, with the objective of being able to start to clean up their codebase from old patterns that were kinda required in the old times.
Un1corn 4y ago
This is a pretty terrible comparison, suitable for those X-vs-Y websites. While on paper Go and Java have a lot in common, in practice their philosophies differs enough to produce different enough languages. I've used both Java and Go and I can tell you, there is no right or wrong but they differ a lot in their ecosystem, tooling and in design patterns. I don't see myself going back to Java because of the virtual threads.
datadeft 4y ago
It would be great to have a language that is a love child of Erlang and Rust. All I need is: repl, message passing, actor model, lightweight-threads and strong types. :)
- kaba0 4y ago
  Scala? A good contender might be OCaml as well.
- hugofirth 4y ago
  I wish Swift wasn’t so tied to the Apple ecosystem, as it has (IMO) a good mix of these
- brabel 4y ago
  The love child of Erlang and Rust exists already: Pony. https://www.ponylang.io https://www.ponylang.io It really is the best of both languages... unfortunately, the main supporter of Pony seems to have stopped using it in favour of Rust though :D. But if that's really what you want, Pony is your language. It definitely deserves more love.
- rakoo 4y ago
  Are you looking for pony (https://www.ponylang.io/discover/#what-is-pony https://www.ponylang.io/discover/#what-is-pony) ? Never tried it, but it does have actors, reference capabilities (in short, "who can get this piece of memory and what can they do with it") but sadly no repl. There is a playground though (https://playground.ponylang.io/ https://playground.ponylang.io/).
- birdfood 4y ago
  https://gleam.run https://gleam.run is a statically typed language on the BEAM
mseepgood 4y ago
> Java has an obviously better type system How does Java have a better type system? Java's generics are unsound, while Go's generics are sound. Java's generics do type erasure, while Go does not. Java's type system is not unified, it does not have a top type (an int is not an Object, int vs. Integer etc.).
- za3faran 4y ago
  Java has records, pattern matching, and proper enums. As of writing this comment, golang does not allow you to have generics on methods as far as I'm aware.
- kaba0 4y ago
  Haskell’s type system does type erasure, is it “worse” for that?
  - gpderetta 4y ago
    No. Both type erasure and monomorphization have always been legitimate ways to compile generic code. IIRC, the issue with Java is that type erasure is sometimes a leaky abstraction.
    - Quekid5 4y ago
      What exactly do you mean by "leaky" here? Can you give an example? My main issue with non-erased generics is that they actually break reasoning wrt. parametric polymorphism as soon as you allow for pattern matching or even just .isInstanceOf on type parameters. Suddenly a function which takes a List<A> can do entirely different things depending on what A is... and that takes away a powerful reasoning tool.
      - kaba0 4y ago
        It’s leaky due to reflection, but type erasure is not a problem in itself. .NET did away with type erasure, but it had a cost in terms of language ecosystem of the platform - not erasing List<A> into List will bake the variance of List into the runtime, and thus other languages have to use the same model.
samuell 4y ago
Will they provide automatic M:N multiplexing on OS threads, or is that something that needs to be handled by the user somehow? Also, what about channels, and select semantics etc? I think before those are in place, with good library support, it won't be very close to competing with Go. Not to mention compilation to fully self-contained binaries.
- kaba0 4y ago
  > Will they provide automatic M:N multiplexing on OS threads Yes, you can set the number of OS threads they can use. Channels and alia have been implemented in Java’s standard library for many many years, it doesn’t need additional language features.
bhawks 4y ago
The linked article has zero references to golang, so it's unclear if the java community has other golang features they're planning on buying into. This change improves Java/JVM capabilities and that's great. Java is a great language and it's nice that it is shaking off the stagnation/perception of stagnation it has acquired over the years. Golang also has really great capabilities and use cases. Having written tons of code in dozens of languages it seems to be folly to expect one language to rule them all. The features that you don't have are almost as important as the features you do have. If Java is looking for additional golang cherrypicks I would love to see their start times improve (shortlived java processes are painful, Graal doesn't cover all uses). FFI even in Panama is much more boilerplate then CGO. Go's deployment story is so much cleaner and straightforward then Java. The amount of engineering hours saved through language/toolchain standardized formatting is just monumental. Those are just 3 things at random, their are a bunch of other great ideas to steal. I also wouldn't throw any shade at Golang's vibrant library ecosystem. There are just so many great active projects written in pure go that make spinning up new services a joy.
- za3faran 4y ago
  golang doesn't really have other features that Java can take from, since Java is so rich, other than perhaps embedding. But it's been the case that the Java development process has been doing an excellent job at taking a better approach than what exists in adhoc developed languages, so it wouldn't surprise me that they would come up with a superior alternative.
impulser_ 4y ago
I started with Java and I will most likely never go back. I mainly use Go now. People want to learn/write Go. It's hard to find anyone that wants to learn/write Java. People probably prefer Kotlin over Java today. It's a much better language and you can keep using JVM libraries. Go is very simple language that is just as powerful as Java, if not more powerful due to not having to rely on the JVM. That's why it's so popular as a replacement for Java. How are Jars more portable than Go binaries when you need Java installed to run Jars? Java obviously has a more mature ecosystem with more libraries due to age, but Go you don't need many libraries to begin with. The Go std lib will give you almost everything you need in most cases.
- surfsvammel 4y ago
  It’s not hard to find people who want to write Java. I do it all the time. We have been hiring and writing Java code for fifteen years and have not seen a decline in the interest.
  - wiseowise 4y ago
    It’s hard to find quality people who want to write Java.
    - 0xAFFFF 4y ago
      Where I am it's hard to find quality people period. If anything targeting Kotlin or Scala developers usually yields slightly better developers but also further restricts an already small candidate pool.
    - pritambarhate 4y ago
      Really? So you mean to say there are no quality people in the millions of Java programmers out there?
      - wiseowise 4y ago
        No quality people - no, small amount - yes. And millions of Java devs are not your pool.
the_gipsy 4y ago
What Go has going is that it's faster and more pleasant to develop in. Yet another bullet-point-feature bolted on only makes the Java ecosystem jungle worse in that aspect. I find your other points a bit dubious. Java's type system suffers from extreme verbosity and little soundness, and exceptions have not been a successful error-handling story. I don't think you can call a jar that needs a system installation of some specific jre portable - at all. The ecosystem may be huge, but also nightmare in terms of interoperability and support of newer features. IDE click-driven-development is a crutch for the extreme verbosity and complexity of patterns in Java. Compile times are much worse in my limited experience.
- kaba0 4y ago
  Based on your writing, your experience with Java is indeed very limited and not up-to-date at all.
  - the_gipsy 4y ago
    It's simply that the average Java project is out of date and not worth updating, which says a lot.
    - wiseowise 4y ago
      As in works just fine and generates business value despite not being touched in years? Yes, says a lot.
      - the_gipsy 4y ago
        As in the effort to update or just change anything major is similar to a rewrite.
  - bborud 4y ago
    When talking about languages a lot of people talk about languages as if all programmers deal with is starting new projects from scratch and being able to use the latest version of the language, using current practices. For most programmers this isn't the case. Most programmers work on projects that were not started by them, and have been around for a while. Or software that is built on, or has to be closely integrated with, legacy code. Based on your writing, you sound like either a junior engineer, or someone who has had very little responsibility for making resource allocation and strategic decisions.
Dinux 4y ago
Are you kidding me? If it wasn't for large enterprise corporations Java would be long dead by now. Ever since Oracle took over Java has seen almost no improvements. The logical comparison is Java to C#, and C# has seen _a lot_ of improvement over the last 7 years or so. It just so happens that Java is sometimes unavoidable for Android development were Kotlin is not (yet) possible. Java is, like its large corporate users, stuck in the past.
- pjmlp 4y ago
  We are at Java 20, when Sun died we were stuck in Java 6. No improvements, what a joke.
  - Kwpolska 4y ago
    Version numbers are extremely arbitrary, and Java has a new number every 6 months. If you compare Java 6 (2006) and Java 20 (2023), and then look at C# 3.0 (2007) versus C# 11 (2022), C# has gained many more features and improvements than Java did over the years.
    - kaba0 4y ago
      Gaining features without bounds is not a positive in case of a language. C# is a very good language, but they really do copy C++ in adding everything under the Sun to it, and the complexity of managing it all can easily crumble under even good developers. Java may be the other side of it, but I think it is a safer bet.
    - pjmlp 4y ago
      Including copying Java features like tiered compilation, default interface methods, compiler plugins, AOT compilation, being able to run UNIX systems, failing on having phone OS written in C#. Anyone that misses C# on the JVM can use Kotlin or Scala. And best of all, due to Microsoft's lack of investment on VS4Mac and VSCode versus VS proper, the best .NET IDE outside Windows runs on Java/Kotlin.
      - 4y ago
pdpi 4y ago
Java's GC has better throughput, because Go's GC specifically optimises for latency. This may or may not be the right tradeoff for you specifically, but it is a perfectly reasonable tradeoff. Jars are more portable at the cost of requiring a JVM installed on the target, whereas Go's statically linked binaries and great cross-compilation make portability mostly moot for server applications. Also, with Java 21, the JVM brings runtime support for virtual threads, at the VM and standard library level, but there is no real language support, whereas Go has actual support with syntactic sugar around goroutines, channels, and select statements. Tooling and the sheer number of libraries are definitely Java's biggest draws, but it's not enough to justify choosing Java over Go across the board.
- killerstorm 4y ago
  JVM has many different GC implementations, some of them are optimized for low latency, and, in fact, come with guarantees.
- kaba0 4y ago
  Java also has a low-lat GC which is also better than Go’s at the relevant metrics (ZGC).
- lenkite 4y ago
  If you wish statically linked binaries and cross-compilation, you can use GraalVM https://www.graalvm.org/22.0/reference-manual/native-image/StaticImages/ https://www.graalvm.org/22.0/reference-manual/native-image/S.... Fully accept that Go has the superior cross-compilation story, though you can do this via Github actions if you really want this for Java. https://github.com/marketplace/actions/github-action-for-graalvm#building-a-helloworld-with-graalvm-native-image-on-different-platforms https://github.com/marketplace/actions/github-action-for-gra... As for GC - Java is superior in nearly all respects. But you are right that common programming libs+paradigms in Java produce too much garbage. This has changed with lean and memory-sensitive frameworks in Java nowadays - like Quarkus https://quarkus.io/ https://quarkus.io/
commandersaki 4y ago
> Java's jars are more portable than go's binaries Since when?
- jillesvangurp 4y ago
  Well a go binary only runs on the platform it was compiled for. A jar file runs on any platform that has a working JVM. I.e. most commonly used operating systems and CPU architectures you can name. Of course whether that matters to you is another thing. Most people package either of those up using docker and run them on generic linux hosts.
- wiseowise 4y ago
  Since forever.
bborud 4y ago
I think all of the things you point out are probably true. But I still prefer Go. And I'm probably not the kind of person you imagine. I'm in my 50s. I used Java for ~20 years. I spent a lot of time developing efficient programming practices in Java and teaching those to both junior developers and people with decades of experience. I'm also not someone who takes a language switch lightly. It takes much, much longer to become reasonably competent in a programming language and I think that if you are going to choose a "workhorse language", you kind of need to see it as a decade long investment. You don't learn a language in a year. I switched to Go mostly because it is a nicer language for what I do (servers). But I can fully understand why someone would flee Java. Java has a lot of baggage in the shape of legacy code. When people talk about languages they tend to talk about them as if we all live in a fantasy world where we can write new programs from scratch all the time. But that isn't reality for most programmers. Most programmers aren't starting projects from scratch - they work on stuff that has already existed for a while. Java has been around for a long time. Which means that every version of the language, every fad, every architectural trend, everything that has happened in almost 3 decades of Java exists at the same time in codebases that are alive and kicking. When developers get a job, this is what they are faced with. The same is true for C++. Yes, the most recent language spec is a nicer language than what you had 10 or 20 years ago. But that probably isn't the language you get to use when you join a company and start to work on their product. The reason people choose different languages when they do start from scratch (do a startup) probably isn't entirely rational. I suspect a lot of people avoid languages where they have encountered large legacy codebases full of frustrating code that is done in a out of fashion way. I chose to switch to Go, despite having 20 years invested in Java, because Go has the features I need in a language and isn't cluttered with much of what I don't need. It has nicer tooling that just works better for everyday things. It also has a healthier approach to how you design stuff: it isn't dominated by large frameworks. I don't have to teach Go programmers minimalism and have "experienced" programmers throw tantrums because they feel threatened when having to re-learn how to program Java. To be honest, I shudder a bit when thinking about going back to Java. It has so much stuff to deal with when reading other people's code. It doesn't feel like it is worth my time. I can't go back to that. My time is too valuable to me. (I probably should point out that I did decide that I had better find an alternative to Java when Oracle showed itself to be untrustworthy and litigious. But it took years to find both the opportunity to leave Java and the language to leave Java for)
jillesvangurp 4y ago
Well technically, you could do async and green threads / co-routines / promises / futures/ etc. (all the same thing technically, it's all callbacks under the hood) on the JVM for many years. Frameworks like Spring, vert.x, and others have supported this for ages. The loom project just makes it a bit easier to use this and provides some JVM level support and optimization for this. With other JVM languages (Scala, Kotlin, Clojure, etc.) this was already quite easy so it's less dramatic if you were already using those languages. My kotlin co-routines will be using loom threads under the hood pretty soon but it's not going to massively change how I use them or what I do with them. Or make a huge difference in performance. My code isn't CPU bottle necked, typically. Like the vast majority of server software (which is IO or memory bottle necked typically). Go of course has simplicity as its main advantage. That doesn't go away of course. But it's a double edged sword and it can be a bit overly verbose / limited for some stuff. Maybe more interesting is the trend towards native compilation in the Java world. Graal is a pretty big deal. And with languages like Kotlin, there is also kotlin native and wasm as a relatively new option. That's the other advantage Go has had that is slowly going becoming less relevant: fast start up times and a simpler run-time (i.e. a statically compiled binary that you start). ChatGPT is fluent in many languages. I've been generating some usable Kotlin code with it, for example. I'm sure it does Java just fine as well.
spion 4y ago
Kind of, but not quite. There is also: - compiling to a single binary (I guess jpackage fixes this) - saner / less elaborate / more ergonomic interfaces to implement and use e.g. compare `io.Reader` (https://go.dev/tour/methods/21 https://go.dev/tour/methods/21) to the Java equivalent
- pjmlp 4y ago
  Several commercial JDK options have offered compiling to single binary for 20 years, even if out of reach for common folks. GraalVM and OpenJ9 now make it available as free beer as well. https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/io/Reader.html https://docs.oracle.com/en/java/javase/20/docs/api/java.base...
  - jsiepkes 4y ago
    We used ExcelsiorJET to create (pre-compiled) executables for Java (Swing) applications back in 2009 if memory serves me right.
    - pjmlp 4y ago
      Yes, unfortunely they went out of business, leaving PTC and Aicas as survivors from those days.
  - spion 4y ago
    Is that the modern Java equivalent of the single-method interface in Go? I can see its an abstract class - what do you do if you want to implement both Reader and Writer?
    - pjmlp 4y ago
      You implement both, duh. Single method interfaces are what lambdas are for.
      - spion 4y ago
nickstinemates 4y ago
`com.lol.myapp.factory.UserFactoryImpl.java` would like to have a word about its clear superiority
- 0xAFFFF 4y ago
  I you really want to stick to terrible naming and overused architectural principles in 2023 that's your choice but that's hardly a Java issue.
- tm-guimaraes 4y ago
  that's a culture issue that is changing rapidly to avoid that. Also that was common due to previous limitations in the language. regarding the "com.lol.myapp", i actually think this is a good think for package management, it avoids naming issues with packages for different vendors and forks. On the code itself you should only see these on the import lines on top of the file, which isn't really a big deal. I think most people issues with java come from old legacy codebases that had over the top patterns like that due to limitations in the language and culture. Nowadays, with a proper conventions guide, java can be quite clean. Sure it won't ever be as clean as something new as Kotlin, as it tries hard to maintain backwards compatibility, so old ugly stuff will remain in the language (even if you don't use it, you might see old code that does), and new stuff designs are restricted by what already exists, but it still has its advantages over new shiny things like kotlin for example: new pattern matching, compile time and compatibility (kotlin "100% compatibility" doesn't actually cover everything, and compatibility is important for Big Co with loads of teams and loads of internal and external dependencies and tools)
  - beagle3 4y ago
    > that's a culture issue that is changing rapidly to avoid that. Define rapidly. It's now been two decades since I was first told "yes, that's a culture thing, but everyone knows it's crazy, and it's on the way out". E.g., this masterpiece from Benji Smith [0], originally on the old "Joel On Software" forum, is from 2005. [0] https://gwern.net/doc/cs/2005-09-30-smith-whyihateframeworks.html https://gwern.net/doc/cs/2005-09-30-smith-whyihateframeworks...
- 4y ago
kabes 4y ago
As a language java's not that bad at this point. But it still has cultural issues. Every java project I encounter tends to be overengineered, has tons of useless boilerplate code and ends up throwing mile-long stack traces as a result. Also, somehow maven manages to be even more unreliable than npm as a package manager. I still frequently encounter situations which seem to only get resolved by throwing away my .m2 folder. Furthermore, since the language evolved so much in recent years, it's hard for newcomers to know what the best practices are. There's at least 6 different ways to iterate over map values. Which one should I pick?
- Bjartr 4y ago
  If it's snapshots causing issues that clearing .m2 is fixing, try adding `-U` to your mvn execution instead, that forces snapshots to be updated. Do you run `mvn install` for your local project under development, or any of its locally built dependent modules? Are all of those at a snapshot version? If not, I think you'd need to delete it from .m2 (or clear all of .m2) to get updates to it into .m2, since even for the local cache I don't think maven will override a cached version during install.
- jayd16 4y ago
  Don't use ambiguous dependencies and you won't need to flush your cache to get a newer version. I would say the culture is not an issue of Java but of popularity. If Go became the shovelware language of choice, you'd see a lot more bad Go.
- vrnvu 4y ago
  Completely agree with you. I stopped working with Java not because the language or the ecosystem. I stopped working with Java because Java developers and their culture of over-engineering everything defending it as "clean code" and "good practice". But this seems a taboo topic in a culture infested with "good practice gurus".
  - lightbendover 4y ago
    https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... isn't too far removed from some of what I've seen in big tech, especially architecture-wise. Certainly less costly absurdity.
rakoo 4y ago
> So with this, the last thing Go had going for it over Java is gone, right? Go still has composition over inheritance, which is vastly more flexible. Go favors explicit (verbose copy-paste, redundancy, use stdlib first, libraries second) over implicit (magic annotations, frameworks everywhere) and I like when I can understand what's happening without holding 10 files in my brain context. Go's memory usage doesn't trigger the OOM killer every 10 minutes. Go favors copy-pasting because what you copy is short and understandable, and function names don't have 10 words in it. It's always going to be a personal choice, and even though virtual threads bring java closer to where go is, it's still not there for me.
- jayd16 4y ago
  How does a language favor copy/pasting? Do you mean it makes code reuse harder?
  - rakoo 4y ago
    It's not so much part of the language but it's an idiom that is said by one of its authors (https://youtube.com/watch?v=PAAkCSZUG1c&t=9m28s https://youtube.com/watch?v=PAAkCSZUG1c&t=9m28s). "Code reuse" always has some non-compressible context: another import with a line in go.mod, another repo and dependency, which doc is going to be on another page/site, etc... It makes sense for big dependencies but not for small ones; the threshold where "small" becomes "big" being of course subjective.
  - geodel 4y ago
    > How does a language favor copy/pasting? It favors as a culture. A little copying is better than a new dependency Just like Java has culture to setup a single http endpoint one typically adds 50-60 little jar files of Spring Boot starter.
    - kaba0 4y ago
      > Just like Java has culture to setup a single http endpoint one typically adds 50-60 little jar files of Spring Boot starter No, you add a single annotation..
zapnuk 4y ago
A few counterpoints: - Modern Java requires heavy use of Decorators - JSON handling is tiresome - As soon as you are using Spring you aren't actually coding Java anymore - Many mature libraries have dated APIs - Similar functionality is often implemented multiple times in multiple different libraries. Can be confusing if you start out. - Java requires a well configure IDE - However, IDE Support won't matter in a year or two when we have IDE integrated AI support I guess it depends on the problem you want to solve. For the use cases I work on I'd prefer Go for its simplicity.
- aembleton 4y ago
  > As soon as you are using Spring you aren't actually coding Java anymore Can you expand on that. I'm pretty sure its still Java. There are some additional annotations that help with autowiring and object reuse, but probably affect the code less than Lombok.
- kaba0 4y ago
  > For the use cases I work on I'd prefer Go for its simplicity Why don’t “enjoy” the simplicity of assembly then? (Not trying to be sarcastic, just I always felt that this logic is flawed. Especially that java is a very simple language, with very few concepts. If you don’t like, you absolutely don’t have to use metaprogramming like Spring)
  - zapnuk 4y ago
    Yes, Java is a simple language. But all the stuff that was added to Java makes it at times feel bloated and annoying to work with. > Why don’t “enjoy” the simplicity of assembly then? Now thats just stupid.
deleted 4y ago
[deleted]
qtzfz 4y ago
Go doesn't have exceptions. That makes it infinitely better than Java could ever be.
Thaxll 4y ago
I mean having a nice feature does not remove all the other pain points. On your last point go mod is way better than anything available in Java. There're still printing out 600 pages book about Maven. Java will always be a mess of layer of abstraction and magical / heavy framework.
gigatexal 4y ago
Can I get a tiny static binary with Java? Nope. Then Go still has legs. Edit: nvm. You can get static muslc binaries with graal https://www.graalvm.org/22.2/reference-manual/native-image/guides/build-static-executables/ https://www.graalvm.org/22.2/reference-manual/native-image/g...

the-alchemist 4y ago

The "original billion dollar mistake" is lack of runtime bounds checking (in the creator's words), not the idea of a null/nil/undefined generally.

lightbendover 4y ago

> the billion dollar mistake Eh, a billion dollars isn't too bad.

Mawr 4y ago

This is missing the forest for the trees. Languages are very complex, you will not get a good picture of their overall strengths and weaknesses if you limit yourself to a very zoomed-in view, like comparing a few features of the languages themselves. As an example, consider the digital camera market vs the cameras in smartphones. The digital camera is a clear winner! So many features. The quality of photos taken is objectively better in every metric too. And yet the digital camera market is dying, completely killed by smartphones. But why, the features are cleary better right?! Because we're looking at it wrong, we're tunnel-visioned on the "camera" part. We need to look at what actually matters. Thankfully, that's simple to answer and is the same for every product in existence. All that matters is the user experience. Nobody wants extra features on their camera, nobody wants a camera in the first place, nobody wants to take photos either. What people actually want is to preserve the moment of their first born child taking their first steps. The technology is irrelevant as long as it lets the user do what they really want. Why would I want a digital camera when my smartphone has a decent enough one that is effectively free and always available? A low quality camera on you is infinitely more valuable than the professional camera at home. Programming languages are no different, just that "users" in this case are programmers, which seems to be confusing to some. What is the developer experience of using Java vs Go? - that's the real question you need to answer to get to the bottom of this. Start a new project and write some code in both languages, compare the experiences. Be wary of biases, if you have pre-existing experience in one of the languages it's going to shadow your judgement (the curse of knowledge). Pay attention to aspects of good design - how many pointless decisions do you have to get through before actually shipping code? Go eliminates whole areas of pain points: - Dependency management? Go modules. - Tests? Built-in. - Code formatting? Built-in autoformatter. - Compilation time? As fast as it gets. - Distribution? Single binary. - Writing code? Minimal ceremony, just make a function. - Performance? The idiomatic code you write will naturally perform well due to value types, explicit pointers, a culture of straightforward code with no needless indirection. If you need to optimize, the profiling tooling is great and the optimizations themselves straightforward due to intuitive language and GC semantics - just reduce allocations. - GC? A single implementation, good enough for 99% of cases. Two whole knobs available if you really need to tune it. Performs well due to the language not getting in its way. - Standard library? Excellent, good balance between batteries-included and bloat. The built-in HTTP server is suitable for 80%+ of workloads. - Concurrency? Core to the language - syntactically supported green threads. The entire language and its ecosystem are built with it in mind. - Linting? Community-made linter runner with a curated list of good linters. - Found a bug in a library? No problem, the library is written in straightforward Go, the same flavor of Go you've been writing. It's of course autoformatted as well. There you go, a single go-to solution to each problem. The language's designers have gotten all the pointless details out of the way for you. You get to focus on writing code. Now compare the above points with Java. Go was designed for developers, with the same philosophy Steve Jobs designed Apple products for users. Java wasn't. Simple as.

ape4 4y ago

ALGOL originated null

TheDong 4y ago
In ALGOL it was more like a thousand dollar mistake. It didn't become a billion dollars until Java caused NPEs on 3 billion devices
- marginalia_nu 4y ago
  Java's got like the safest most soft-punching NPEs in any language that's got them though. They're so safe you can use them as flow control devices.
  - another2another 4y ago
    yes, but please don't - there's a good dear.
    - marginalia_nu 4y ago
      try { return true; } finally { return false; }
- ajuc 4y ago
  I'm pretty sure nulls in C and C++ caused more problems than in Java :)

hintymad 4y ago

My experience in small companies told me that younger generation didn’t choose Go because Go is objectively better than Java, but because they actively hate Java for it being out of fashion.

jpgvm 4y ago
Irrational Fear of Java is one of the most confusing things among startup stage companies.
- 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

marginalia_nu 4y ago

I think there are still a few changes in the pipe before Java is quite what it could be in terms of performance. Project Valhalla, and the foreign function and memory APIs in particular.

MrBuddyCasino 4y ago
I'm not sure Project Panama will have a large performance influence on most Java deployments. Native interop is rare.
- marginalia_nu 4y ago
  Big part of why native interop is rare because it's slow and awful and generally not worth it. I don't expect a lot of code to actually use these features, but the code that does will be the low level stuff that lets the higher level stuff really perform.
  - kaba0 4y ago
    FFI makes cross-platform usage more questionable (have a look at python or node breaking a build on windows vs linux, this is very very rare in case of Java builds), and Java is more than fast enough for most use cases that it simply doesn’t need FFI for speed (like Python for example). Also, this is a huge advantage of the system, you don’t shallowly depend on a ton of C libraries, you can be confident that your whole application to the last bit is properly abstracted (plus can be debugged and observed with the same great tooling).
    - marginalia_nu 4y ago
      Eh, Java leaves quite a lot of performance on the table compared to C or Fortran. It's not as bad as Python, but if you really want to go fast, it's not quite able to compete with fine tuned native code. The Vector API might help a bit, but I don't think it will go all the way.
      - 4y ago

quanticle 4y ago

while Java originated the billion dollar mistake By the "billion dollar mistake", are you referring to null references [1]? But null references were introduced in 1965 in Algol, by Tony Hoare. They long predate Java. [1]: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/ https://www.infoq.com/presentations/Null-References-The-Bill...

self_awareness 4y ago
I don't think it's about the existence of null references, but how Java is using them. Null references can be a useful, e.g. Kotlin has converted them to be useful (with nullable types).
- Cthulhu_ 4y ago
  Using nulls in Java is mostly a choice on the part of developers; even if you can't migrate to a JVM-targeted language like Scala, you can still adopt practices like null objects [0]. [0] https://en.wikipedia.org/wiki/Null_object_pattern https://en.wikipedia.org/wiki/Null_object_pattern
saurik 4y ago
Speaking of Go and Algol... http://cowlark.com/2009-11-15-go/ http://cowlark.com/2009-11-15-go/

the-smug-one 4y ago

> So with this, the last thing Go had going for it over Java is gone, right? No. Go does containerized microservices better because of its lower memory footprint. If you can use GraalVM then that might not matter.

threeseed 4y ago
This is based on outdated advice. Java stacks like Quarkus [1] have memory as low as 12MB and JVMs like OpenJ9 natively support CRIU for instant startup. [1] https://quarkus.io https://quarkus.io [2] https://blog.openj9.org/2022/10/14/openj9-criu-support-a-look-under-the-hood/ https://blog.openj9.org/2022/10/14/openj9-criu-support-a-loo...
- PlutoIsAPlanet 4y ago
  Yet with Go you don't need to worry about comparing Java Stacks, changing your tooling, testing them etc, the binaries "just work" out the box in a near perfect condition.
  - junon 4y ago
    Not really. We saw overall performance speed up when we limited the number of system threads for goroutines to 1. This was with Docker and Kubernetes (albeit several years ago). This was configured, if memory serves, by an environment variable. So no, it's not as simple and perfect in my opinion.
    - aktau 4y ago
      Performance increasing when setting `GOMAXPROCS=1` sounds like an (interesting) edge case for the scheduler. If you ever encounter this again, it would be great to file an upstream issue about this. Go has plenty of built in observability tools (I imagine runtime/trace would be good here) so it'd be easy to get the developers the data they'd need.
      - 4y ago

vardump 4y ago

"So with this, the last thing Go had going for it over Java is gone, right?" You can deploy Go app with a single binary, no runtime required. No runtime configuration.

foepys 4y ago
Nowadays you don't deploy a global JRE on machines anymore. Each application has its own JRE bundled.

darthrupert 4y ago

Java will always have Java syntax, though. And its runtime will remain rather heavy compared to language implementations that compile down to machine code. Go's benefit's will probably always be there. Java can be taught to 2-year olds so Go seems to have a slight disadvantage there. ;)

jbverschoor 4y ago
Java Card on smart cards?
kaba0 4y ago
Very subjective, but having Java syntax is an advantage compared to goddamn Go — like I have seen my fair share of languages and can generally “read” a new language’s code sample just fine, but go was honestly quite hard the first time with their stupid type, “receiver” etc notation. And I have honestly no problem with Haskell/Lisp/C/etc notation at allz

FooBarWidget 4y ago

As someone who recently developed in Java (for developing a Jenkins plugin) after not having done so for a long time (~15 years), I feel that Java nowadays is technologically quite interesting with many interesting libraries and tooling. IDE code navigation and debugging support is excellent. At the same time, the ecosystem can feel messy and overwhelming. There are multiple @Nonnull annotation libraries and it's not clear what the difference is. There are many different testing libraries (some TDD, some BDD) but it seems everybody picks a different one. There are multiple advanced concurrency libraries and concepts, but again not much consensus and everybody uses a different one. Lots of deprecations all over the place. It's even worse in the Jenkins-specific ecosystem where nearly every plugin uses some deprecated aspect of either Java or Jenkins, and hunting for what the "right" way is supposed to be is a bit of a daunting task. There are like 20 different JDKs, not sure why. On the other hand, startup time and memory usage still seems to be a big issue. Starting Jenkins takes forever even with JVM in client mode and with bytecode verification disabled. And when started it uses a huge amount of memory. To date I've never seen one non-hello-world Java app that isn't like that.

mike_hearn 4y ago
Hi there ;) Knowing you, I'm sure you've got it all figured out by now but for any others who are reading: - Nonnull annotations: you can pick any. Tooling doesn't care and tends to just accept any annotation with a name like @Nullable or @Nonnull regardless of namespace. There was an attempt to standardize this years ago which failed for reasons that are hard to understand from the outside, something to do with lack of agreement on the exact semantics and use cases. No, me neither. Or just write in Kotlin where it's all integrated with the type system and the compiler understands / hides from you the Java annotation mess. - Testing libraries: it's been quite a long time since I encountered anything except JUnit 4 or 5, but they interoperate so that's no big deal. JUnit 5 is great and very standard so you can't go wrong by picking it. - Concurrency libraries/concepts: yes this is a problem but it's one found in other ecosystems, and it's one the new virtual threads are designed to solve. The hope is (and I guess we'll see) that everyone can forget about coroutines and reactive programming now, at least where performance matters, and go back to writing old fashioned ordinary threaded code. I guess they'll stick around in Jetpack Compose GUI programming. - Lots of different JDKs. That is indeed new and unfortunate. They don't actually vary much, mostly in how long major versions remain supported. Amazon is a sort of default choice unless you're doing GUI work, in which case JetBrains Runtime has lots of desktop specific patches. - Startup time/memory usage. There are simple things that can be done to improve this (see AppCDS). Some of it is cultural however, the people who write CI servers probably don't care about startup time. IntelliJ for example starts pretty fast in the latest versions, because they care to optimize it. For memory usage, be aware that the JVM will default to using most of your free system RAM even if it doesn't need to. It figures hey, the RAM is free, so why waste CPU time and energy on garbage collecting if I don't have to. If you planned to use the RAM for something else, or conclude that this is the "natural" level of RAM usage, it can be annoying however. You can give it a limit or in recent versions set a flag that'll cause it to regularly run GC when the app is idle, to give back memory to the OS.

pizza234 4y ago

What's the modern startup time of JARs? I haven't used Java in a long time, but long ago, the relatively slow startup time was a dealbraker for using java to write small tools.

mike_hearn 4y ago
Depends what the JARs do of course. Some desirable libraries are unfortunately slow. PicoCLI for argument parsing is one. It's got every feature you might ever want, but, it adds a couple hundred msec to startup. There is a HotSpot feature called AppCDS. It improves startup time by about 30% in my experiments. However you have to turn it on. Just running `java -jar` won't do it. Then there is GraalVM Native Image. It can compile JARs to native code ahead of time. They start as fast or faster than the equivalent C program, so it's the big hammer for CLI tools. However, it can't cross compile so you have to compile for the target system on the target system. There can also be compatibility issues with some libraries, though that's getting better rapidly. So those are the options. Still, even without those extra features, startup time is usually good enough.
- kaba0 4y ago
  > PicoCLI for argument parsing is one Doesn’t it generate every additional code at compile time? I didn’t notice it slowing down my startup times, it’s mostly every other lib (which you usually have, as what’s the point of a hello world cli app)
  - mike_hearn 4y ago
    I've timed it, it's very slow because it uses reflection to generate the model. The annotation processor doesn't let you avoid this step unfortunately. Native images do.
    - kaba0 4y ago
      But that step only has to run as part of building it. It doesn’t have to run at every invocation. How did you try to run it? From the documentation: > The picocli-codegen module includes an annotation processor that can build a model from the picocli annotations at compile time rather than at runtime. > Enabling this annotation processor in your project is optional, but strongly recommended. Use this if you’re interested in I think you didn’t use it.

pharmakom 4y ago

C# already had all the advantages of Go (more or less) and more, yet Go is still growing. This has nothing to do with the technical capabilities of the languages.

andresp 4y ago
C# GC, MS and external libraries, build, docs, tools support (especially for Linux) are all worse than Java.
- jayd16 4y ago
  MSBuild is actually really nice, haha. I wish Gradle was that simple.
- pharmakom 4y ago
  How so? Linux is a first class citizen in .NET these days.
  - pjmlp 4y ago
    A first class citzen would have support for MAUI, and something better than VSCode like macOS gets VS4Mac.
    - jayd16 4y ago
      Does Java even have a MAUI equivalent? There are other open source frameworks for GUI apps. This feels like goal post shifting.
      - kaba0 4y ago
        The point is cross-platformness and windows does have MAUI, so not having it on linux means it is not a first-class target.
        metaltyphoon 4y ago

Kwpolska 4y ago

I would say that Go's error handling is a billion dollar mistake as well. The JVM is very impressive and a great thing to build upon. The Java standard library is vast and the developers actually care about it (unlike the Python folks, who gave up on having a sane HTTP client library built-in and instead defer to the third-party requests library). The Java language is not as great, lacking some quality-of-life features (properties and operator overloading, for example). It often suffers from design-by-committee (e.g. https://openjdk.org/jeps/430 https://openjdk.org/jeps/430 ). And then you get to the web frameworks. The most popular one is Spring, and it's a pain, with abuse of reflection and magic, bad docs, and other issues.

kaba0 4y ago
> The most popular one is Spring, and it's a pain, with abuse of reflection and magic, bad docs, and other issues How is it any different from something like RoR or Django, both of which are well-liked?
- tm-guimaraes 4y ago
  Depends if they are talking about Spring the framework, or Spring Boot, the "conventions bootstrapper" Both of them do not have bad docs, maybe some sub project might have, but compared to RoR (sorry never used Django), Spring's projects docs are magnificent. Their problem could be navigation for someone new to it, or in the case of Spring Framework, just too much concepts. So, Spring Framework is basically "make everything configurable extensible etc", its code if full of old java patterns for generic stuff (the infamous "AbstractSingletonProxyBeanFactory" , ye, not great), to not only have a very feature full dependency injection, but to allow stuff like AOP and setting up via xml and many other things. This is the base of spring so you will have to kinda deal with its concepts if you hit an issue. Ruby on Rails was a reaction to things like Spring, it's philosophy is "convention over configuration" in contrast to Spring's unparalleled configuration options. And so Spring Boot is born as a reaction to Rails. Spring Boot is at its core 2 things * an annotation engine for Spring configuration, instead of using all those hellish factories or XML * Sane Defaults for Spring Framework There were also many other projects under its umbrella to streamline with those 2 things other components of the Spring ecosystems, from Http Apis to Repository patterns Ok so reflection and magic: * Both are full of reflection. That's how it keeps being very generic at its core. * Magic is an issue of Boot, you just put some annotation and it would do who knows what. Still way less magic than Rails, as at least you see the annotations, and search for it in the docs. Framework isn't really "magic", as you would have to explicitly configure everything in either XML or through its classes. ( Spring Data does have weird magic, worse that Rails, generating full SQL queries from method names? C'mon) Nowadays, modern java (server side) either uses Spring Boot (due to easily supporting most kind of infra you might use from persistence to messaging), something specific for their use case (quarkus makes it easy for small image and quick startup) or not use a DI framework at all, as most servers nowadays are fine, and language has plenty of features to not need some management of Injected. I actually see no value now to "minimal DI frameworks", because manually wiring is not actually hard except when you have a circular dependency, which you should not have anyway. (The codebases I had better time working with were either on Boot or had no managed DI) Spring Boot and Framework new releases actually require Java17, with the objective of being able to start to clean up their codebase from old patterns that were kinda required in the old times.

Un1corn 4y ago

This is a pretty terrible comparison, suitable for those X-vs-Y websites. While on paper Go and Java have a lot in common, in practice their philosophies differs enough to produce different enough languages. I've used both Java and Go and I can tell you, there is no right or wrong but they differ a lot in their ecosystem, tooling and in design patterns. I don't see myself going back to Java because of the virtual threads.

datadeft 4y ago

It would be great to have a language that is a love child of Erlang and Rust. All I need is: repl, message passing, actor model, lightweight-threads and strong types. :)

kaba0 4y ago
Scala? A good contender might be OCaml as well.
hugofirth 4y ago
I wish Swift wasn’t so tied to the Apple ecosystem, as it has (IMO) a good mix of these
brabel 4y ago
The love child of Erlang and Rust exists already: Pony. https://www.ponylang.io https://www.ponylang.io It really is the best of both languages... unfortunately, the main supporter of Pony seems to have stopped using it in favour of Rust though :D. But if that's really what you want, Pony is your language. It definitely deserves more love.
rakoo 4y ago
Are you looking for pony (https://www.ponylang.io/discover/#what-is-pony https://www.ponylang.io/discover/#what-is-pony) ? Never tried it, but it does have actors, reference capabilities (in short, "who can get this piece of memory and what can they do with it") but sadly no repl. There is a playground though (https://playground.ponylang.io/ https://playground.ponylang.io/).
birdfood 4y ago
https://gleam.run https://gleam.run is a statically typed language on the BEAM

mseepgood 4y ago

> Java has an obviously better type system How does Java have a better type system? Java's generics are unsound, while Go's generics are sound. Java's generics do type erasure, while Go does not. Java's type system is not unified, it does not have a top type (an int is not an Object, int vs. Integer etc.).

za3faran 4y ago
Java has records, pattern matching, and proper enums. As of writing this comment, golang does not allow you to have generics on methods as far as I'm aware.
kaba0 4y ago
Haskell’s type system does type erasure, is it “worse” for that?
- gpderetta 4y ago
  No. Both type erasure and monomorphization have always been legitimate ways to compile generic code. IIRC, the issue with Java is that type erasure is sometimes a leaky abstraction.
  - Quekid5 4y ago
    What exactly do you mean by "leaky" here? Can you give an example? My main issue with non-erased generics is that they actually break reasoning wrt. parametric polymorphism as soon as you allow for pattern matching or even just .isInstanceOf on type parameters. Suddenly a function which takes a List<A> can do entirely different things depending on what A is... and that takes away a powerful reasoning tool.
    - kaba0 4y ago
      It’s leaky due to reflection, but type erasure is not a problem in itself. .NET did away with type erasure, but it had a cost in terms of language ecosystem of the platform - not erasing List<A> into List will bake the variance of List into the runtime, and thus other languages have to use the same model.

samuell 4y ago

Will they provide automatic M:N multiplexing on OS threads, or is that something that needs to be handled by the user somehow? Also, what about channels, and select semantics etc? I think before those are in place, with good library support, it won't be very close to competing with Go. Not to mention compilation to fully self-contained binaries.

kaba0 4y ago
> Will they provide automatic M:N multiplexing on OS threads Yes, you can set the number of OS threads they can use. Channels and alia have been implemented in Java’s standard library for many many years, it doesn’t need additional language features.

bhawks 4y ago

The linked article has zero references to golang, so it's unclear if the java community has other golang features they're planning on buying into. This change improves Java/JVM capabilities and that's great. Java is a great language and it's nice that it is shaking off the stagnation/perception of stagnation it has acquired over the years. Golang also has really great capabilities and use cases. Having written tons of code in dozens of languages it seems to be folly to expect one language to rule them all. The features that you don't have are almost as important as the features you do have. If Java is looking for additional golang cherrypicks I would love to see their start times improve (shortlived java processes are painful, Graal doesn't cover all uses). FFI even in Panama is much more boilerplate then CGO. Go's deployment story is so much cleaner and straightforward then Java. The amount of engineering hours saved through language/toolchain standardized formatting is just monumental. Those are just 3 things at random, their are a bunch of other great ideas to steal. I also wouldn't throw any shade at Golang's vibrant library ecosystem. There are just so many great active projects written in pure go that make spinning up new services a joy.

za3faran 4y ago
golang doesn't really have other features that Java can take from, since Java is so rich, other than perhaps embedding. But it's been the case that the Java development process has been doing an excellent job at taking a better approach than what exists in adhoc developed languages, so it wouldn't surprise me that they would come up with a superior alternative.

impulser_ 4y ago

I started with Java and I will most likely never go back. I mainly use Go now. People want to learn/write Go. It's hard to find anyone that wants to learn/write Java. People probably prefer Kotlin over Java today. It's a much better language and you can keep using JVM libraries. Go is very simple language that is just as powerful as Java, if not more powerful due to not having to rely on the JVM. That's why it's so popular as a replacement for Java. How are Jars more portable than Go binaries when you need Java installed to run Jars? Java obviously has a more mature ecosystem with more libraries due to age, but Go you don't need many libraries to begin with. The Go std lib will give you almost everything you need in most cases.

surfsvammel 4y ago
It’s not hard to find people who want to write Java. I do it all the time. We have been hiring and writing Java code for fifteen years and have not seen a decline in the interest.
- wiseowise 4y ago
  It’s hard to find quality people who want to write Java.
  - 0xAFFFF 4y ago
    Where I am it's hard to find quality people period. If anything targeting Kotlin or Scala developers usually yields slightly better developers but also further restricts an already small candidate pool.
  - pritambarhate 4y ago
    Really? So you mean to say there are no quality people in the millions of Java programmers out there?
    - wiseowise 4y ago
      No quality people - no, small amount - yes. And millions of Java devs are not your pool.

the_gipsy 4y ago

What Go has going is that it's faster and more pleasant to develop in. Yet another bullet-point-feature bolted on only makes the Java ecosystem jungle worse in that aspect. I find your other points a bit dubious. Java's type system suffers from extreme verbosity and little soundness, and exceptions have not been a successful error-handling story. I don't think you can call a jar that needs a system installation of some specific jre portable - at all. The ecosystem may be huge, but also nightmare in terms of interoperability and support of newer features. IDE click-driven-development is a crutch for the extreme verbosity and complexity of patterns in Java. Compile times are much worse in my limited experience.

kaba0 4y ago
Based on your writing, your experience with Java is indeed very limited and not up-to-date at all.
- the_gipsy 4y ago
  It's simply that the average Java project is out of date and not worth updating, which says a lot.
  - wiseowise 4y ago
    As in works just fine and generates business value despite not being touched in years? Yes, says a lot.
    - the_gipsy 4y ago
      As in the effort to update or just change anything major is similar to a rewrite.
- bborud 4y ago
  When talking about languages a lot of people talk about languages as if all programmers deal with is starting new projects from scratch and being able to use the latest version of the language, using current practices. For most programmers this isn't the case. Most programmers work on projects that were not started by them, and have been around for a while. Or software that is built on, or has to be closely integrated with, legacy code. Based on your writing, you sound like either a junior engineer, or someone who has had very little responsibility for making resource allocation and strategic decisions.

Dinux 4y ago

Are you kidding me? If it wasn't for large enterprise corporations Java would be long dead by now. Ever since Oracle took over Java has seen almost no improvements. The logical comparison is Java to C#, and C# has seen _a lot_ of improvement over the last 7 years or so. It just so happens that Java is sometimes unavoidable for Android development were Kotlin is not (yet) possible. Java is, like its large corporate users, stuck in the past.

pjmlp 4y ago
We are at Java 20, when Sun died we were stuck in Java 6. No improvements, what a joke.
- Kwpolska 4y ago
  Version numbers are extremely arbitrary, and Java has a new number every 6 months. If you compare Java 6 (2006) and Java 20 (2023), and then look at C# 3.0 (2007) versus C# 11 (2022), C# has gained many more features and improvements than Java did over the years.
  - kaba0 4y ago
    Gaining features without bounds is not a positive in case of a language. C# is a very good language, but they really do copy C++ in adding everything under the Sun to it, and the complexity of managing it all can easily crumble under even good developers. Java may be the other side of it, but I think it is a safer bet.
  - pjmlp 4y ago
    Including copying Java features like tiered compilation, default interface methods, compiler plugins, AOT compilation, being able to run UNIX systems, failing on having phone OS written in C#. Anyone that misses C# on the JVM can use Kotlin or Scala. And best of all, due to Microsoft's lack of investment on VS4Mac and VSCode versus VS proper, the best .NET IDE outside Windows runs on Java/Kotlin.
    - 4y ago

pdpi 4y ago

Java's GC has better throughput, because Go's GC specifically optimises for latency. This may or may not be the right tradeoff for you specifically, but it is a perfectly reasonable tradeoff. Jars are more portable at the cost of requiring a JVM installed on the target, whereas Go's statically linked binaries and great cross-compilation make portability mostly moot for server applications. Also, with Java 21, the JVM brings runtime support for virtual threads, at the VM and standard library level, but there is no real language support, whereas Go has actual support with syntactic sugar around goroutines, channels, and select statements. Tooling and the sheer number of libraries are definitely Java's biggest draws, but it's not enough to justify choosing Java over Go across the board.

killerstorm 4y ago
JVM has many different GC implementations, some of them are optimized for low latency, and, in fact, come with guarantees.
kaba0 4y ago
Java also has a low-lat GC which is also better than Go’s at the relevant metrics (ZGC).
lenkite 4y ago
If you wish statically linked binaries and cross-compilation, you can use GraalVM https://www.graalvm.org/22.0/reference-manual/native-image/StaticImages/ https://www.graalvm.org/22.0/reference-manual/native-image/S.... Fully accept that Go has the superior cross-compilation story, though you can do this via Github actions if you really want this for Java. https://github.com/marketplace/actions/github-action-for-graalvm#building-a-helloworld-with-graalvm-native-image-on-different-platforms https://github.com/marketplace/actions/github-action-for-gra... As for GC - Java is superior in nearly all respects. But you are right that common programming libs+paradigms in Java produce too much garbage. This has changed with lean and memory-sensitive frameworks in Java nowadays - like Quarkus https://quarkus.io/ https://quarkus.io/

commandersaki 4y ago

> Java's jars are more portable than go's binaries Since when?

jillesvangurp 4y ago
Well a go binary only runs on the platform it was compiled for. A jar file runs on any platform that has a working JVM. I.e. most commonly used operating systems and CPU architectures you can name. Of course whether that matters to you is another thing. Most people package either of those up using docker and run them on generic linux hosts.
wiseowise 4y ago
Since forever.

bborud 4y ago

I think all of the things you point out are probably true. But I still prefer Go. And I'm probably not the kind of person you imagine. I'm in my 50s. I used Java for ~20 years. I spent a lot of time developing efficient programming practices in Java and teaching those to both junior developers and people with decades of experience. I'm also not someone who takes a language switch lightly. It takes much, much longer to become reasonably competent in a programming language and I think that if you are going to choose a "workhorse language", you kind of need to see it as a decade long investment. You don't learn a language in a year. I switched to Go mostly because it is a nicer language for what I do (servers). But I can fully understand why someone would flee Java. Java has a lot of baggage in the shape of legacy code. When people talk about languages they tend to talk about them as if we all live in a fantasy world where we can write new programs from scratch all the time. But that isn't reality for most programmers. Most programmers aren't starting projects from scratch - they work on stuff that has already existed for a while. Java has been around for a long time. Which means that every version of the language, every fad, every architectural trend, everything that has happened in almost 3 decades of Java exists at the same time in codebases that are alive and kicking. When developers get a job, this is what they are faced with. The same is true for C++. Yes, the most recent language spec is a nicer language than what you had 10 or 20 years ago. But that probably isn't the language you get to use when you join a company and start to work on their product. The reason people choose different languages when they do start from scratch (do a startup) probably isn't entirely rational. I suspect a lot of people avoid languages where they have encountered large legacy codebases full of frustrating code that is done in a out of fashion way. I chose to switch to Go, despite having 20 years invested in Java, because Go has the features I need in a language and isn't cluttered with much of what I don't need. It has nicer tooling that just works better for everyday things. It also has a healthier approach to how you design stuff: it isn't dominated by large frameworks. I don't have to teach Go programmers minimalism and have "experienced" programmers throw tantrums because they feel threatened when having to re-learn how to program Java. To be honest, I shudder a bit when thinking about going back to Java. It has so much stuff to deal with when reading other people's code. It doesn't feel like it is worth my time. I can't go back to that. My time is too valuable to me. (I probably should point out that I did decide that I had better find an alternative to Java when Oracle showed itself to be untrustworthy and litigious. But it took years to find both the opportunity to leave Java and the language to leave Java for)

jillesvangurp 4y ago

Well technically, you could do async and green threads / co-routines / promises / futures/ etc. (all the same thing technically, it's all callbacks under the hood) on the JVM for many years. Frameworks like Spring, vert.x, and others have supported this for ages. The loom project just makes it a bit easier to use this and provides some JVM level support and optimization for this. With other JVM languages (Scala, Kotlin, Clojure, etc.) this was already quite easy so it's less dramatic if you were already using those languages. My kotlin co-routines will be using loom threads under the hood pretty soon but it's not going to massively change how I use them or what I do with them. Or make a huge difference in performance. My code isn't CPU bottle necked, typically. Like the vast majority of server software (which is IO or memory bottle necked typically). Go of course has simplicity as its main advantage. That doesn't go away of course. But it's a double edged sword and it can be a bit overly verbose / limited for some stuff. Maybe more interesting is the trend towards native compilation in the Java world. Graal is a pretty big deal. And with languages like Kotlin, there is also kotlin native and wasm as a relatively new option. That's the other advantage Go has had that is slowly going becoming less relevant: fast start up times and a simpler run-time (i.e. a statically compiled binary that you start). ChatGPT is fluent in many languages. I've been generating some usable Kotlin code with it, for example. I'm sure it does Java just fine as well.

spion 4y ago

Kind of, but not quite. There is also: - compiling to a single binary (I guess jpackage fixes this) - saner / less elaborate / more ergonomic interfaces to implement and use e.g. compare `io.Reader` (https://go.dev/tour/methods/21 https://go.dev/tour/methods/21) to the Java equivalent

pjmlp 4y ago
Several commercial JDK options have offered compiling to single binary for 20 years, even if out of reach for common folks. GraalVM and OpenJ9 now make it available as free beer as well. https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/io/Reader.html https://docs.oracle.com/en/java/javase/20/docs/api/java.base...
- jsiepkes 4y ago
  We used ExcelsiorJET to create (pre-compiled) executables for Java (Swing) applications back in 2009 if memory serves me right.
  - pjmlp 4y ago
    Yes, unfortunely they went out of business, leaving PTC and Aicas as survivors from those days.
- spion 4y ago
  Is that the modern Java equivalent of the single-method interface in Go? I can see its an abstract class - what do you do if you want to implement both Reader and Writer?
  - pjmlp 4y ago
    You implement both, duh. Single method interfaces are what lambdas are for.
    - spion 4y ago

nickstinemates 4y ago

`com.lol.myapp.factory.UserFactoryImpl.java` would like to have a word about its clear superiority

0xAFFFF 4y ago
I you really want to stick to terrible naming and overused architectural principles in 2023 that's your choice but that's hardly a Java issue.
tm-guimaraes 4y ago
that's a culture issue that is changing rapidly to avoid that. Also that was common due to previous limitations in the language. regarding the "com.lol.myapp", i actually think this is a good think for package management, it avoids naming issues with packages for different vendors and forks. On the code itself you should only see these on the import lines on top of the file, which isn't really a big deal. I think most people issues with java come from old legacy codebases that had over the top patterns like that due to limitations in the language and culture. Nowadays, with a proper conventions guide, java can be quite clean. Sure it won't ever be as clean as something new as Kotlin, as it tries hard to maintain backwards compatibility, so old ugly stuff will remain in the language (even if you don't use it, you might see old code that does), and new stuff designs are restricted by what already exists, but it still has its advantages over new shiny things like kotlin for example: new pattern matching, compile time and compatibility (kotlin "100% compatibility" doesn't actually cover everything, and compatibility is important for Big Co with loads of teams and loads of internal and external dependencies and tools)
- beagle3 4y ago
  > that's a culture issue that is changing rapidly to avoid that. Define rapidly. It's now been two decades since I was first told "yes, that's a culture thing, but everyone knows it's crazy, and it's on the way out". E.g., this masterpiece from Benji Smith [0], originally on the old "Joel On Software" forum, is from 2005. [0] https://gwern.net/doc/cs/2005-09-30-smith-whyihateframeworks.html https://gwern.net/doc/cs/2005-09-30-smith-whyihateframeworks...
4y ago

kabes 4y ago

As a language java's not that bad at this point. But it still has cultural issues. Every java project I encounter tends to be overengineered, has tons of useless boilerplate code and ends up throwing mile-long stack traces as a result. Also, somehow maven manages to be even more unreliable than npm as a package manager. I still frequently encounter situations which seem to only get resolved by throwing away my .m2 folder. Furthermore, since the language evolved so much in recent years, it's hard for newcomers to know what the best practices are. There's at least 6 different ways to iterate over map values. Which one should I pick?

Bjartr 4y ago
If it's snapshots causing issues that clearing .m2 is fixing, try adding `-U` to your mvn execution instead, that forces snapshots to be updated. Do you run `mvn install` for your local project under development, or any of its locally built dependent modules? Are all of those at a snapshot version? If not, I think you'd need to delete it from .m2 (or clear all of .m2) to get updates to it into .m2, since even for the local cache I don't think maven will override a cached version during install.
jayd16 4y ago
Don't use ambiguous dependencies and you won't need to flush your cache to get a newer version. I would say the culture is not an issue of Java but of popularity. If Go became the shovelware language of choice, you'd see a lot more bad Go.
vrnvu 4y ago
Completely agree with you. I stopped working with Java not because the language or the ecosystem. I stopped working with Java because Java developers and their culture of over-engineering everything defending it as "clean code" and "good practice". But this seems a taboo topic in a culture infested with "good practice gurus".
- lightbendover 4y ago
  https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... isn't too far removed from some of what I've seen in big tech, especially architecture-wise. Certainly less costly absurdity.

rakoo 4y ago

> So with this, the last thing Go had going for it over Java is gone, right? Go still has composition over inheritance, which is vastly more flexible. Go favors explicit (verbose copy-paste, redundancy, use stdlib first, libraries second) over implicit (magic annotations, frameworks everywhere) and I like when I can understand what's happening without holding 10 files in my brain context. Go's memory usage doesn't trigger the OOM killer every 10 minutes. Go favors copy-pasting because what you copy is short and understandable, and function names don't have 10 words in it. It's always going to be a personal choice, and even though virtual threads bring java closer to where go is, it's still not there for me.

jayd16 4y ago
How does a language favor copy/pasting? Do you mean it makes code reuse harder?
- rakoo 4y ago
  It's not so much part of the language but it's an idiom that is said by one of its authors (https://youtube.com/watch?v=PAAkCSZUG1c&t=9m28s https://youtube.com/watch?v=PAAkCSZUG1c&t=9m28s). "Code reuse" always has some non-compressible context: another import with a line in go.mod, another repo and dependency, which doc is going to be on another page/site, etc... It makes sense for big dependencies but not for small ones; the threshold where "small" becomes "big" being of course subjective.
- geodel 4y ago
  > How does a language favor copy/pasting? It favors as a culture. A little copying is better than a new dependency Just like Java has culture to setup a single http endpoint one typically adds 50-60 little jar files of Spring Boot starter.
  - kaba0 4y ago
    > Just like Java has culture to setup a single http endpoint one typically adds 50-60 little jar files of Spring Boot starter No, you add a single annotation..

zapnuk 4y ago

A few counterpoints: - Modern Java requires heavy use of Decorators - JSON handling is tiresome - As soon as you are using Spring you aren't actually coding Java anymore - Many mature libraries have dated APIs - Similar functionality is often implemented multiple times in multiple different libraries. Can be confusing if you start out. - Java requires a well configure IDE - However, IDE Support won't matter in a year or two when we have IDE integrated AI support I guess it depends on the problem you want to solve. For the use cases I work on I'd prefer Go for its simplicity.

aembleton 4y ago
> As soon as you are using Spring you aren't actually coding Java anymore Can you expand on that. I'm pretty sure its still Java. There are some additional annotations that help with autowiring and object reuse, but probably affect the code less than Lombok.
kaba0 4y ago
> For the use cases I work on I'd prefer Go for its simplicity Why don’t “enjoy” the simplicity of assembly then? (Not trying to be sarcastic, just I always felt that this logic is flawed. Especially that java is a very simple language, with very few concepts. If you don’t like, you absolutely don’t have to use metaprogramming like Spring)
- zapnuk 4y ago
  Yes, Java is a simple language. But all the stuff that was added to Java makes it at times feel bloated and annoying to work with. > Why don’t “enjoy” the simplicity of assembly then? Now thats just stupid.

deleted 4y ago

[deleted]

qtzfz 4y ago

Go doesn't have exceptions. That makes it infinitely better than Java could ever be.

Thaxll 4y ago

I mean having a nice feature does not remove all the other pain points. On your last point go mod is way better than anything available in Java. There're still printing out 600 pages book about Maven. Java will always be a mess of layer of abstraction and magical / heavy framework.

gigatexal 4y ago

Can I get a tiny static binary with Java? Nope. Then Go still has legs. Edit: nvm. You can get static muslc binaries with graal https://www.graalvm.org/22.2/reference-manual/native-image/guides/build-static-executables/ https://www.graalvm.org/22.2/reference-manual/native-image/g...