That feeling is mutual. I very much prefer boring Java or .NET developers who are all supposedly stuck in the 90s to hipsters chasing after the latest JS fad of the week.

> especially not when there are other much better and more modern tools. (which Java is demonstrably playing catch-up with)

Which modern tools do you have in mind here?

Java does indeed playing catch up with new features. That's inevitable for a language came out 30 years ago. OTOTH many other languages are still behind Java in terms of the runtime environment and the ecosystem. You should pick what works for you, not to go with the trend.

> The best talent don't even want to consider working with Java if they can help it.

I think you seriously overestimate how talent those devs are if language is the deciding factor of what they choose to work on.

> I've worked with the kind of engineers who are still doing Java + Spring like it's still the 90s, and they're not the ones you want on your projects

And I've worked with programmers who use the latest fad of the day (golang, etc) and they're not the ones you want to have on your projects.

> The best talent don't even want to consider working with Java if they can help it.

Not in my experience.

To build a good product you don’t need a kid with Hollywood star complex, for whom the choice of programming language or tools matters that much.

If Java repels such self-proclaimed “best talent”, good, because the team will be healthier without them. There’s enough engineers willing to learn and write a good code on Java to solve a business or an user problem, and they are absolutely not mediocre. There’s even no such thing as a scale on which you could put an engineer to measure some “greatness”. Every person is unique and has talents that may be useful in different types of projects.

Hard agree on the maturity, it's clear this person has literally just decided that Kotlin is immature despite it flying in the face of all facts

> I have seen the same problem solved in different languages take 2-3x the amount of work and have a large difference in ongoing maintenance costs

I am sure none of this experiences were basis for an objective experience, there are too many variables. But surely, there are (very few) problems that doesn’t fit Java too well, though it is not an OOP-only language, it is a multi-paradigm one, with many FP concepts seeping into it.

E.g. for some ultra low-lat audio processing I wouldn’t choose it, your binary stream processing may be another good example, though it depends on a bunch of factors and in many cases java is more than fine for that as well.

> reliance on traditional OO means that only a small subset of business domains naturally map to the language's constructs

You don't have to stick to OO constructs. Java has functional programming support and pattern matching.

> best represented as thousands of threads going off to do independent work and then unifying results

Java has had executor support for a long time now. And if you're talking about IO bound tasks, Java has virtual threads now.

> parse a raw binary stream that had a lot of unsigned ints

Java has `Integer.parseUnsignedInt()` and other similar operations.

> Java's reliance on traditional OO means that only a small subset of business domains naturally map to the language's constructs.

In my career I worked on a really wide range of business domains and have not even noticed the problems you are talking about.

The problem of mapping certain types like unsigned int that you mentioned is rather rare integration scenario. There’s not that many domains where numbers with the most significant bit are important, but MAX+1 size numbers are not.

> I don't think I've ever seen a Java codebase that doesn't experience NPEs in prod

Frankly, the last NPE I saw in production was many many years ago.

None of those are a necessity, and they can be easily implemented in an additional layer (e.g. annotation processor if you really wanted to).

Hopefully never. There's a reason no primarily functional language ever became mainstream. The "elegant code" they allow is never as lovely as the zealots imagine

You can easily combine the two, just use a virtual thread and when you hit a `suspend` function use `runBlocking` to get rid of the suspension.

> Google invented Go.

A handful of people at google invented golang is the more correct thing to say.

Yet, google continues to use Java at a much much bigger scale than golang.

golang is simplistic, not simple. Once you work on large golang code bases you'll see the challenges and messes it causes.

You're trying to make the point that the only companies using Java are doing so because of legacy. That is demonstrably untrue. Netflix and Google have had ample time and capacity to replace Java, yet they didn't.

As any good engineer, people working at those companies recognize that Java, Golang, Rust etc. are all tools and these tools have their place in different scenarios.

I used to be like you, but my personal "anti-language" was PHP. I would talk down on organizations using PHP and I would take them less seriously as engineers. But I have come to see that they too are using a language (PHP in this case) as a tool to build a business. And it serves those orgs well apparently.

Don't get me wrong, Java would not be my first choice in many cases. At the company I'm working for, we only use Golang and Python in the backend and Typescript in the frontend. That doesn't mean that I cannot recognize the value the Java can bring and the niche it occupies.

I'm actually pretty amazed by how far Java has come as a language. 10 years ago, I thought Java was going to be replaced by the likes of Kotlin or even Scala. But Java has pretty much caught up in terms of features and ergonomics compared to the Kotlin and occupies a comfortable spot now as being an expressive and productive language without bringing the learning curve and footguns of Scala.

