4 ms·

I desperately want to like Scala. An expressive, concise pure OO Lang with static typing designed for a REPL is something I often wish existed. But every time I

I desperately want to like Scala. An expressive, concise pure OO Lang with static typing designed for a REPL is something I often wish existed. But every time I've used it I've come away disappointed with the execution. A bewildering standard library, a type system that crashes, glacial compilation, and the sbt repl leaks memory every time you type a command. I'll try it again, as I believe it's an excellent idea. Having objects so fine grained allows it to emulate functional programming really well. But I suspect I'll be disappointed again.

whateveracct 10y ago
When was the last time you tried Scala? I just left a Scala/scalaz job after around 2 years and everyone I worked with was extremely happy with the language. We gradually moved to a more Haskell-like approach to programming, which I feel Scala is more capable of than any other mature general-purpose language (except Haskell ofc) I'll address your issues one-by-one. > A bewildering standard library What about it troubled you? The main things I use in the stdlib are collections (CanBuildFrom aside, they're pretty solid), Future (although I prefer scalaz.concurrent.Task), and Option. In 2.12, Either is finally usable too! > a type system that crashes I've only run into a single type checker crash (NPE) in my 2 years. Aside from that, the type system has become my best friend. I write implicit-heavy code that leans on scalaz and shapeless too. > glacial compilation A full compile of our ~250 file (idr loc) service took like 2 minutes. But I pretty much never did full compiles. Sbt incremental compilation of a handful of files would take a coupe seconds. This makes the feedback loop of running tests/the repl pretty quick, and unlike with other fast-feedback-loop languages (like Ruby), I get really strong checks from the compiler in each loop. > the sbt repl leaks memory every time you type a command. Are you referring to the Scala repl (sbt console) or the sbt build tool prompt? It's true that the repl leaks memory but that's by design: every repl evaluation is stored in a variable (res0, res1, etc). I've run into memory trouble once or twice when loading large production data into the repl, which would store it in one of these variables. I worked around it by loading it but then in a block extracting what I needed. This smaller data would in turn be stored in resX.
- lacampbell 10y ago
  My memory is fuzzy on all of the above, so this all just represents the impression it left on me. > When was the last time you tried Scala? Around 2 years ago, as well. It showed so much promise but I ran into so many problems using it day to day. > What about it troubled you? The main things I use in the stdlib are collections (CanBuildFrom aside, they're pretty solid), Future (although I prefer scalaz.concurrent.Task), and Option. In 2.12, Either is finally usable too! Unreadable type signatures, mainly. And the collection hierarchy was rather bewildering. > I've only run into a single type checker crash (NPE) in my 2 years. I wasn't complaining about NPEs. IIRC Scalas type system is actually turing complete. I ran into it trying to do fairly mundane things - it crashed when I was writing a simple interepter I think. > A full compile of our ~250 file (idr loc) service took like 2 minutes. But I pretty much never did full compiles. Sbt incremental compilation of a handful of files would take a coupe seconds. This makes the feedback loop of running tests/the repl pretty quick, and unlike with other fast-feedback-loop languages (like Ruby), I get really strong checks from the compiler in each loop. True. SBT helps a lot by being incremental. It's absolutely glacial compared to Java where you don't even notice it, but a slow incremental compile system is still better than all but the fastest batch compilers. So I agree with you there. Except... > It's true that the repl leaks memory but that's by design: every repl evaluation is stored in a variable (res0, res1, etc). I've run into memory trouble once or twice when loading large production data into the repl, which would store it in one of these variables. I realise that the memory usage of a running repl is bound to grow as you enter in commands. But I've never seen something grow as rapidly as the sbt console. I'd have to restart it every 3-4 times I'd reload the small file I was working on, because I simply can't spare a GB of memory in order to run an interpreter. I never had any issues with say ruby, even when ruby was much slower, and my personal machine was abysmal (less than 1gb of ram). Maybe it's not so much a memory leak as just very sloppy use of memory.

whateveracct 10y ago

When was the last time you tried Scala? I just left a Scala/scalaz job after around 2 years and everyone I worked with was extremely happy with the language. We gradually moved to a more Haskell-like approach to programming, which I feel Scala is more capable of than any other mature general-purpose language (except Haskell ofc) I'll address your issues one-by-one. > A bewildering standard library What about it troubled you? The main things I use in the stdlib are collections (CanBuildFrom aside, they're pretty solid), Future (although I prefer scalaz.concurrent.Task), and Option. In 2.12, Either is finally usable too! > a type system that crashes I've only run into a single type checker crash (NPE) in my 2 years. Aside from that, the type system has become my best friend. I write implicit-heavy code that leans on scalaz and shapeless too. > glacial compilation A full compile of our ~250 file (idr loc) service took like 2 minutes. But I pretty much never did full compiles. Sbt incremental compilation of a handful of files would take a coupe seconds. This makes the feedback loop of running tests/the repl pretty quick, and unlike with other fast-feedback-loop languages (like Ruby), I get really strong checks from the compiler in each loop. > the sbt repl leaks memory every time you type a command. Are you referring to the Scala repl (sbt console) or the sbt build tool prompt? It's true that the repl leaks memory but that's by design: every repl evaluation is stored in a variable (res0, res1, etc). I've run into memory trouble once or twice when loading large production data into the repl, which would store it in one of these variables. I worked around it by loading it but then in a block extracting what I needed. This smaller data would in turn be stored in resX.

lacampbell 10y ago
My memory is fuzzy on all of the above, so this all just represents the impression it left on me. > When was the last time you tried Scala? Around 2 years ago, as well. It showed so much promise but I ran into so many problems using it day to day. > What about it troubled you? The main things I use in the stdlib are collections (CanBuildFrom aside, they're pretty solid), Future (although I prefer scalaz.concurrent.Task), and Option. In 2.12, Either is finally usable too! Unreadable type signatures, mainly. And the collection hierarchy was rather bewildering. > I've only run into a single type checker crash (NPE) in my 2 years. I wasn't complaining about NPEs. IIRC Scalas type system is actually turing complete. I ran into it trying to do fairly mundane things - it crashed when I was writing a simple interepter I think. > A full compile of our ~250 file (idr loc) service took like 2 minutes. But I pretty much never did full compiles. Sbt incremental compilation of a handful of files would take a coupe seconds. This makes the feedback loop of running tests/the repl pretty quick, and unlike with other fast-feedback-loop languages (like Ruby), I get really strong checks from the compiler in each loop. True. SBT helps a lot by being incremental. It's absolutely glacial compared to Java where you don't even notice it, but a slow incremental compile system is still better than all but the fastest batch compilers. So I agree with you there. Except... > It's true that the repl leaks memory but that's by design: every repl evaluation is stored in a variable (res0, res1, etc). I've run into memory trouble once or twice when loading large production data into the repl, which would store it in one of these variables. I realise that the memory usage of a running repl is bound to grow as you enter in commands. But I've never seen something grow as rapidly as the sbt console. I'd have to restart it every 3-4 times I'd reload the small file I was working on, because I simply can't spare a GB of memory in order to run an interpreter. I never had any issues with say ruby, even when ruby was much slower, and my personal machine was abysmal (less than 1gb of ram). Maybe it's not so much a memory leak as just very sloppy use of memory.