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

351–360 of 394 posts

Re: Scala isn't fun anymore

#351

Post by seer-zig »

marcosdumay wrote: post #314
threeseed wrote: post #14

Earlier quoted context omitted.

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.

This will make it trivial in Java: https://openjdk.org/jeps/428

Re: Scala isn't fun anymore

#352

Post by layer8 »

clhodapp wrote: post #338
layer8 wrote: post #186

Earlier quoted context omitted.

A major problem is that Maven (and friends) doesn’t distinguish between API dependencies (the API of a library using types from the API of another library) and implementation dependencies (a library depending on another library as an implementation detail). If that distinction were made consistently, implementation dependencies could indeed be separated into a dedicated classloader for each library, and you’d only ha…

I believe that separating interface from implementation doesn't really solve the problem, it just shrinks it. E.g. what if you depend on two libraries that re-export classes from different versions of a third library? I think that if you truly want to solve the problem, you need to extend the definition of the fully qualified classname to include the notion of a breaking version reference. Kind of like what folks now…

I agree, but I believe the “shrinkage” would already reduce the problem substantially, and maybe more importantly, would make developers more careful about what they include as interface dependencies instead of as just implementation dependencies.

Re: Scala isn't fun anymore

#353

Post by tasuki »

auggierose wrote: post #203
valenterry wrote: post #199

Earlier quoted context omitted.

I'm not so sure. The problem is that the world is moving, including hardware, software, interfaces but also people and process. Languages have to optimize against a moving target. So naturally it's a good idea to optimize for something moving and not something static. This is what makes Scala good. The language itself is not very complex actually, but it enables complex and powerful libraries.

We are still in the phase where concepts are settling. Pretty sure nobody in a 100 years will think that Monads are a good idea.

> We are still in the phase where concepts are settling.

Yes of course concepts are still settling, and they always will be.

> Pretty sure nobody in a 100 years will think that Monads are a good idea.

Why? I for one am pretty sure monads will be a useful concept a hundred years from now.

What about functors, will that concept also be obsolete?

Re: Scala isn't fun anymore

#355

Post by pestatije »

valenterry wrote: post #187
pestatije wrote: post #155

Earlier quoted context omitted.

> 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.

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

Re: Scala isn't fun anymore

#356

Post by cube2222 »

eweise wrote: post #345
cube2222 wrote: post #325

Earlier quoted context omitted.

It doesn't create a green thread. I meant async in the technical underlying runtime sense of not blocking an OS thread when doing seemingly blocking operations and tried to describe it in an approachable way. Async in the sense of a python or rust function that is declared as async. If you think in terms of function colors (async and non-async) Go only has async ones. The `await` and `go` bit are an intuition about h…

I don't see anything in the docs about cancelling a standard function. Maybe internally Go represents a function as some type of future but for all practical purposes, it looks to me like a function in Go is just as synchronous as as a function in say java.

There's a big difference. If you write to a file using the stdlib in java, you will block an OS thread. In Go you won't.

That does not mean all Go calls are cancelable, they're not.

If, in a Scala/Python/Rust async function you use a synchronous stdlib function, that call will block the whole OS thread with it.

The following experiment will show you the difference:

In Java, run 10 futures on a threadpool of 4 workers, with each future doing a thread.Sleep(1s). That will finish after 3 seconds.

In Go, run 10 goroutines with GOMAXPROCS=4, with each doing time.Sleep(1s). That will finish after 1 second.

Re: Scala isn't fun anymore

#358

Post by auggierose »

hither_shores wrote: post #335
auggierose wrote: post #216

Earlier quoted context omitted.

Given that our brains have been the same for a few thousand years, maybe I don't need to optimise for that. Anyway, what we currently have as programming languages are all workarounds. Necessary for now, because how else would we program? But in the end we need to converge programming, math and logic, and once this is done, we will be ready for anything. And we won't need monads as a crutch, forced upon us by a type…

> But in the end we need to converge programming, math and logic, and once this is done, we will be ready for anything. And we won't need monads as a crutch, forced upon us by a type system. 1. Math is filled to the brim with monads, it's just that mathematicians are necessarily specialists, and tend to think about things in terms of their applications to their specialties: they talk about closure operators or algebr…

Type theory is already dead, it just doesn't know it yet.

Re: Scala isn't fun anymore

#359

Post by valenterry »

pestatije wrote: post #355
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.

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.

Re: Scala isn't fun anymore

#360

Post by p_l »

azemetre wrote: post #180
Test0129 wrote: post #172

Earlier quoted context omitted.

https://www.theregister.com/2022/09/08/open_source_biz_sick_... Here's an article on it. Their logic actually makes sense. Not that I support gouging customers, but when you consider how there are massive billion dollar companies with expensive lawyers figuring out how to end-around OSS (via SaaS, etc) this is the logical conclusion. A lot of companies make a lot of money on OSS and give little to nothing in return.…

If you’re making $25mil in revenue why is it out of the question to pay for licenses?

Because $25mil in revenue might still mean less profit than the cost of Akka licenses will add.

Remember, Revenue is before applying costs - costs like extra million here or there from licensing and costs of servicing the license which I think many people forget about. Especially when the software doesn't have some automated methods of license management.

Post reply on HN