I've watched some of Mark Rendle's talks (like this one https://youtu.be/2-mFWi5oLkM) and while watching it I realized how much I dislike when languages start to absorb ideas that are either alien to the language, or offer multiple paradigms for solving the same problems.
I can understand Java programmer want the goodies offered in languages that are more geared towards concurrency. But multiparadigmatic languages really suck because they are no longer a single language. You get islands of different practices and a partitioned set of practitioners. And they can't always use each other's code (C++ being the most extreme and painful example).
This makes me kind of glad I switched to Go 5-6 years ago. And it makes me wonder when the (good) intentions of the Go designers to not absorb every idea that comes along will go out the window and Go will start to grow knobbly bits all over.
I think you can say that for any language, other than Java. It is a deliberately slow moving language, with very few keywords and concepts going for it. It was always meant to be a simple language on top of a very high-end runtime — and indeed they manage to implement loom with no language change. Also, concurrency not being inherent to java? It was the first major language with good support for multithreading with its synchronized keyword.
Java was one step along the way, but let's say it had adequate representation of heavy-handed tools we already had in C/C++ that made some forms of concurrency somewhat easier. But it was still some ways from promoting concurrency in that threads were pretty costly and you still depended on locking to move state between threads. And it isn't like CSP hadn't been thought of.
After about 20 years of programming Java and 5-6 years programming Go I wouldn't really list concurrency as a main feature of Java. Because you kind of go at it the way you go at it in C/C++. I think someone who has programmed (for instance) Erlang would feel much the same way.
Java exposes the low-level details of parallelism, but it also allows for high level abstractions on top. Thanks to that there are indeed libraries like Akka to provide something for those that prefer the actor model, but also clojure with its immutable data structure-using concurrency and anything in between like reactive libs. Of course concurrency has never been easy in practice so the low level details are hard to get right, but they are there in a sane and easy to use way, so if not the main point of the language, I would absolutely mention it as one of the most important plus features.
Does Go have closures? Yes it does. Therefore you can start writing everything in an async style, manually passing closures around. Then build an executor interface. Voilà. Here's an utterly alien Go codebase that doesn't use green threads.
It has nothing to do with language. It has everything to do with how other libraries (especially standard libraries) structure their code.
This is literally avoiding "bifurcating the language" and avoiding the function coloring problem, its the whole point! Otherwise they could have just copied Kotlin's coroutines. Everything works as before using the familiar Thread API, just with a different underlying machinery.
your comment surprises me, because this kind of development is explicitly trying to avoid bifurcating the language. i would argue that the async io/futures libraries that exist in java are the bifurcation because programming with them is very jarring compared to threaded java.
His comment bellies his clear ignorance to both the Java development process and Loom in particular. Such comments aren't unusual where Java is concerned, it's the one language where many are willfully ignorant (well PHP is also in contention).
Pay them no mind though. Java is already the premier server side language for serious work and this is just another tool in the toolbox, hopefully I will see less RxJava in my future. :)
Yes, and I am hoping that Go won't go through the same. But if you think about how different languages have evolved they do, over time, tend to end up in places where it gets harder and harder to avoid.
I can understand Java programmer want the goodies offered in languages that are more geared towards concurrency. But multiparadigmatic languages really suck because they are no longer a single language. You get islands of different practices and a partitioned set of practitioners. And they can't always use each other's code (C++ being the most extreme and painful example).
This makes me kind of glad I switched to Go 5-6 years ago. And it makes me wonder when the (good) intentions of the Go designers to not absorb every idea that comes along will go out the window and Go will start to grow knobbly bits all over.