Hacker News Reader

Comment by dsacco | Hacker News Reader

This post is very fortuitous for me. I've been looking to learn a functional language and I had more or less narrowed my options to Haskell, OCaml and Scala. I liked the breakdown between these languages and the resources.

Can anyone who programs in Haskell or OCaml regularly tell me the current state of standard and third party library support? I'm very attracted to Scala because it has JVM support, which sounds fantastic for overall ecosystem maturity.

That said, I come from a C++ and Python background, so do I need to know Java well before learning Scala?

View on HN

I can recommend Scala:

- It is mature and rock-solid, but still manages to evolve, fix issues and simplify/remove features. Most other languages are purely additive, meaning you will have to carry on all the baggage since the languages' inception.

- It is a language which is interested in identifying the best way to solve common programming issues and spares you with all this ideological "OOP/FP is bad" bullshit.

- It has the largest ecosystem (plus it can use all of Java's, too).

- It has the best tooling.

- It has the largest community.

- It has some great learning resources, like the three (or four?) Coursera courses starting in a few weeks.

- Its JavaScript backend is stable and production-ready, Scala-Native is being worked on.

> That said, I come from a C++ and Python background, so do I need to know Java well before learning Scala?

Java knowledge might reduce the amount of learning (as many Java things like the JVM also apply to Scala), but isn't really necessary. You will be fine.

I am so freaking excited about Scala Native. I haven't been so genuinely excited and enthusiastic about something for such a long time, but Scala Native is so awesome.

I feel like turning Scala into a cross-platform language is the best idea possible. I'd love to see Scala someday be able to just dump out WebAssembly, or JVM bytecode, or LLVM IR, or whatever the next "hip" format is, while keeping the language the same.

I also find it shocking how hard people are pushing Typescript when Scala.js exists. Why would you ever subject yourself to TS?!?!

The size of the Javascript generated by Scala.js alone makes it a non starter for serious projects.

Look at here: https://www.scala-js.org/

"The generated JavaScript is both fast and small, starting from 45kB gzipped for a full application." - 45kB... jQuery is ~80kB.

jQuery gzipped and minified is 25kb. You're comparing raw to compressed.

Yeah, these tens of kilobytes of JS next to those ten badly compressed 600kB jpgs are really killing it.

this isn't a fair comparison. It fails to account for what happens after the files are downloaded, which is where overall js code size has an outsized effect.

I think people have been including jQuery just fine for the last decade.

Yes, but jquery is much smaller than an empty scala.js app. jquery is about 25kb gzipped and minified (the other comment used the raw size) whereas scala js is 45kb for an empty application.

TBH, You don't use scala.js to write hello world apps. I'm much more curious how Scala.js handles a 100Kloc app, but I haven't seen any data on that.

Cedric, how does a 45KB js file make Scala a non-starter?

What is Scala native? Is there a Scala that doesn't rely on the JVM for hosting?

http://www.scala-native.org/

I am not sure about tooling. Do you consider SBT part of tooling? In that case I do not understand how can you say best. SBT is good enough at its finest.

IDEs, editors, SBT, ScalaFmt, Mima, WartRemover, etc.

Yeah, build tools are usually terrible. Being "good enough" is enough for SBT to beat the other ones though.

(Best incremental compilation, fast artifact resolution, reliable dependency management, versioning support, fastest to-Android compilation, broadest plugin support, interactive REPL and project console ...)

Once you have had real Hindley-Milner Scala feels painfully primitive. Just go straight to OCaml.

I'm afraid I disagree. I went from Ocaml to Scala. While full type inference is nice, it's a minor issue in practise, but the vastly bigger library ecosystem that Scala has (due to being a JVM language) isn't. Object orientation also works better in Scala than Ocaml.

Can you expand on this for someone who is not familiar with Hindley-Milner typing?

Hindley-Milner means that you – unlike Scala – don't need to provide any type annotations at all as they can all be inferred.

This comes at a steep price, as HM-inferable typesystems are very limited, and most languages have in fact a typesystem that might be based on what HM can infer, but have extensions that require type annotations.

In the end Scala's requirement to annotate input parameters is not a big deal, as this only enforces what Haskell/Ocaml/... consider to be best practice anyway.

> In the end Scala's requirement to annotate input parameters is not a big deal, as this only enforces what Haskell/Ocaml/... consider to be best practice anyway.

It's a huge deal. I always write type signatures once I know what they are, but a lot of the time I get the compiler to infer them for me which saves significant headaches.

I'm afraid you have it backwards. Scala's type inference comes at a slight cost (you have to annotate parameters), but it enables a much more powerful type system than even HM allows for.

Or go to F# and enjoy the vast universe of .NET.

To be fair Scala does have access to the Java ecosystem

Ocaml has opam, a package manager, with currently 1227 packages in it. https://opam.ocaml.org/ The standard library of ocaml is quite basic, so usually, you use either Core (https://github.com/janestreet/core) or Batteries Included (https://github.com/ocaml-batteries-team/batteries-included) I personnally prefer Batteries because it tries to stay compatible with the standard library.

I've been writing Haskell professionally full-time since 2010. Before I started pursuing Haskell I looked into Scala, but it seems to be trying to embrace too many paradigms, which has resulted in a gigantic unwieldy language. In the 6 years that I've been using it professionally the Haskell ecosystem has matured tremendously. Obviously the third party library support can't be as good as popular languages like Ruby, Python, etc simply because of manpower, but I find that these days there is an open source package for just about everything I need. Furthermore, due to Haskell's purity and strong type system it is MUCH more likely that these libraries will work. It is also usually quite easy to make improvements when needed.

If you're really interested in learning a language for itself, rather than using it for some practical goal, libraries that are "just" bindings to some other language with radically different semantics don't really count as a positive. They generally end up non-native and a real pain to try to write "language-A in language-B", unless someone has taken the time to write a native-idiom wrapper around them, which is pretty uncommon. So for educational purposes, I'd only look at the pure-Scala libraries rather than "the JVM ecosystem". Or, similarly for Haskell, Haskell still AFAIK does't have a great binding to native QT or GTK or any other really good desktop toolkit. There are bindings, but you're writing C in Haskell at that point, which is definitely a pain, and not a great way to learn the language.

If you want to do practical things with the language, by all means count the bindings as an asset. It's still better to have a foreign-library binding to some capability than no capability at all, and it's not hard to imagine that using another language for some reason, even with the cost of the foreign-idiom binding, is still net cost/benefit positive.

I've spent some time with both Haskell and Scala.

Haskell's big pluses are purity and rigor. Most functions can't affect external state; they can only return results. Haskell also has strict typing, which is great for catching mistakes up front, and takes most of the pain out of using it through really great type inference. Unfortunately the community around Haskell is very small, so if you use it for a project larger than one person you could run into hiring problems.

I wrote some more about the pluses and minuses of Haskell here: http://short-sharp.blogspot.ca/2016/06/should-you-use-haskel...

Scala's big advantage is that it works well with legacy code in Java. Unfortunately it straddles the boundary of OO and FP, and making both programming models work requires a large and complicated language. I'd prefer something simpler.

If we were to take another swing at FP, I'd look hard at Scheme and in particular at the Racket system. The big plus of Scheme is a certain elegance, which is very appealing. And lots of people have learned Scheme in school.

I'd prefer something simpler.

Consider Kotlin: https://kotlinlang.org/docs/reference/comparison-to-scala.ht...

I didn't have large problems with Haskell library availability until lately. I was attempting to see what some code from work would look like from work. It used:

Mssql, Cassandra, CSV, and MySQL

MySQL and CSV were no problem. The Cassandra bindings were bitrotted and I had to do a good amount of work fixing the Cassandra dependency and the thrift dependency it has. Mssql bindings through hs-odbc have an allocation error I haven't had the time or energy to figure out.

If I were using Haskell in production and not having mssql was a showstopper, I'd need to take the time to fix this library to with fix my immediate case and then continue maintaining it.

I found that Haskell Library support seems to be stronger in the technically Superior Technologies Department. For instance postgres support is quite a bit better than MySQL support.

It makes total sense that the Haskell Community would put more work into supporting technically Superior Solutions using their technically Superior language, but I fear that's biting off more than you can chew.

At home for instance I've been struggling with Linux issues rather than putting time into my side project. It would probably be a better economic choice to buy something with more seamless Hardware support like a Mac, and then be bleeding edge with my side project using Haskell.

Point being, if every part of your life is bleeding edge you'll just end up bloody and never going anywhere.

See my post history for many of the positives of Haskell. The above post only highlighted the negative.

There's a very good summary of the Haskell ecosystem here: https://github.com/Gabriel439/post-rfc/blob/master/sotu.md

We write OCaml professionally. In case you find it useful to browse real world, battle-tested code, here's our main repo (there are others, but this is the largest): https://github.com/libguestfs/libguestfs There is an introduction/overview of the source here: http://libguestfs.org/guestfs-hacking.1.html

Heh, libguestfs helped me out a couple of years ago.. Never realised it was OCaml. Nice! (Noobing myself through OCaml & F# right now, so this will be an interesting reference to study :) )

It's a mix. The library is C, pure and simple. But we use OCaml to generate a lot of that C - which I think is a very under-used but powerful technique giving you the best of both worlds. We also use OCaml to generate programming language bindings to the C API, so that when a new API is added you simply have to recompile and the API is available in every supported language (about a dozen so far).

However the main use of OCaml is in the higher-level utilities, for example virt-v2v (https://github.com/libguestfs/libguestfs/tree/master/v2v) and virt-builder (https://github.com/libguestfs/libguestfs/tree/master/builder) are substantial OCaml programs.

Indeed, yes, having a quick look at the repo I now see the point you make. Thank you for the pointers to the H/L utils - therein lies more interest :)

Scala's JVM support can get rough. Many a developer had gone down the road of finding a library like a db driver and using it in Scala. This works fine until you deadlock your production system because your execution context ran out of threads because your db driver blocks.

So yes, while you can use Java libraries you often have to jump through a lot of hoops.

Scala makes it really easy to call a blocking function using a future with a configurable execution context. I don't see why one would run out of threads. Currently we use the Typesafe supported Slick library but the mechanism is the same.

Maybe I'm missing your point but as a professional Scala programmer I've never run into a problem with Jvm or Java integration

I've done it naively with a mongo driver. Just wrapping it in a future doesn't cut it, as you said you have to configure a separate execution context and even that context is finite. Or use a blocking future which has other implications.

It's more a point against the "strictly better than Java, use the bits you want as you you go" point in the article. You have to understand Scala's execution model and make sure you are mixing the paradigms properly, because it's fully of leaky abstractions.

It's also a real pain to call Scala code from Java, which makes blending Java and Scala code in a project, or adding Scala code to an existing Java project, much less attractive.

Knowing Java won't help you much in learning Scala. It's the functional programming parts that will trip you up if you haven't done that before, and this is the most valuable part to learn. I use Scala every day, and it was easy to learn; but I suspect that was because I did a lot of functional programming before that.

But ins't one of the nice parts about Scala that you can use it strictly for OO programming, use it for strictly for FP or both?

Yes, that's definitely one of the great things about Scala.

If you come from an OO background, I recommend to avoid using Scala's functional features at the start. Just treat Scala as a nice, conventional OO language until you are comfortable with the language. Then, slowly use some of the more advanced features. Case classes and pattern matching are easy and powerful next steps.

Enjoy the ride!

This is true, I was from an OO background and Scala was my first functional language. I had to put it aside for a while and learn Haskell to grok the functional side of Scala. The ML world can be a little alien if you're new to it, and I found it useful to learn from a purely functional language first and then go back to Scala with a better understanding of how it fits OO and ML together.

I had zero background in Java, and I'm a very happy Scala developer for about two years now (still at the beginner level, though).

I'd say not knowing Java the language isn't a big deal. Also not a big deal, but certainly a point to consider, is Java the ecosystem. I can imagine Java pros bringing their knowledge regarding the JVM, threads, and other stuff, that's certainly a plus.

I would recommend Elixir or Clojure over Scala. In my opinion, Scala and F# suffer from supporting multiple programming paradigms, which means that people tend to fall back on the procedural or object-oriented programming they know, rather than learning how to do things the right way, functionally speaking. That has been my experience with them, anyway.

Answering your second question:

Since you have experience with a statically typed language, you'll be fine with little no to Java knowledge.

The huge difference between Haskell and the other two (that isn't in libraries) is that Haskell has controlled side effects, whereas side effects are uncontrolled in the other two (and virtually all other languages...)

That, at least to me, is way more interesting/important than libraries, which can always be ported or otherwise interfaced with.

Some would argue that not knowing Java would be a benefit to learning scala. It depends though, some scala codebases are very java-y and others are very un-java-y

Reply on news.ycombinator.com