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

Scala 2.12.0 is now available

scala-lang.org

Post reply on HN
Print view View original

61–70 of 78 posts

Re: Scala 2.12.0 is now available

#61

Post by whateveracct »

lacampbell wrote: post #59

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

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.

Re: Scala 2.12.0 is now available

#62

Post by whateveracct »

ThePawnBreak wrote: post #14

Does anyone have any tips for learning Scala? I want to learn the language, it looks very interesting, and I have some familiarity with Scheme, Haskell and Ocaml, but I just don't know how to start. What should I read? What should I build?

If you're familiar with Haskell, you can probably dive into the "Typelevel Scala" approach. Once you learn how to do ADTs and typeclasses in Scala, you'll be able to make use of scalaz or cats effectively and feel relatively at home.

Re: Scala 2.12.0 is now available

#63

Post by dvlsg »

zephyri wrote: post #55
amelius wrote: post #35

Offtopic. Does anybody know of a practical imperative language in which promises are implicit? Often, when writing software, it happens that deeply nested functions suddenly have to return a promise instead of a direct value, and this forces the programmer to rewrite all the callers of that function into dealing with promises, which of course sucks. So it would be better if the programming language would do that rewr…

Go. It's what I love most about it. If something needs to wait for a response, e.g., a database call, your goroutine just pauses without blocking any other goroutine, even if you're running only a single process. You never have to return a promise. Contrast that with JavaScript where you're forced to use promises/async await. If you don't, you block the whole event loop. See also "What Color is Your Function": http:/…

I don't understand the claim that not using async / await and promises with js will block the event loop. Can you elaborate on what you mean?

Re: Scala 2.12.0 is now available

#64

Post by zephyri »

dvlsg wrote: post #63
zephyri wrote: post #55

Earlier quoted context omitted.

Go. It's what I love most about it. If something needs to wait for a response, e.g., a database call, your goroutine just pauses without blocking any other goroutine, even if you're running only a single process. You never have to return a promise. Contrast that with JavaScript where you're forced to use promises/async await. If you don't, you block the whole event loop. See also "What Color is Your Function": http:/…

I don't understand the claim that not using async / await and promises with js will block the event loop. Can you elaborate on what you mean?

I mean that, in an event loop, synchronous code is blocking code. If you could synchronously run a database query in Node, nothing else would be allowed to execute while you waited. That's why you have to use asynchronous callbacks/promises/generators/await whatever.

In Go I can make an apparently synchronous database query without blocking anything except the calling code.

Re: Scala 2.12.0 is now available

#65

Post by paulddraper »

lmm wrote: post #50
paulddraper wrote: post #41

Earlier quoted context omitted.

The last announced plan was to conclude 2.11.x with 2.11.9 (currently at 2.11.8). Maybe we'll see longer support for people who don't migrate (heck, SBT still uses 2.10.x), but justifying it by Java version is weird. If you're okay with using old Java versions, it's not much of a stretch to say you'll be okay with old Scala versions.

> If you're okay with using old Java versions, it's not much of a stretch to say you'll be okay with old Scala versions. No, because Scala doesn't offer forward binary or source compatibility. Maintainers of widely-used Java libraries can write and build for Java 6 and be confident their libraries will be usable by everyone (on Android and off). Maintainers of widely-used Scala libraries have no such option (for now…

> there's no guarantee that such a subset will be maintained

There's no guarantee about Java either. This class compiles with Java 7, but not with Java 8:

    class SampleClass {
        static class Baz {
            public static java.util.List> sampleMethod(Baz param) {
                return null;
            }
        }
 
        private static void bar(Baz arg) {
            Baz element = Baz.sampleMethod(arg).get(0);
        }
    }
Like Java or any other good software, Scala will try to maintain backwards compatibility (particularly source compatibility).

Re: Scala 2.12.0 is now available

#66

Post by GFK_of_xmaspast »

sjrd wrote: post #32
rahilb wrote: post #31

Earlier quoted context omitted.

>continued effort regarding Scala.js It's a shame the documentation is so poor for scalajs.

Could you elaborate on specific points that would require improvements? Most feedback I receive says it's good. If those of you who think it's poor only tell us "it's poor", there is nothing we can do to improve it.

I haven't looked at scala.js, but as a new-ish scala user I thought the kick-off post in that mailing list drama from last month summarized my thoughts pretty well.

Re: Scala 2.12.0 is now available

#67

Post by sjrd »

estefan wrote: post #47
sjrd wrote: post #32

Earlier quoted context omitted.

Could you elaborate on specific points that would require improvements? Most feedback I receive says it's good. If those of you who think it's poor only tell us "it's poor", there is nothing we can do to improve it.

I'm about to start using it again, but one point: the installation page[1] doesn't actually tell you how to install it... [1] http://www.scala-js.org/doc/

Hum, that's because you don't actually need to install Scala.js per se. sbt will download and use it for your project automatically.

I agree that the way it is presented on that page is confusing, though. I'll add some explanation about that when I get back from conferences.

Thanks for the feedback!

Re: Scala 2.12.0 is now available

#68

Post by sjrd »

GFK_of_xmaspast wrote: post #66
sjrd wrote: post #32

Earlier quoted context omitted.

Could you elaborate on specific points that would require improvements? Most feedback I receive says it's good. If those of you who think it's poor only tell us "it's poor", there is nothing we can do to improve it.

I haven't looked at scala.js, but as a new-ish scala user I thought the kick-off post in that mailing list drama from last month summarized my thoughts pretty well.

I won't argue about the documentation of Scala in general. But a post in the thread you are referring to was specifically mentioning Scala.js as not having the same issues.

Re: Scala 2.12.0 is now available

#69

Post by lmm »

paulddraper wrote: post #65
lmm wrote: post #50

Earlier quoted context omitted.

> If you're okay with using old Java versions, it's not much of a stretch to say you'll be okay with old Scala versions. No, because Scala doesn't offer forward binary or source compatibility. Maintainers of widely-used Java libraries can write and build for Java 6 and be confident their libraries will be usable by everyone (on Android and off). Maintainers of widely-used Scala libraries have no such option (for now…

> there's no guarantee that such a subset will be maintained There's no guarantee about Java either. This class compiles with Java 7, but not with Java 8: class SampleClass { static class Baz { public static java.util.List > sampleMethod(Baz param) { return null; } } private static void bar(Baz arg) { Baz element = Baz.sampleMethod(arg).get(0); } } Like Java or any other good software, Scala will try to maintain back…

> There's no guarantee about Java either. This class compiles with Java 7, but not with Java 8:

Ok, but you can compile it with the newer compiler by passing -source 1.7, right? And you can call into it from 1.8 code?

Re: Scala 2.12.0 is now available

#70

Post by lacampbell »

whateveracct wrote: post #61
lacampbell wrote: post #59

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

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 troub…

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.

Post reply on HN