Those are pedantic semantics. I assume you know what I mean. But I'll explain it to you: with Rust you are in control of how memory is managed. Indeed through the borrow checker.

Sounds like you're talking about a pop band, not a tool.

> Golang

golang is probably a good contender for business logic code where Java is widely used, but I feel ecosystem (libs, integrations) is not comparable to Java, so you take some risks while choosing golang.

[dead]

>finally make coroutines… I mean “virtual threads” a stable feature

Don't you mean fibers? Anyway, I'm pretty sure it's targeted to JDK21.

In what language would that marvel be? I give you the less memory....

Maybe you should upgrade from Java 1.4...

It’s almost like there is even a CS law for this exact scenario.. but Java 8 will be around and will still work 10 years from now, plus it is not an insurmountable task to bump it up to the latest version at all. Tell me literally any platform that has a better backwards compatibility story, because honest to God there is simply absolutely none.

Yeah, sure the thing that runs the whole of Apple, Alibaba infrastructure, many part of Google, most of that "cloud" infra is a wagoneer..

Such as...?

A minimal Java app can easily start up in 0.1 seconds, which might just as well be good enough, but if not, there is also GraalVM that can output a native binary.

Trust me, I looked up dozens of references. All would mysteriously halt after several files - known issues with how the Archiver library works, and none with any kind of fix, basically a data race within the library itself. Node's streams and promises are far too complex for far too little added benefit, and leads to broken concurrency in a multitude of libraries, and I'd had enough.

As for startup time - the latency isn't that important and would be an order of magnitude less than the ZIP construction, so the JVM warmup delay is actually just fine. The cost will be slightly higher, but it's not an operation I expect to run with high regularity - it's only on-demand for a reasonably small userbase.

As for complexity - which I am able to weigh due to the above constraints - Java's streams are not only simpler in design, but vastly more stable, and far more straightforward to glue together, and with highly stable implementations of ZIP stream wrappers and output-input pipes. A couple of additional stream wrappers for chunking into multipart upload segments and forwarding streams (introduced in JVM 9 when I'm on 8), and I was ready to go.

All that to say: don't create universal rules, though I agree that all of what you mention are good rules of thumb for certain. My given constraints work just fine with Java, here.

I've seen this response before, but why on earth would we be using C# if not for its included batteries? I can't imagine a world where we would have chosen C# to write an API unless there were some specific benefits, and while I may be wrong to assume this, I don't think I've ever met someone who would. Not so much because there is anything wrong with C# or .Net for that matter, it's okish, it's just well... Honestly, writing C# is a lot like writing typescript with bad linting rules, at least to me. It's not that bad, but it's also not something I'd ever really want to do.

For Linux and macOS you can use Rider and CLI tooling (as expected for most other langs), VS Code is up there but obviously does not come with profiling or advanced debugging tools.

The bias does exist but it's going away, especially that now a lot of developers are moving over to M-series macs.

Groovy is... not Java.

I don't have as much experience or knowledge as others in this thread, but just taking the opportunity to chime in that C# is a great language, and pretty pleasant to work with. And it was a language to which I was introduced as a 24 year old at a venture-backed startup, not at like Boeing or the company Dilbert works at or something.

It has features like LINQ. It has routinely had a lot of good updates, new features always coming out, increases in performance, etc. The primary thing lacking has been good support for developing and deploying on Linux, and a couple other devops-related things. It's a shame to see that holding it back, but at least MSFT actually opened up Linux support at all (nobody thought they would).

See https://isdotnetopen.com/ for why people think .NET has openness issues

Does it have a vested interest to make everything work cross-platform?

Great to hear. I used to program java in 2010 and inheritance was still beeing heavily used back then. But things change, if both the lang and the main community has change to focus more on simplicity its def worth looking at again. Coroutines and pattern matching is really good features

Effective Java, written by Joshua Bloch, and first published in 2001, had a very influential section called Favor composition over inheritance:

https://books.google.co.nz/books?id=Ra9QAAAAMAAJ&q=inheritan...

Why do you think DI is so prevalent in Java codebases? It's a great way of simplifying composition.

I’ve been writing OOP code and reading about it for a decade or two, and inheritance was identified as problematic pretty quickly. The problem today, imo, is more underuse now.

Funnily enough, it actually started from C++. And, Java is so large that it is simply meaningless to talk about a unified style -- sure, some Java EE behemoth will continue to run on a complicated Application Server for decades still, churning on its workload, but so will someone write a Micronaut microservice, or something for robotics, and these will all have distinct styles.

