Hacker News Reader

Comment by geodel | Hacker News Reader

Okay, are you going to give reason or is it more of a Thought leader style pronouncement?

Haha, I guess you are right.

The reason why it is a mistake is because it is essentially trying to solve the rpc problem once again even though it has been tried many times without success.

There just is a difference between making a synchronous call within your own OS thread vs. making such a call against anything else (the filesystem, the network, ...). Because you can assume that a synchronous call either succeeds and you can continue whatever you do. Or the whole thing crashes because e.g. the thread was killed due to some external effect or OOM error. But in that case, you have the guarantee that no more code on your thread is being run.

With Loom, it is not clear anymore if more code will be run based on your call or not, since there isn't an immediate difference between the two types of calls anymore (when looking at the code). This missing distinction is exactly what makes it easier to use but it also makes it very easy to use the "wrong default".

Joe Armstrong (the creator of Erlang) said the same thing back in 2008.

> The fundamental problem with taking a remote operation and wrapping it up so that it looks like a local operation is that the failure modes of local and remote operations are completely different.

> If that's not bad enough, the performance aspects are also completely different. A local operation that takes a few microseconds, when performed through an RPC, can suddenly take milliseconds.

http://armstrongonsoftware.blogspot.com/2008/05/road-we-didn...

Thx, always feels good to be confirmed by what someone write ~15 years ago. I think he's right.

A comment under Joe’s post points out that this has been understood at least since 1994.

> We argue that objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space. These differences are required because distributed systems require that the programmer be aware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure.

> We look at a number of distributed systems that have attempted to paper over the distinction between local and remote objects, and show that such systems fail to support basic requirements of robustness and reliability.

https://web.archive.org/web/20030310070307/http://research.s...

We can go further - the very first of Peter Deutsch's Fallacies of Distributed Computing, written in 1994, is [1]:

> The network is reliable.

[1] https://www.computing.dcu.ie/~ray/teaching/CA485/notes/falla...

I think that I disagree. Not because I think Loom is a good design, but because I've seen the same design mistake committed a couple times before, and, despite initial hype, people tend learn to hate and avoid it long, long before it can become as intractable a problem as null is.

The worst I anticipate coming from it is some hassles in production and a whole lot of time wasted futilely trying to explain why I don't like it to people who've had 1/10 as much time as me to become bitter and jaded from working in the profession.

> there isn't an immediate difference between the two types of calls anymore (when looking at the code)

There is: sync calls don't change. Async calls use the Future::fork call, all within your parent thread block scope.

Are you saying that Thread.sleep() will still be blocking its OS-thread completely so that this thread executes no other code until the end of the sleep call?

Because otherwise your claim "sync calls don't change" is wrong - since this is how it currently works.

That's the very definition of what sleep() does, and the reason why, if you're calling it in an async context, you need to dispatch it in a special "blocking" dispatcher, as opposed to the other regular async calls.

That doesn't answer my question to the OP. I know what sleep() does and how to use it, but that's not the point.

We are talking virtual threads here(project loom), i think, no?

https://openjdk.org/jeps/428

Basically, you don't have a thread context anymore, or you don't have a use for it anymore

> We are talking virtual threads here(project loom), i think, no?

No.

Currently, when I have code (not using futures or anything) and in the middle there is a Thread.sleep() then I know that this thread will be blocked until the sleep is over (or interrupted) and _no other code is being executed on this thread_.

So the question is: will this behaviour change? Because if it does, then Loom breaks existing code. And that's what it does. And it does it not by accident but on purpose, to retroactively improve performance of exactly those situations where OS threads are blocked.

ah ok i see your single thread is blocked nevermind

I'll take your bet.

First of all, the difference between threads is not nearly as severe as the difference between (remote) machines. There is an analogy to be made, but that's all it is - an analogy. Most applications don't care about nitty gritty thread-management performance.

Second, people said all that shit about network calls and yet... here we live in the age of distributed computing and it keeps getting more distributed. It's rapidly getting to the point where remote boundaries are something you consider as an optimization step. Most boring old business applications are "fast enough" even though the XyzService lives on another machine.

> First of all, the difference between threads is not nearly as severe as the difference between (remote) machines

The whole reason for Loom is to improve performance of code that would otherwise be blocking. So what code is blocking? Exactly: code that waits for the OS (files, network, etc.). A call from one thread to the other isn't really a blocking call and that is not really what project Loom's main focus is about - at least as far as I can tell.

Doesn't the problem you mention for Loom applies equally to OS threads? What's the difference? Loom just lets you create more threads but with OS threads you are doing IO too.

This is independent of OS threads or green threads. The problem is that with Loom the developer loses control whether they can execute something on one OS thread only or not. Whereas right now they conciously have to decide if they want to run something sync or async.

Nothing is stopping the developer from starting a single thread executor and using that to launch many virtual threads. Is that what you meant?

Well, that is something that is desired and also something we can already do in the JVM world.

What I mean is that semantics of existing code changes (and becomes harder to understand for future code).

Loom doesn't hide exceptions. Now you just write the exception handling the same way you would write synchronous exception handling.

It does look awfully like the async/await mess languages with bad concurrency adopted as a crutch for not having good concurrency.

Erlang/Golang model of superlight "threads" exchanging messages appears to be much better at both being actually concurrent and making most code look decent and easy to see what is actually happening.

> model of superlight "threads" exchanging messages

That's exactly what Loom is.

Reply on news.ycombinator.com