161–170 of 777 posts
Earlier quoted context omitted.
So basically executor.submit(). And you still have a language that is significantly less verbose than go, objectively.
Yes, if you ignore more than half of the code it's quite concise.
Earlier quoted context omitted.
I have not used Go generics, but it's viability as a business logic language would depend on that.
they have generics now, but there are other conceptual shifts: - no inheritance - error codes with explicit handling everywhere
Go just assumes if you satisfy the interface, you’re good.
Earlier quoted context omitted.
Wait, what? Generic programming is a perfectly valid style, but are you saying it's essential to implement business logic? Because, like, the last 3 languages that got adopted as the default business logic language didn't have them (Java pre 1.5, C, and Cobol).
and during last 20 years consensus has converged to the view point that generics are essential.
I mean, don't get me wrong. It's quite useful once in a while, especially when working with containers, but I don't think of it as essential.
But I'm fine with it as long as people don't overdo it.
Earlier quoted context omitted.
You must be really lucky then. In my previous job, inheritance and abstract classes were everywhere. Coupled with dependency injection frameworks that "worked like magic", it was really hard to follow the code inside that big, monolithic app. It made me never want to work with Java ever again.
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.
Earlier quoted context omitted.
Wrap it in class Go { static void go(…) } and it will look better with “import static”
I assume `Go` would have to be Closeable and you'd still need the try-with-resources, right?
But you often want the concurrently running threads to return some results, that try-with-resources is part of the structured concurrency that helps you with closing off a branching point, similarly to how we use while loops instead of gotos. `go` in itself corresponds to `goto` basically, with many of the same negatives.
The biggest feature in Java 21 is the release of Virtual Threads: https://openjdk.org/jeps/444 For some reason, this is missing from the article. If there was any feature that would sway existing Golang developers to switch to Java, it would be this. It would perhaps also convince the haters of the reactive-style concurrency patterns.
I don't think Golang devs are waiting to switch to Java if only making a lot of threads was easier. Honestly, its way too early. Virtual Threads will need a a "killer app" (in this case a killer framework) to pull in devs.
Earlier quoted context omitted.
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.
Agreed. Java injection frameworks are opaque and accomplish what they need to with overly powerful mechanisms because of the nature of the language. You don't see that sort of nonsense in python.
Earlier quoted context omitted.
they have generics now, but there are other conceptual shifts: - no inheritance - error codes with explicit handling everywhere
no inheritance but there are interfaces to be able to provide alternate implementations. Similar to traits in Rust. If it quacks like a duck, has feathers like a duck, swims like a duck… Go just assumes if you satisfy the interface, you’re good.
[flagged]
I was able to rewrite and deploy the function in Kotlin in two days' time. It was easy to set up and run, and worked literally first compile and run - a benefit of static types.
Now, would I recommend it to anyone who is unfamiliar with the JVM ecosystem? That's a harder sell. But the stability of the ecosystem and a modern set of saner tools and libraries have made it much better to work in; I'd even call it pleasant.
Earlier quoted context omitted.
> I rarely see inheritance used in practice in java code bases. That seems absurd to me and I have a hard time understanding it, honestly.
> 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 respons…