With that said, even the Java EE/Spring complicated word has been moving towards a less inheritance-based future.

Even in Ruby, IME, deep inheritance is fairly uncommon.

Wide inheritance through mixins is common, though.

If you type everything with interfaces in your codebase, you are much less tied to inheritance. In fact, everyone could be written to be composed.

However Java doesn’t support type union so you can get into some ugly and verbose situations but the JVM doesn’t really check type so this is more a compile-time issue and could be fixed in a future Java language revision.

> I rarely see inheritance used in practice in java code bases.

Without some specific call-out, it can be assumed that this is a very niche viewpoint that has no bearing on modern development.

The vast majority of projects use inheritance, today.

Does it use Spring? extends SpringBootServletInitializer

Meaningful responses using values from a request? extends OncePerRequestFilter

Formatting exception handling responses on web requests? extends ResponseEntityExceptionHandler

Then there's all the interfaces you have to satisfy, because it's all tied into the standard library and popular libraries.

    public class App {}

I've never been a big fan of dependency injection. It solves a problem with unit testing in Java, sure, but the reality is that Java could have done some nifty things to help alleviate that as well.

    class MyClass:

        def __init__(self, my_dep1=None):
             if my_dep1 is None:
                 self.my_dep1 = get_my_dep1()  # Or potentially raise
             else:
                 self.my_dep1 = my_dep1

             [...]

    def test_my_class(): 
        mocked_dep1 = MagicMock()
        my_class = MyClass(my_dep1=mocked_dep1)
        [...]

I've seen the same craziness with NodeJS, and very simple Java services with minimal inheritance.

Your Point?

Long:

Please make your Point Understandable.

"in practice it's too tempting to expand the hierarchy."

Not anymore, if you got stuck, by doing that once too often. But 2-3 levels can be allright as well. It depends, what you are doing amd with whom.

> No, there's a lot wrong with inheritance.

No, there is a lot wrong with bad code. No need to blame the language or any programming concept.

Note that I say that for all programming languages, not just Java.

You don't like code reuse?

I think a comma would make it less ambiguous.

Starting that single though with "The" indicates to me that you don't think those are two different ideas.

Compare:

    the idea that inheritance is really good idea and belongs everywhere.

With:

    the idea that inheritance is really good idea. and belongs everywhere.

Such code would be difficult to follow regardless of whether you use inheritance or not. Sometimes, two pieces of code developed independently just need to interact very closely with each other.

Remember that OOP and inheritance to some extent came out of the need to develop GUI systems. Inheritance is still heavily used in GUI toolkits because it's a good fit for that problem space. You have graphs of objects that need to be treated at different levels of abstraction, and controls often need to customize (override) or implement some behavior that shouldn't itself be a part of the public API.

Attempts to get rid of inheritance and OOP in UIs end up looking like Compose or React. I found very quickly when working with these that pure composition just wasn't sufficient and these approaches have their own issues; problems that OOP trivially solves become difficult to impossible to solve cleanly without it.

I've certainly done that in the past, but not since I changed jobs ... 7 years ago. Probably not for several years before then.

> a well-known mantra

which isn't an explanation, but just the same as the OOP mantra that was taught in undergraduate courses.

> This is not a fun situation to deal with and inheritance makes it a lot harder because the "is a" relationship is driving a ton of your logic.

Judicious OOP design allows others to change behavior based upon needs that perhaps the original coder never thought of.

I would not call most Java OOP design judicious. The control in Java is owned by the library writers and the language devs -- not the people using it.

In cases of refactoring, inheritance seriously sucks.

But it is quite advantageous when, as you say, your model is well thought out and stable.

This problem is partly a type system limitation however.

In a more flexible type system with union types and other magical features, your example problem would be less of an issue.

However Java has an extremely limited type system so there is no middle ground between composition and inheritance. Once you choose one way, there is no “middle step” to migrate over.

> you build a classification of all life and it is built upon the idea that everything "is a" plant or animal

With all due respect, this and similar examples are just plain wrong, and I really can't take anyone seriously when that example is used. The point of programming, and its abstractions is to help you complete a task, and make the implementation maintainable and easy to reason about. I think grabbing the "is a" part is fundamentally bad -- there is no point in creating a taxonomy in and of itself, this is no database for that data. Inheritance sometimes is the correct abstraction and while it is definitely overused, when it's correctly applied there isn't really another abstraction that would fit better. E.g. see a graphics library's Node class as the stereotypical correct application.

