[flagged]
Me and my catheter will be over here delivering actual software while you figure out how React 32 broke your transcompiler.
I think I will check Java once they finally make coroutines… I mean “virtual threads” a stable feature. That actually looks exciting… being able to parallelize almost like in Go 5 years ago.
Don't you mean fibers? Anyway, I'm pretty sure it's targeted to JDK21.
Java is now catching up with go and adding virtual threads which in september 2023 will have the same ease of use as go had in … 2007?
But as I wrote above, it migh really get me to check java again.
Say that to enterprise software systems still running on Java 7 or 8 without any clear path to upgrade because their whole systems will break.
Let's look at the alternatives you mentioned: Rust and Golang. Java compared to Golang is a much more expressive language. Java compared to Rust is a much easier language because you have a garbage collector for the majority of the cases you don't need the manual memory controls that Rust offers you. In other words, Java is a perfectly valid alternative to both Golang and Rust with its own tradeoffs.
You try to paint a picture of Java not being cool but at the same time I see "modern" companies that are held in high esteem for their engineering prowess using Java to do incredible thing (e.g. Netflix and Google)
Netflix uses Java and Rust and Go.
Twitter used to use Scala.
GitHub uses Ruby on Rails.
EpicGames uses C++.
Instagram uses Python.
Everybody uses something.
Now, if you have building on top of your organizations previous 10 years of engineering, you’re probably going to be writing Java and it’s probably going to be complicated. I’ve been there. I wrote Java for 15 years. I won’t anymore. I’m in love with the simplicity and speed of Golang. I’m in love with the robustness and correctness of Rust. I’m in love with docker pull scratch:latest and putting your binary inside to run on an empty metal container. No need to waste 250MB of ram on a JVM. Use nano size instances and it’s just as fast as c5’s (async based workloads).
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.
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.
> virtual threads but you still have threadpools and os threads
As opposed to what, quantum entanglement threads?
> No one really enjoys debugging your call stacks
Frankly, debugging has probably the very best tooling around the JVM -- so, what exactly is your chosen favorite that would be supposedly better? Or is objective reality not hyped anymore?
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.
AWS Lambda’s documentation shows how to accept a Request and send a response. You don’t need a package for that. For making zips from s3, again, AWS’s sdk. It’s one of the most commonly asked questions on SO. Here’s one implementation for you that could have saved you days:
https://stackoverflow.com/questions/38633577/create-a-zip-fi...
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.
It’s not a sports car, it’s not a dune buggy, it’s not even pretty in its wood paneling and drab paint scheme. But it got your family to Wisconsin for the holidays.
In 2023, we have better options.
Of all the things to criticize about Java, this IMO is not one! A Java call stack is a joy compared to just about anything but Python.
> you still have threadpools and os threads.
why this is a bad thing exactly?
Java, whether it be spring, micronauts, jee, whatever, is wasting CPU and Memory in the cloud costing you and/or your enterprise money.
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.
I am not Go expert, but to me this is Go's big advantage: you can chose you want to have object GC controlled or be on stack and copied everywhere. GC controlled objects add lots of overhead, because malloc is expensive, and require lots of memory per object to track state and synchronize between thread, and that's why JVM tries to adapt something similar: https://openjdk.org/jeps/8277163
Also, any non-toy GC won't be using malloc, e.g. in Java's case allocating objects is barely more expensive than allocating them on the stack: they use a so-called thread-local allocation buffer, which can be used to allocate new objects in, without expensive synchronization, and the GC can quickly scan it, moving still alive objects out of it, and clearing the buffer.
yeah, all these logics still have significant overhead, especially memory wise, it is hard to reason when JVM decides to kick that or another optimization or not kick anything at all.
With value objects you have full control and bare-metal-native performance without compromises.
Not even you believe that, right? Especially with regards to Go.. Go is closer to JS than to Rust/C++.
also, golang has arena API now, and it also makes heap allocations super cheap if you manage to integrate it into app life cycle.
Golang's arenas were an experiment that has already been ditched by the maintainer as un-feasible.
I mean you can pass structs by ref or value around, which makes direct impact will they be on stack or heap.
> Golang's arenas were an experiment that has already been ditched by the maintainer as un-feasible.
Thank you, good to know, looks like big pros in favor of rust as lang for my next project.
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).
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.
This thread was in the context of go generics, which generally means go 1.18, when user defined generics were added to the language. Go always had support for a minimal number of containers, I've never rolled my own when working in the language.
Go had special compiler support for slices, maps, and channels before then, and they got used as the default containers for everything.
Using those was annoying when you needed to do the same thing to, say, a slice of strings and a slice of ints, but if you aren't using a generic heavy style, it actually comes up surprisingly rarely. And, if I'm being honest, I'd consider most of the uses of generics I've seen the average enterprise dev use to be mistakes.
- no inheritance
- error codes with explicit handling everywhere
Go just assumes if you satisfy the interface, you’re good.
Is golang still using mark and sweep gc?