Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala isn't fun anymore

alexn.org

Post reply on HN
Print view View original

311–320 of 394 posts

Re: Scala isn't fun anymore

#311

Post by valenterry »

hota_mazi wrote: post #277
valenterry wrote: post #187

Earlier quoted context omitted.

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.

Re: Scala isn't fun anymore

#312

Post by marcosdumay »

kerblang wrote: post #220
mumblemumble wrote: post #145

Earlier quoted context omitted.

I have personally spent so much time fussing with runtime ClassDefNotFound and MethodNotFound errors in Java that I am no longer able to respond to assertions that Java is type-safe with anything but an incoherent stream of cursing and rage tears. But Scala somehow seems to take all of that and intensify it. I have heard that Scala 3 is supposed to improve this, but I don't anticipate being able to adopt Scala 3 befo…

Those sorts of java runtime errors largely depend on programmers' insistence on doing things via reflection, and it will be the same in any programming language: Like most drugs, at first reflection seems you've opened a new door into enlightenment, until eventually you find yourself sleeping in a gutter with half your teeth missing and wondering why it didn't work out as expected. A lot of Java open source is addict…

The errors are created by failures on finding dependencies.

Re: Scala isn't fun anymore

#313

Post by ithrow »

valenterry wrote: post #111
geodel wrote: post #103

Earlier quoted context omitted.

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…

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.

Re: Scala isn't fun anymore

#314

Post by marcosdumay »

threeseed wrote: post #14
brightball wrote: post #9

Earlier quoted context omitted.

On any platform?

It has the ability to make real-world concurrency scenarios trivial e.g. * 3 fibers - each fetches from remote storage, local storage and in-memory cache. * Race them, kill the two slowest and give me the result. * Free the resources safely including if any of the connections fails for an unforeseen reason. That's a few lines in ZIO. Pain to get working properly in Java, Rust, Go, C++ at least.

It's trivial in Haskell, a bit hard in Rust, really hard in Java, and trivial to get a non-working implementation and declare it flawless on C++. I never tried it in Go.

Re: Scala isn't fun anymore

#315

Post by valenterry »

ithrow wrote: post #313
valenterry wrote: post #111

Earlier quoted context omitted.

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…

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.

Re: Scala isn't fun anymore

#316

Post by gengstrand »

While there are some language features in Scala that are a bit of a buzz kill (see https://glennengstrand.info/software/coding/java/scala for more on that), the OP is mostly complaining about https://en.wikipedia.org/wiki/Dependency_hell

The Akka BSL is a big disappointment to me as well but a better name for that would be LightBend isn't fun anymore.

Re: Scala isn't fun anymore

#317

Post by cube2222 »

threeseed wrote: post #302
cube2222 wrote: post #40

Earlier quoted context omitted.

This is actually trivial in Go as well, with a context (cancellation) and a WaitGroup or channel (waiting for the first one to finish).

I think maybe you've misread the intent. I do not want to wait for the three fibers to finish. I want the whole process to stop the minute any of them have returned i.e. get me my data as quick as possible no matter its source.

I haven't.

You wait for the first result using i.e. a shared result channel, then you cancel the context.

Re: Scala isn't fun anymore

#318

Post by dkarl »

JackFr wrote: post #107
threeseed wrote: post #7

I actually think Scala is in the best position it's ever been. There is a commitment to making the language simpler, easier and cleaner. On the backend, ZIO ( https://zio.dev ) is the best concurrency library on any platform. On the frontend you have really interesting Scala.js projects like Laminar ( https://laminar.dev ). The biggest issue really is the tooling. SBT is simply awful.

> The biggest issue really is the tooling. SBT is simply awful. It's like they sat down and said "Maven has a bunch of problems. Let's fix none of them and introduce a few new ones."

Sometimes when creating software that solves a hard problem, the author is so thrilled by all the little conceptual breakthroughs they experience along the way that they think the users of their software will enjoy it just as much as they did, so they write the software in such a way that the users have to make all the same conceptual breakthroughs in order to use it. SBT feels like that's what happened to it. It's completely inappropriate for a build tool. 99% of the people using a build tool shouldn't have to appreciate how hard it is to write a build tool.

Re: Scala isn't fun anymore

#319

Post by cube2222 »

eweise wrote: post #283
cube2222 wrote: post #157

Earlier quoted context omitted.

And not just goroutines. The whole Go runtime is basically what Loom aspires to be. All functions async by default and preemptible. Writing code that looks like it's blocking but is in fact async. "Await" as the default action to do with an async function, and "go" being the optional action. So far the reception has been very good and it works very well in practice. To me it's a pain now to work with languages that d…

"All functions async by default and preemptible." Really? I thought functions were sync by default unless you add the 'go' keyword.

The `go` keyword means you want to run this function concurrently to what you're doing right now.

You can think of it this way, to use terms from other languages: in Go, every function really returns a Future. But every function call has an `await` implicitly. Using the `go` keyword signals that you don't want that `await`. The call-site action doesn't change whether or not the function itself is asynchronous or not (it is).

However, if you use a mutex in Go, or wait on a channel, or try to write to a TCP connection, those calls won't block an OS thread. Additionally, if a goroutine goes on too long and others are waiting, it will be stopped and the OS thread will work on a different goroutine for a while.

Re: Scala isn't fun anymore

#320

Post by valzam »

cube2222 wrote: post #319
eweise wrote: post #283

Earlier quoted context omitted.

"All functions async by default and preemptible." Really? I thought functions were sync by default unless you add the 'go' keyword.

The `go` keyword means you want to run this function concurrently to what you're doing right now. You can think of it this way, to use terms from other languages: in Go, every function really returns a Future. But every function call has an `await` implicitly. Using the `go` keyword signals that you don't want that `await`. The call-site action doesn't change whether or not the function itself is asynchronous or not…

Is this really true? My impression was that the 'go' keyword means a green thread is spun up for the function to run in and this wrapper returns immediately (hence the need for channels or waitgroups etc to get the results back). I can't imagine that every synchronous function call creates a green thread, that seems massively wasteful.
Post reply on HN