Inheritance is a useful feature, using bad abstractions is a user error.

Nulls are an error in that no language feature solves them (though third-party tooling does), so far at least.

Records and value/primitive classes are immutable, not to mention https://openjdk.org/jeps/401

Well, that will be available as a basically zero-cost abstraction. But I haven’t seen more specific mention of it in the mailing lists/design proposals - they definitely didn’t want to add a new primitive type, but perhaps if they manage to heal this rift between objects and primitives and it will only be add syntax-level complexity, they might go for it.

It is more verbose than java by all objective counts.

Not having nulls is easy.

Persuading Java devs not to use nulls is hard.

they won’t change the default reference type to non null. might take a few years but you can see their planned syntax here: https://openjdk.org/jeps/401

That's basically what c# has done. But it's implemented as a warning which can be upgraded to an error. I think it might even be an error by default in new projects now.

> The earliest JVMs weren't really thread safe at all but machines were single core so it didn't matter, you could just cooperatively multi-task.

In the 90s we didn't have multiple cores but we had multiple CPUs. I started using java in '96 on a 2 CPU SPARC and the lack of real thread support was limiting. When green threads was dropped in favor of real (OS) thread support there was much rejoicing. I worked primarily in server performance back in those days.

> Virtual threads are M:N threading.

Solaris had M:N threads early on but it also was dropped.

Thanks. Any good books that cover the current java performance landscape but is grounded in the history of what came before?

I used to be heavily involved in java-based server performance and scalability work back in the 90s and 00s but have been working on other things the last decade. But it would be fun to learn more about where things stand.

I was skeptical as well. Thanks for providing feedback. I suspect the way they were counting lines was wrong as 25M lines is a very large project in its own right.

Yes, if you ignore more than half of the code it's quite concise.

I assume `Go` would have to be Closeable and you'd still need the try-with-resources, right?

> The go example is missing the channels, select, wait group, context, cancellation

The Java version would require all of those in the exact same way though.

[deleted by user]

My comment is perhaps too glib. I'm not trying to say that Go is better, I frankly like Java more. I only mean that if I'm in a Go mindset and I read the linked document on virtual threads, and I see that code example, I'm going to close the tab.

> JVM (especially paired with Kotlin)

I agree the Go lang compiler/runtime needs "a Kotlin", with more null-safey build in, proper sum types, a std lib that makes heavy use of null-safety and sum types, better story for polymorphism, better ergonomics for writing stream pipelines, and additional compilation targets (like JS, WASM). This all while proving stellar interop with all Go code, obviously.

Kotlin is quite a sweet deal.

Going on 12 years with Go and agree with everything.

I’ve got to disagree with this strongly. I built and operated the same large system in both languages (acquisition forced me to rewrite) and both the dev and operating cost of the JVM was much higher.

Go is a high velocity language. Code reviews on language/style issues are non existent, it’s GC is blazing fast (not our experience with JVM) and it’s really easy to read. I’ve watched many new engineers ramp up on both systems, as both operated side by side for a while, Go was inevitably faster for engineers.

What made maintaining Go hard for you?

I never see Dart talked about in these contexts but just to highlight a few things.

1. Compiles to native code with a single and very reasonable sized binary on pretty much any platform.

2. Compile to WASM (coming this year) if that’s your thing.

3. Excellent concurrency support with lightweight and simple mental models

4. Variables are not nullable by default thus simplifying tedious checking in your codebase.

5. Syntactically it’s the best parts of Java and JavaScript combined without all the foot guns and verbosity.

6. Full support for both OOP and functional code styles

7. Existing interop support with C, C++, Rust, Java and JavaScript and in the future WASI.

8. Fully static / compile time metaprogramming capabilities coming this year.

9. Also have maybe one of the best teams working on it that I’ve ever seen in an open source project anywhere. They put in a stupid amount of detail and care to try and keep everything pointing in the right direction at a macro level and have really strong levels of transparency around how the language is developed https://github.com/dart-lang/language

Honestly I think it’s critically under-rated and under-used. Most of its common criticisms I see about it are many years out of date.

Shipping one binary to install on a users machine has been solved by jlink and jpackage for ages.

> Go's major selling point to me is that you can ship one binary, nothing beats that.

Are .war files no longer a thing? ;)

I suggest reading about GraalVM...

> Go's major selling point to me is that you can ship one binary, nothing beats that.

You can ship one compiled binary in Java too if you want it. https://www.graalvm.org/22.0/reference-manual/native-image/

