Scala isn't fun anymore

Post by seer-zig » Wed, Sep 14, 2022, 5:27 AM UTC

mumblemumble wrote: post #279

kerblang wrote: post #220

Earlier quoted context omitted.

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…

I don't think that this is entirely fair to Java programmers. Java's designers decided early on to lean fairly hard on reflection. Not just by giving Java strong reflective capabilities, but by sometimes deliberately choosing not to give Java great facilities for solving problems without using reflection. When I first came to Java from .NET, I was initially shocked at how heavily it was used in the Java space. (.NET…

Post by pragmatick » Wed, Sep 14, 2022, 6:12 AM UTC

jillesvangurp wrote: post #237

cryptos wrote: post #162

Earlier quoted context omitted.

A good middleground is Kotlin. You get some of the nice features / syntax from Java without the problems. While Scala is actually a way more powerful language, Kotlin is more than good enough for most real world tasks and the tooling is so much better.

Exactly, you might even go as far as to say that Kotlin exists because the people at Jetbrains looked at and dismissed Scala as just not what they were looking for in a language. And then they went on to develop Kotlin instead. Kotlin is unique in the sense that the language originated from a company whose primary business it is to provide developer tooling and IDEs (intellij). They know a thing or two about what dev…

Post by eweise » Wed, Sep 14, 2022, 6:45 AM UTC

cube2222 wrote: post #325

valzam wrote: post #320

Earlier quoted context omitted.

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.

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…

Post by oftenwrong » Wed, Sep 14, 2022, 7:13 AM UTC

badpun wrote: post #42

saberience wrote: post #2

I don't have a ton to say here, the article says it all really. But this also reflects my experience when developing with Scala and although I love the language and its brevity, I went back to Java because I hated the Scala toolchain, sbt, dependency issues, etc. Basically, I like the language in isolation but the overall experience was horrible.

Java has the same dependency issues? I vividly remember spending days on jars shading in Maven. Basically, a single approach that would solve this, irrespective of the language, would be isolating dependency trees of every library from each other, essentially duplicating the code of many common libraries in RAM (like Docker, but for libraries inside the same process). There's an option to do that in Maven, but it's n…

Post by seer-zig » Wed, Sep 14, 2022, 7:20 AM UTC

cube2222 wrote: post #194

kaba0 wrote: post #176

Earlier quoted context omitted.

Error handling and Go doesn’t mix well.

That's a matter of opinion. Many, me included, very much like the current, very explicit, approach. I understand why people who like monadic constructs don't like it though.