Hacker News Reader

Comment by bestinterest | Hacker News Reader

I very much like the ethos of Golang for this reason. Still not had a reason to use it but like the idea of mastering the fundamentals in a weekend. Even if I lose the flexibility of LINQ or Java streams.

It feels like a scale of language conservativeness Go all the way at the top, Java somewhat in the middle (a little above) and C# at the bottom. It is going the route with lots of features and complexity, which can be a great thing but not for grug devs https://grugbrain.dev like me.

But saying all that Blazor looks really good for WebDev, I just worry it gets abandoned. It feels everything does in the C# space.

C# also made a big mistake imo by going with async/await instead of lightweight threads which will add a ton of complexity in the future for if they decide to go the greenthread route like Goroutines/Project Loom.

View on HN

> But saying all that Blazor looks really good for WebDev, I just worry it gets abandoned. It feels everything does in the C# space.

I've been maintaining a asp.net (WebForms!) framework codebase for almost 18 years now. Running on the latest Windows Server and Visual Studio 2022.

> C# also made a big mistake imo by going with async/await instead of lightweight threads which will add a ton of complexity in the future for if they decide to go the greenthread route like Goroutines/Project Loom.

Could you expand on this? Async/await is just syntax magic for Task continuations (in other words, Promises [0]), which have very little to do with the underlying threading model. This statement is equivalent to saying "Completable Futures add a ton of complexity to Project Loom."

[0] https://en.wikipedia.org/wiki/Futures_and_promises#List_of_i...

IIRC, the statement was from some Java blog about Loom. Idea is that with lightweight threads you can make everything sync and still be performant. While C# has gone ahead with making everything async

I understand the difference in approaches. However, the parent stated that this decision makes green threads harder in C#, which is what I don't understand.

I think this post has the best information on it as I am also learning here https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

It is not just `magic` syntax imo, it is viral to your codebase. The blog post does way more justice than I can explain.

For what it's worth, there is experimentation of green thread in C# happening.

Yes I understand the function coloring "problem" (oh no functions need to specify in their signature whether they return results immediately or eventually). Regardless, I still don't understand how this prevents green threads a la Project Loom, if you have a function that returns a `CompletableFuture` in Java, it also needs to change its signature.

Reply on news.ycombinator.com