> Go is simple. It's easy to understand, read, and maintain

Go involves a lot of code repetition which makes it difficult to human-scan and maintain. Worked on both large scale Go and Java projects and I found Java projects easier and more comfortable to maintain. Had to pay a lot more attention to Go. Go is easier to write though thanks to its well-designed and extensive standard library which is possibly the best in the world, but the maintenance angle still tilts to Java. There are also more Gotchas in Go compared to Java.

How do you distribute a Go library? How do you distribute a Go library that has dependencies?

Fully compiled languages have another huge advantage. If you write a tool in Python and targeted say Python 3.10 then people using Phython 3.9 might not be able to use it. So, you really can't use latest and greatest features of Python 3.11 or 3.12. However, with Go, you can build your tool in Go 1.21 or whatever, and the user does not even need a Go toolchain on their machine.

I was planning to write a small side-project to generate GitHub Actions boilerplate. And this time, I intentionally chose Go for that exact reason. https://github.com/ashishb/gabo

If you want to distribute app to non tech people you do it via browser ;)

> not so great if you want to distribute software for people who are not software savvy, who typically just wants to download one file, install and start using it.

i think it's a flaw that wasn't considered properly in the standard java toolchain to not produce an embedded java runtime into a final packaged artifact that is self-executable.

You end up with third party tooling like: https://www.ej-technologies.com/resources/install4j/help/doc... (and https://launch4j.sourceforge.net/ too).

If oracle bundled this tool into the JDK, it would've not been an issue at all.

Since Java 9, developers can use jlink to provide a pre-packaged runtime environment bundled with the application. It's not static-link friendly or a single executable, but it does not require the user to pre-install anything or pull dependencies at runtime.

You mentioned "distribute software" but did not consider Electron for Node.

You can make an Electron app with JavaScript and ship the binary (or installer) on any platform. It's not a single executable file, but the user experience is the same.

I don't think there's an equivalent in Go that allows you build a desktop app like that (with frontend and backend both written in Go)?

You can easily pack every single class file and resource into one single .jar if you desire to do so, no external dependency apart from JRE itself. Oh and of course no installation necessary, just put it anywhere with read access, all works.

At least in the past you could also make a single .exe out of it via 3rd party if you wanted, but I didnt use that for 20+ years so maybe its not valid anymore.

You just add the -static argument, if you want a fully static executable that can run on any linux distro: ‘g++ -o main main.cpp -static’

You can even go above and beyond with cosmopolitan libc v2, which makes c/c++ build-once run-anywhere: https://github.com/jart/cosmopolitan/releases/tag/2.0

There seems to be some work getting cosmopolitan libc support in Go, but it is not ready like it is for c/c++: https://github.com/golang/go/issues/51900

Edit: There can be some problems with using static, if you are using your system package manager for library dependencies. I would recommend compiling dependencies from source using CMake and FetchContent, this has solved pretty much all problems I have had with c++ dependency management.

I went the other way as I was sick of all the repetition in Go. Spring boot/JPA data repositories save so much SQL, and spring boot automatically marshals to and from JSON, form data, etc. It means you can just work on the meaningful business logic. Add on Lombok and there's even less to maintain.

With the little difference that spring boot offers you 99% of your needs, both to fetch the data from (sql, nosql, you-name-it), and to offer your interface out (web, rest), and programming style (syncronous, asyncronous), and observability, ....

while for go you'll find yourself deep in the mud of choosing what 3rd part library to use for logging and how to make it work with the rest of custom stuff you have to write

And some people for no fucking reason think that they're smarter than everyone else and are qualified to tell others how they should go about they business.

You're entitled to your opinion. I guess I must be a mediocre programmer then. (Don't forget that 90% of developers thinks of themselves as above average.) But if Java can evolve, why wouldn't its practitioners?

That escalated quickly. There are good and less good people everywhere and using language X does not automatically tell anything about you.

If anything I think the cases where you can use Go successfully are only o fraction of the cases where you can use Java successfully. It's not necessarily Java itself but the ubiquity of the JVM and its ecosystem (see Kotlin, see Scala as examplea that have leveraged this ecosystem successfully)

In the past, when java was dominant and most popular language - sure.

Today though, with languages like js being the most popular one, I would be surprised if inflow of mediocre developers into Java world would be even the same, not to mention higher, then with those more popular languages (Go included)

Yeah that's not going to be too popular but Java in particular has a tech culture problem. It's way more common to find overengineering and overabstractions in Java projects than any other language.

The language itself might be fine but I'll never touch it because of that.

