My vote is for Elixir as well, but it's not a competitor for multiple important reasons. There are some languages in that niche, although too small and immature, like Crystal, Nim. Still waiting for something better.
yeah, if the requirement is "makes it pretty straightforward to write reliable, highly concurrent services that don't rely on heavy multithreading", Elixir is a perfect match.
And even without types (which are coming and are looking good), Elixir's pattern matching is a thousands times better than the horror of Go error handling
I haven't followed swift too closely, but ref counting is not a good fit for typical server applications. Sure, value types and such take off a lot of load from the GC (yes, ref counting is a GC), but still, tracing GCs have much better performance on server workloads. (Reference counting when an object is shared between multiple cores require atomic increments/decrements and that is very expensive).
> but still, tracing GCs have much better performance on server workloads
Good performance with traditional tracing GC's involves a lot of memory overhead. Golang improves on this quite a bit with its concurrent GC, and maybe Java will achieve similarly in the future with ZGC, but reference counting has very little memory overhead in most cases.
> Reference counting when an object is shared between multiple cores require atomic increments/decrements and that is very expensive
Reference counting with a language like Rust only requires atomic inc/dec when independently "owning" references (i.e. references that can keep the object around and extend its lifecycle) are added or removed, which should be a rare operation. It's not really performing an atomic op on every access.
And memory is cheap, especially when we talk about backend workloads.
A tracing GCs can do the job concurrently, without slowing down the actual, work-bearing threads, so throughput will be much better.
> Golang improves on this quite a bit with its concurrent GC
Not sure what does it have to do with memory overhead. Java's GCs are at least generation ahead on every count, Go can just get away with a slower GC due to value types.
Sure, though RC can't get away from pauses either - ever seen a C++ program seemingly hang at termination? That's a large object graph recursively running its destructors. And the worst thing is that it runs on the mutator thread (the thread doing the actual work).
Also, Java has ZGC that basically solved the pause time issue, though it does come at the expense of some throughput (compared to their default GC).
In my opinion they need to invest a lot more time and money into it for that.
The development experience on VSCode was pretty bad (I think the LSP has a memory leak), and some important (for me) libraries aren't tuned very well yet (a Vapor webserver can sit around 100 MiB memory, whereas putting a bunch of load on the grpc implementation balloons the memory usage to >1 GiB).
The only silver bullet we know of is building on existing libraries. These are also non-accidentally the top 3 most popular languages according to any ranking worthy of consideration.
First, we allow main methods to omit the infamous boilerplate of public static void main(String[] args), which simplifies the Hello, World! program to:
class HelloWorld {
void main() {
System.out.println("Hello, World!");
}
}
Second, we introduce a compact form of source file that lets developers get straight to the code, without a superfluous class declaration:
Third, we add a new class in the java.lang package that provides basic line-oriented I/O methods for beginners, thereby replacing the mysterious System.out.println with a simpler form:
Perhaps that it is coming sooner than you think...
It all started with adding Value types, now syntactic refinements à la Go... Who knows? :-)
You'll be very happy.
edit: hold on wait, java doesn't have Value types yet...
/jk
refinement: the process of removing impurities or unwanted elements from a substance.
refinement: the improvement or clarification of something by the making of small changes.
public static void in a class with factory of AbstractFactoryBuilderInstances...? right..? Yes, say that again?
We are talking about removing unnecessary syntactic constructs, not adding as some would do with annotations in order to have what? Refinement types perhaps? :)
> public static void in a class with factory of AbstractFactoryBuilderInstances
That's not syntax. Factory builders have nothing to do with syntax and everything to do with code style.
The oxymoron is implying syntax refinements would be inspired by Go of all things, a language with famously basic syntax. I'm not saying it's bad to have basic syntax. But obviously modern Java has a much more refined syntax and it's not because it looks closer to Go.
Always find 'java is verbose' to be a novice argument from go coders when there is so much boilerplate on the go side of things that's nicely handled on the java side.
Every function call is 3-5 lines in Go. For any problem which needs to handle errors, the Go code is generally >2x the Java LOC. Go is a language that especially suffers from the "code padding" problem.
It's rich to complain about verbosity coming from Go.
Nonetheless, Java has eased the psvm requirements, you don't even have to explicitly declare a class and a void main method is enough. [1] Not that it would matter for any non-script code.
An expert Ruby programmer can do wonders and be insanely productive, but I think there is a size from which it doesn't scale as nicely (both from a performance and a larger team perspective).
PHP's frameworks are fantastic and they hide a lot from an otherwise minefield of a language (though steadily improved over the years).
Both are decent choices if this is what you/your developers know.
Absolutely no on Java. Even if the core language has seen improvements over the years, choosing Java almost certainly means that your team will be tied to using proprietary / enterprise tools (IntelliJ) because every time you work at a Java/C# shop, local environments are tied to IDE configurations. Not to mention Spring -- now every code review will render "Large diffs are not rendered by default." in Github because a simple module in Java must be a new class at least >500 LOC long.
Local environments are not tied to IDEs at all, but you are doing yourself a disservice if you don't use a decent IDE irrespective of language - they are a huge productivity boost.
And are you stuck in the XML times or what? Spring Boot is insanely productive - just as a fact of matter, Go is significantly more verbose than Java, with all the unnecessary if errs.
Local environments are not literally tied to IDEs, but they effectively are in any non-trivially sized project. And the reason is because most Java shops really do believe "you are doing yourself a disservice if you don't use a decent IDE irrespective of language." I get along fine with a text editor + CLI tools in Deno, Lua, and Zig. Only when I enter Java world do the wisest of the wise say "yeah there is a CLI, but I don't really know it. I recommend you download IntelliJ and run these configs instead."
Yes Spring Boot is productive. So is Ruby on Rails or Laravel.
Any production-grade project will use either Maven or Gradle for builds. There are CI/CD pipelines, lints, etc, how would all these work if you could only build through an IDE?
Sure, there are some awfully dated companies that still send changed files over email to each other with no version control, I'm sure some of those are stuck with an IDE config, but to be honest where I have seen this most commonly were some Visual Studio projects, not Java. Even though you could find any of these for any other language, you just need to scale your user base up. A language that hasn't even hit 1.0 will have a higher percentage of technically capable users, that's hardly a surprise.
>Only when I enter Java world do the wisest of the wise say "yeah there is a CLI, but I don't really know it. I recommend you download IntelliJ and run these configs instead."
Then they obviously don't know their tooling well, and I would hesitate to call a jr 'the wisest of the wise'
