News for hackers. Stuff that matters.
Re:Scala projects are difficult to maintain by nullifidian on Monday March 22, 2021 @10:09AM (#26540979)
Does rust have this issue? Anyone with experience?
Re:Scala projects are difficult to maintain by terhechte on Monday March 22, 2021 @10:30AM (#26541330)
I did a lot of Scala some years ago and also ended up in sort of a ragequit. Nowadays I'm mostly doing Rust or Swift. Rust, of course, has a steep learning curve due to the lifetime & borrowing system. However, the errors are usually very easy to understand. In the rare case where they aren't, it is easy enough to figure out what's wrong by searching for the error message. One of the Scala issues I had was that the error was the compiler throwing up a stream of sigils because some generic requirement didn't hold and it was very very difficult to search for, let alone understand what was wrong. Granted, it's been almost 6 years since I stopped using Scala. The experience that broke me back then was trying to use Slick, a typesafe Scala ORM. I forgot the details but I remember it was astonishingly hard to use back then and I couldn't for the life of me tell what was wrong because the compiler error message was so cryptic.
Re:Scala projects are difficult to maintain by AheadOfTime295 on Monday March 22, 2021 @12:51PM (#26543340)
The maintainer of Slick was in the last round of layoffs at Lightbend. Not sure who maintains Slick these days.

https://news.ycombinator.com/item?id=22854494

Re:Scala projects are difficult to maintain by AzzieElbab on Monday March 22, 2021 @10:52AM (#26541644)
Yeah slicks errors were terrifying back in the days. They fixed both slick and scala to simply tell you which implicits were missing
Re:Scala projects are difficult to maintain by thinkharderdev on Monday March 22, 2021 @10:47AM (#26541568)
Yeah, it has gotten tremendously better in the last couple years when it comes to cryptic compiler errors. But even then Slick was a particularly egregious example. I had many WTF moments using Slick a few years back.
Re:Scala projects are difficult to maintain by tormeh on Monday March 22, 2021 @10:11AM (#26541013)
I love Rust, but it always looks ugly.
Re:Scala projects are difficult to maintain by pornel on Monday March 22, 2021 @11:01AM (#26541806)
It's the semantics that counts.
Re:Scala projects are difficult to maintain by KingOfCoders on Monday March 22, 2021 @10:29AM (#26541318)
Wrote 100k+ lines of Scala, now write Rust. It's very different, Rust has much more noise (but I like Rust as a language a lot) and doesn't look beautiful.
Re:Scala projects are difficult to maintain by tgv on Monday March 22, 2021 @11:08AM (#26541915)
In my little experience with rust, things can get ugly very quickly, but it depends very much on the task. I wrote a game server monitor, and a fairly extensive command line calculator in rust, and that code for all those looks quite fancy. I wrote a tool that converts a lexicon to a trie and one that can do error correction using that trie, and that has some quirks. I also tried porting an Earley parser from C, and that took a nasty turn, since it relies a lot on pointer sharing.

I have more experience writing in Go, and I think the code for all would look similar-ish. Go is a bit of a grey language, but it gets the job done without a lot of refactoring and restructuring.

Re:Scala projects are difficult to maintain by hota_mazi on Monday March 22, 2021 @12:56PM (#26543413)
Rust was a surprise to me. I didn't expect to like it (I'm a Kotlin person) but I ended up pretty happy with it overall.

I'm happy to pay the complexity tax associated with the borrow checker. You get outstanding performance and you usually don't need to dive deep into lifetimes to get some basic code running.

The language itself is reasonably pleasant but is missing some key features that really annoy me:

- No overloading

- No default parameters

- No named parameters

- Awkward constructor syntax which causes a lot of copy/pasting boiler plate

But overall, I'd say Rust is safely in my #2 spot, with Kotlin a bit ahead at #1.