This generalisation is easy to explain. On the server-side, Java "won" the enterprise battle. In the last 20 years, big corporates re-wrote their server-side C/C++ stack in pure Java (and thick desktop clients in C#). It is so much easier to maintain than C/C++. As a result, they can hire mediocre Java developers to maintain their "new" legacy services.

    who produce mediocre code based on the wrong ideas of object oriented programming

This overlooks this history of OOP. Each decade, lots of new ideas have emerged so that skilled programmers continue to use the same languages (Java, C#, C++, C), but change how they use them. C++ in 1996? Let's fight about diamond inheritance! C++ in 2006? C++ in 2016? C++ in 2026? Repeat for all four languages that I mentioned. The story will look similar. Anyone good writing new code in these four languages isn't using many levels of inheritance. It is gone. Sure, it exists in the language for historical reasons, but it is hardly used in new code. "Prefer composition over inheritance."

Despite the fact that this is a claim with no basis in reality, what you are saying is that people who don't understand the core concepts the language is built on write bad code...Isn't that true for every language?

Let's not forget who golang was made for:

"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. - Rob Pike

> attracts some mediocre programmers who produce mediocre code

That will be reality for most companies, no matter the language. And if Java projects still got delivered in such conditions - it might also be a mediocre language but it is also just good enough.

Some people are aware about various concepts/paradigms and are able to put each to good use where appropriate.

Other follow fashion and if some dick looking for fame declares A as obsolete and B as the new and shiny one (to be replaced soon anyways) then the lemmings would follow and sing the gospel.

My main pet peeve with Golang is to use single letter or very short abbreviations when naming variables. The Golang documentation recommends what is considered a bad practice by most programmers communities.

Wait, are you implying Go doesn't have error checking? In what way? It has famously verbose error semantics.

I've heard this argument before, and I point out Kubernetes to them. Is that code base complex enough, because it's pure Go doing just fine and runs on plenty of systems?

> Java (and preferably Kotlin) are a lot more serious about making sure your code is robust before it compiles.

You are making great points for Rust, Ocaml and Haskell.

  sealed interface Option<T> permits Some<T>, None<T> {
    record Some<T>(T value) {}
    record None<T>() {}
  }

> You are just at the early phase of the project.

Lately, I am seeing very few codebases getting supported more than 3 years in companies offering software products. Every 2-4 years services are getting rewritten, what's the point of having tool intended for 15 years, when services are deprecated in 4 years

Im convinced Go is just an incomplete language masquerading as a simple one.

>>You are just at the early phase of the project.

Nah.

99% of the code written out there doesn't need layers of indirection, responsibility tossing around, Code splitting across classes, design patterns, inheritance and the class jungle that is common in Java.

Rise of languages like Go is simply majority of the people realising when they want X, they are better of writing just X. You don't have to write a generic version of X that needs to work in a dozen situations. This is for a simple reason. Most of the times, there are no dozen situations. Most, not all the times.

Most of the code I write, doesn't change all that much. If you are writing code that needs to run for decades in an industry where grifting and job hunting is a daily affair you are doing it wrong.

It would be good for my job if learned go, but I've been having a hard time because it's just so boring.

And yet even after writing Go for 5+ years I still have to Google for what actually implements Reader so I can read a file, etc.

Do you mean overloaded methods? You can "override" methods in Go in the sense that if you have an embedded struct you can provide your own implementation in your struct to use instead

[deleted by user]

Java is an inferior language to C#. To get a superior language you would likely have to go for Kotlin. There is no comparison, because Java gets features today that C# had for years. Not even mentioning having to retrofit green threads because adopting async/await (used by TS, Rust, Swift and other languages) is impossible at this point.

   type erasure for generics is annoying

    Set<File> s = new HashSet<File>();

    s.add( new File( "c:/temp" ) );
    s.add( new File( "c:/temp" ) );

    System.out.println( s.size() );

    ISet<FileInfo> s = new HashSet<FileInfo>();

    s.Add( new FileInfo( "c:/temp" ) );
    s.Add( new FileInfo( "c:/temp" ) );

    Console.WriteLine( s.Count );

    string path = "/tmp/filename.txt";
    FileInfo f = new FileInfo( path );

    File.CreateText( path ).Dispose();
    Assert.True( f.Exists );

    f.Delete();
    Assert.False( f.Exists );

  async fn read_file(filename):
    f = await os.open(filename)
    let data = f.read()
    await f.close()
    return data

  fn read_file(filename):
    f = os.open(filename)
    let data = f.read()
    f.close()
    return data

Go has had generics for more than a year now

Afaik, no language as great of exceptional handling as Java. I prefer Go but I have to admit, Java's checked exception handling is amazing.

  fun openFile(fileName: String): File | FileNotFoundException {…}

  val content: String | FileNotFoundException = openFile(“myfile.txt”).?read()
  …then you have to do a check before you use content as a String…

  val content: String = openFile(“myfile.txt”)?.read() ?: “File not found”

What is “enterprise” use? Plenty of enterprises use Go.

    Apache contributors were much better-skilled.

> Exception handling and generics are missing key pieces from go. But adding them will make go look like java.

You know that Go has generics since a couple of years now?

This is definitely one of those. “Tell me you don’t know .NET with out telling me you don’t know .NET” moments.

> I just wish java would add null safety in the type system in a first citizen way

With valhalla (value types), it might just come!

For cases that are IO bound yes. Threads still have their place (another thing that golang doesn't have).

I haven't really used or heard of the others but Spring was already quite good and you really didn't need to think about threads very much. This might help some benchmarks but, again, who is pining for "Spring but with more threads?"

I'm thinking something that would be a clear differentiater such as a multithreaded GUI framework.

If you avoid pre-Java 11 modules in Apache Maven, it is very fast to build. Plus, IntelliJ is auto-magically incremental build. Can you give some specific examples where Java build tools are slow? Most Java developers spend their whole day in an IDE that is doing incremental build, jumping in and out of a debugger to fix bugs or broken unit tests.

Gradle, when the daemon is runnning is very fast, people just often fck up their build scripts to include config-time run functionality, which is just all around a stupid thing to do.

It only ever runs tasks that actually have to be run, has integration with javac, can work in parallel, and even has cross-company build caches if needed.

Also don't forget that Java can do hot reloads with the debugger, or with tools like JRebel. Certain frameworks support it 100% and it will be much much faster than whatever go does.

That's because everybody is busy shipping full web browsers with a hard-coded website inside and calling that an "app".

If you are leveraging Maven, use mvnd during development: https://github.com/apache/maven-mvnd

Ironically, golang does not have constructs to build immutable types to pass them around, while Java does (records).

Yet another reason is that you really want generics for container types and Go's generics are relatively new

He listed off a bunch during the talk.

There are lots. Usually these days, also comparing with TruffleRuby, which also runs on the JVM.

This one is a couple years old now but you get the idea:

https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-yj...

I don't know where to find more up to date benchmarks.

He actually talks about that during the video as well. Short answer is “it depends”.

IIRC Truffle is dramatically faster in some benchmarks but slower in others. And there are some usability aspects of the language that are negatively impacted.

It’s not though. In lots of languages a namespace can span multiple files, whereas a class must be declared in a single file[0][1]. Modules can usually contain a collection of functions and classes. And namespaces can also contain multiple classes/structure/functions and sometimes modules depending on the language[2].

[0]: https://www.typescriptlang.org/docs/handbook/namespaces-and-...

[1]: https://learn.microsoft.com/en-us/cpp/cpp/namespaces-cpp?vie...

[2]: https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...

Then there's even more scattering around of the logic.

Good way:

  PhysicsEngine {
    List<Entities> entities;
    doCollisions() {
      // Logic involving instanceof
    }
  }

Bad way:

  PhysicsEngine {
    List<Entities> entities;
    doCollisions() {
      // Delegate to whomever.
      entities.forEach(e -> e.collide());
    }
  }

  Dog {
    collide() {
      // What the hell can I do here?
      // I don't know about the rest of the world
    }
  }

  Car {
    collide() {
      // What the hell can I do here?
      // I don't know about the rest of the world
    }
  }

Worse way:

  PhysicsEngine {
    List<Entities> entities;
    doCollisions() {
      // Delegate to whomever.
      entities.forEach(e -> e.collide());
    }
  }

  Dog : PhysicalObject {
    collide() {
      super.collide();
    }
  }

  Car : PhysicalObject {
    collide() {
      super.collide();
    }
  }

  PhysicalObject  {
    collide() {
      // Not only do I not know about the rest of the world
      // I don't even know how *I* collide, because what am I?
    }
  }

Ruby modules aren't tied to the file system

Or import ../../../../../asd

Yeah I really like my IDE doing stuff in the background without me knowing shit about it.

>Only if you're using vim like someone from the 70s, otherwise any sane IDE handles those things for you

I don't think that's quite it when Ruby is also from the 90s and figured out not to tie namespace resolution to the directory tree

The/ide/giveths/the/ide/takeths/all/this/could/be/easier/and/you/know/it.

I can't help but think if you're teetering on a knife's edge, only holding on thanks to hyper tuned GC params, then you should take a step back and consider getting out of that predicament.

Is that what happened at your company?

Java sort of suck for microservices (microservices suck on their own) as it has relatively high bootstrap cost.

High allocation rate feels weird with micro services - I suppose that depends a lot on the coding style. G1GC is meant for generally large setups, with several cores at least. E.g. the default setup of 2048 areas on 2GB heap means, allocations over 1MB require special care.

I understand pointers, yet I can’t be trusted never to make a mistake with them. “Each mistake will go uncaught and become an unpredictable catastrophe” is a language problem when your target audience is made of meat.

"But that's because the human's dumb, not a language problem."

If everything is the programmer's fault for being dumb, then Brainfuck is an excellent system language.

> C++ doesn't have any "memory problems"

Well, every time I see someone claim this, I roll my eyes.

> Every time I see something like this I roll my eyes... C++ doesn't have any "memory problems".

You can choose which report you would prefer: Microsoft's, Google's 65%, ... I'm sure they just hired bad developers that don't understand pointers.

Sure, human problem, but if no human can use the tool correctly, then surely there is some problem with it. And no, that doesn't mean that memory unsafe languages don't have a place, but we really should have a very good reason for going down that road.

It must be hard being perfect. The rest of us will keep looking for solutions for mortals.

Another rather new option is VSCode + the Java plugin

Eclipse has seen vast development in the last few years and is fast and easy to use these days.

IntelliJ is very good.

https://www.jetbrains.com/idea/

Isn't that true in any language that lets you allocate memory?

var list = [];

while (true) { list.add(1); }

Here you are, which language won't leak memory here?

Also, which language will let you connect to a prod instance without a performance hit to get some stats on the heap and its allocated objects? Hell, you can even list every instance of a type as I've recently learned.

You can. But you have to try rather hard.

Shitty code is shit in any language. What's your point?

You can leak memory in any language. That’s an impossible bar. The problems op is referring to is obviously about memory safety.

Java obviously isn’t thread safe like Rust is, but it’s typically safer than C++ on that front too.

Sadly this isn't just the case for scientific Python. E.g. some widely-used web library (I forget which) recently switched to using a Rust implementation of TLS, and suddenly you needed a working Rust tool chain available to install it. This caused a lot of grief.

I love Python, and I've been experimenting with Rust and enjoying it so far, but this situation could have been better handled, I think.

I agree 100% about scientific Python though. It's a whole new level of horrible when it comes to dependency management.

DI buys you maintainability.

Without DI, there's too much flexibility in how objects get constructed. If you want to add new functionality to a legacy code base, it can be difficult to track down the different integration points and slow to plumb through your dependencies. These projects can turn into spaghetti very quickly.

DI solves this with a simple recipe: define your functionality, define your dependencies, wire it up to the injector.

The pattern is useful in all OO languages, Python and C++ included.

  > I started using just static factories in my code, and abandoned all those DI and it works well enough.

urllib... getopts...

There's as much useless junk in Python's standard library as there is in Java's.

> run through a VM

This is just incorrect use/understanding of Java’s execution model. It does have a runtime, but it is definitely not a VirtualBox VM.

When java came out? So mid 90s c++ vs mid 90s java?

> In Java I have to

You have to do literally none of these things to write working Java.

[deleted by user]

> I agree C++ is bloated in a 'just make it a setting' / 'add this feature' / 'kitchen sink' sort of way.

Interesting. Can you expand on this, explain more? I honestly don't know what you mean or are referring to -- and I'm a heavy modern c++ advocate -- but suspect if I did it might expand my mindset/viewpoint a bit. :)

Modern Java in Action (the 2nd edition of Java 9 in Action) covers Java 11 and contains a final chapter that talks about "future Java" features -- many of which are now implemented.

It's a great book for Java programmers who want to make the jump to functional-style programming. If that's the transition one is hoping to make, then I would definitely recommend the book.

... and I agree that there is a need for a Java 21+ book which includes discussion of algebraic data types, pattern matching etc.

Core Java for the Impatient (3rd) is less than a year old and updated for Java 17.

I would love a union type in Java, but I still enjoy the language, community and especially development experience. I wouldn't recommend it for everything, but it's sturdy by design and enjoyable for when it fits.

I'd love if interfaces worked as in typescript.

As long as the object signature matches the interface as parameter then you can use it.

[dead]