Ron Pressler - Pull Push: Please stop polluting our imperative languages with pure concepts-Curry On

What people said

fzeindl · 2024-11 · Recommendation

Here are more arguments against async/await: [VIDEO] Ron Pressler always was an advocate for blocking code and even joined oracle to add virtual threads to the JVM, thus invalidating the performance argument of the async/await/non-blocking crowd. I really wish young developers would be taught about the actor model and communicating sequential processes before falling for the false promises of async/await-land. And I wish JavaScript runtimes had a way of expressing continuations /blocking threads on their eventloop.

Read the original HN comment ↗

fzeindl · 2024-07 · Recommendation

Does it shake out to any real advantage? To put it shortly: Writing single-threaded blocking code is far easier for most people and has many other benefits, like more understandable and readable programs: [VIDEO] The main reason why non-blocking IO with it's style of intertwining concurrency and algorithms came along is that starting a thread for every request was too expensive. With virtual threads that problem is eliminated so we can go back to writing blocking code.

Read the original HN comment ↗

apta · 2019-06 · Recommendation

> Or Java? Yes - that was implied in the same sentence where I wrote "(e.g. exceptions or actual compiler enforced error handling like Rust)." :-) > As far as I know, race conditions happen and leak out into production with Scala and Java. They do. But there are more techniques in those languages (such as immutable collections, as their type systems are actually able to model and implement them) to mitigate the issue. > and really the lesson of programming in the large for the past 30 years, is that it's not enough to have mathematical or methodological power in guaranteeing correctness in a program. I agree there. I actually don't abide by the ideas that using a language like Haskell or Idris or what have you will automagically grant you superior or error-free software. I actually like what talks like these have to say: * [LINK] * [VIDEO] However, that does not mean we disregard established practices, only to try to reinvent them in a bad way as we see golang trying to do (no generics - even though many other languages implemented them "correctly", bad error handling, no sum types, null pointers, and so on). They purposely disregarded these works without good arguments at all, and now they're struggling to find workarounds, or continue to dismiss them as non-issues, even though they clearly are. The way I see it, the moment Java gets fibers and value types implemented, and GraalVM's native compilation is mature enough for use, golang's appeal as a devops langauge where it en

Read the original HN comment ↗