Originally posted by juarezr
View Post
Announcement
Collapse
No announcement yet.
OpenJDK Java 22 Rolls Into GA With New Features
Collapse
X
-
Originally posted by partcyborg View Post
Sorry, this isn't remotely true. Go's concurrency/async model is light-years beyond .NET
And in case of Async/await, Go doesn't have them. You can do it a bit more ugly way but in C# you just have keywords async/await and they exist since 2011. If that is best or not, it is up for debate, but according to Wiki, F# was literally first language to support async/awat in 2007, and later it was added to C#. Meanwhile Yield/Tasks are things even way older in C#. And people do like it, only issue i heard from C# corporate programmers with it (I am not C# programmer myself, but worked with a ton of them), is sometimes they pollute call stack when you are using them.
I would say Go's channels is something quite excellent but C# also has fields were you can write what you want asynchronously/concurrent in simpler, shorter code.
Comment
-
Originally posted by cynic View Post
that's my personal perception of fear, when it comes to concurrency:
Go: fearless to write / a bit less fearless when running (there's a lot of errors you can make that could explode at runtime)
Rust: definitely not fearless when writing (!!!) / absolutely fearless to run once you get it to compile 🙂
Java: a good balance of the two
Go is as "fearless" as Rust, only the "do not alter a structure that you have sent over a channel "is a gentleman's agreement, it's not compiler-enforced like Rust. If you abide by that agreement, you're fine.
Rust is definitely not hard to write, it just takes some effort to shake off bad habits you might have picked up while using other languages.
Java can be seen as "a good balance" since by now it includes everything and the kitchen sink. But that makes it a tall order for someone new to the language: when should you use what? It offers neither the simplicity of Go nor the safety of Rust. So it can be seen as the worst of both worlds, too.
Edit: Just to be clear: multithreading is hard. Solutions like Go, that offer something straightforward to use only give the user just a facade to the multithreading problem as a whole. That in itself had pros and cons (but in the context of Go, it does precisely what it's intended to do). As usual: pick the right tool for the job you need to accomplish, don't blame the language.Last edited by bug77; 20 March 2024, 11:18 AM.
- Likes 1
Comment
-
Originally posted by piotrj3 View Post
Except that Go's goroutines can work on different machines I don't see a part of Go that is superior to C#'s Tasks.
And in case of Async/await, Go doesn't have them. You can do it a bit more ugly way but in C# you just have keywords async/await and they exist since 2011. If that is best or not, it is up for debate, but according to Wiki, F# was literally first language to support async/awat in 2007, and later it was added to C#. Meanwhile Yield/Tasks are things even way older in C#. And people do like it, only issue i heard from C# corporate programmers with it (I am not C# programmer myself, but worked with a ton of them), is sometimes they pollute call stack when you are using them.
I would say Go's channels is something quite excellent but C# also has fields were you can write what you want asynchronously/concurrent in simpler, shorter code.
Comment
-
bellsoft jre's work well.
Download Liberica JDK, supported OpenJDK builds. Open source Java 8, 11 and more for Linux, Windows, macOS.
jlink is really a myth, last I checked it couldnt build a working modules file for windows, and there is a load of completely unnecessary garbage gets added.
OTOH, Java 17 was a solid upgrade from 8 (decent memory footprint decreases and perf inprovements), and looks like it continues to improve.
- Likes 2
Comment
-
Originally posted by piotrj3 View Post
Except that Go's goroutines can work on different machines I don't see a part of Go that is superior to C#'s Tasks.
And in case of Async/await, Go doesn't have them. You can do it a bit more ugly way but in C# you just have keywords async/await and they exist since 2011. If that is best or not, it is up for debate, but according to Wiki, F# was literally first language to support async/awat in 2007, and later it was added to C#. Meanwhile Yield/Tasks are things even way older in C#. And people do like it, only issue i heard from C# corporate programmers with it (I am not C# programmer myself, but worked with a ton of them), is sometimes they pollute call stack when you are using them.
I would say Go's channels is something quite excellent but C# also has fields were you can write what you want asynchronously/concurrent in simpler, shorter code.
Go doesn't have those explicit keywords, but with goroutines and channels you can implement the exact same thing. There are tons of async libraries for go implemented this way. That is the beauty and superiority of go, you can do so much more with less
- Likes 1
Comment
-
Originally posted by scottishduck View PostI’m a little unclear on modern Java. Why is it the JDK is rapidly developing through versions but JRE remains at v8. Is the JRE versioning just a compatibility thing and it can run code from the latest JDK?
And I agree, jlink has little-to-no adoption right now.
Comment
-
Originally posted by partcyborg View Post
Go doesn't have those explicit keywords, but with goroutines and channels you can implement the exact same thing. There are tons of async libraries for go implemented this way. That is the beauty and superiority of go, you can do so much more with less
OTOH
Comment
-
Originally posted by mSparks View Post
I really like the where GO seems to be going, I think its a big leap to suggest its as mature as Java yet, but the progress there is nothing short of phenominal.
OTOH
https://fasterthanli.me/articles/i-w...angs-wild-ride
I agree it's not a perfect solution for everything, but for not-so-skilled developers, it's a Godsend. I was recently doing a presentation of Go, I wrote some code to show how to exercise concurrency and after I wrote it, it struck me: the code worked from the first try! That's where Go really shines.
Comment
-
Originally posted by bug77 View Post
"Go doesn't have generics"... How old is that article?
Originally posted by bug77 View PostI agree it's not a perfect solution for everything, but for not-so-skilled developers, it's a Godsend. I was recently doing a presentation of Go, I wrote some code to show how to exercise concurrency and after I wrote it, it struck me: the code worked from the first try! That's where Go really shines.
"making the result "production-ready" is left as an exercise to the writer. Big companies that have adopted it have developed tons of tooling around it, use all available linters, do code generation, check the disassembly, and regularly pay the engineering cost of just using Go at all."
and
"Or rather, it's a half-truth that conveniently covers up the fact that, when you make something simple, you move complexity elsewhere."
Both of which are where java shines (you shift the complexity to a self contained jar), and are pretty much essential to getting software to the point it actually pays the bills (aka production ready).Last edited by mSparks; 21 March 2024, 01:37 PM.
- Likes 1
Comment
Comment