i’m going to start a new project at work in upcoming months, so i have thoughts about giving some typed fp language a try in it.I’ve stopped at Scala and Ocaml, so can anyone with experience chime in and compare the two? I’m interested in:
- total cost of ownership
- developer onboarding and dx
- ecosystem( is ocaml’s ecosystem really that bad?)
- tooling(build systems, editor integration, testing, monitoring, etc.)
- expresiveness and how it scales in terms of teams of devs with varying expertise
- how runtime characteristics of the two compare(resource usage and predictability of runtime perf)
I will be very thankful for any answers
1 Like
I can’t give you a comprehensive analysis, but from my experience it depends a lot on what you are already familiar with.
I learned and worked with Scala for a while about a decade ago. It was a natural and straightforward process because I was already a professional Java programmer so I understood the JVM, and the JVM ecosystem, and because Scala can be used as a better Java as a starting point.
More recently I have started using OCaml. It was a natural and straightforward process because I was already a professional Swift programmer, and so I was accustomed to working with a compiled language with no VM, and because Swift borrows heavily from OCaml in its type system.
In my experience the ecosystem is fine and improving rapidly. I use VSCode with the official plugin and it’s as good as anything else I’ve worked with.
The biggest obstacle for me was learning the different syntax. It’s easy to see this as a source of frustration, but having gone through it, I see it as having significant benefits, and I miss it when I work in Swift.
I will say that if you are experienced in the Java ecosystem, Scala will be productive for you much more quickly than OCaml.
If not, it’s a much more even comparison, and I would prefer OCaml.
8 Likes
Me - A few years of scala experience and just starting out with ocaml. I have also used haskell for a while.
I think you will have lower total cost of ownership with scala, as you will have to implement and maintain fewer bindings yourself. You might be able to get around this issue by using nodejs libraries from ocaml.
Developer onboarding might be slightly faster in ocaml as the scala language surface area is enormous (oo + fp, both used widely). Ocaml seems to stick with basic fp side of things in practice, even if oo is available. There will be some drag in developer onboarding in scala because sbt is awful compared to dune, so each new developer will have to either understand some obscure sbt plugins or syntax or one team member will become the sbt expert.
Scala has nice editor integration. Testing will be same in both. Monitoring will be better in scala because of tools targeting the jvm for other jvm languages. Ocaml build times are amazing. Scala has major issues there and it drags down your entire development cycle.
What happens with scala is it attracts two crowds - better java and haskell fans - and teams that mix those groups run into issues with code style and library preferences.
I think the most amazing part of scala is the cats ecosystem and competitors. It’s almost on par with haskell abstractions now.
5 Likes
What kind of project are you starting? What kind of functionality/integrations do you need?
simple streaming service, receive data from mq(probably kafka) parse it, transform it, throw out unneeded ones, route to other downstream consumers, maybe i’ll need a pg driver(caqti comes to the rescue)
Cool, that all sounds perfectly doable with OCaml. The opam package index is your friend, search for mq, kafka, and so on.
With Scala if you want specialized streaming support, there are several good libraries to choose from, especially fs2. In OCaml we have the similar streaming library: [ANN] First release of streaming
If you want an HTTP server check Dream — Tidy, feature-complete web framework , it’s still unpublished, but very promising. For HTTP client use opam - piaf –it’s modern, pure OCaml, and should integrate well with Dream.
3 Likes
as i understand preface is a ocaml variant of cats?
The cats ecosystem is much larger than just cats - Cats: Typelevel Ecosystem
1 Like
wow, thanks! Looks like scala for now, and reevaluate ocaml a year from now. Do you expect a lot of churn during scala 3 transition in libraries?
I would create a scala project with about 50 classes and uses a few libraries from cats, and time how long it takes for the project to compile. Try something similar with ocaml. I personally would choose ocaml for your scenario because I just don’t have any patience for scala’s build times.
I haven’t followed Scala closely this year. I seem to remember there was talk of the people who implement spark resist migrating quickly. The rest of ecosystem will probably migrate fast?
2 Likes
7s for a clean build(without deps, around 30s with deps) and 1-2s incremental, definitely slower than ocaml, but not too shabby
[info] compiling 29 Scala sources and 4 Java sources to /home/user/scala-http4s-realworld-example-app/target/scala-2.13/classes ...
[success] Total time: 7 s, completed Apr 23, 2021, 12:15:42 AM
2 Likes
I’m not sure your use case demands the Typelevel Ecosystem. OCaml can easily handle a simple service that processes a stream. If you have more specialized needs, we could go over those.
One more thing–I think no one mentioned anything about resource usage and runtime perf–with Scala you are dependent on the JVM and whatever GC and other tuning that you can do to get good runtime perf. Besides that, you’ll need to pack up an entire JVM to deploy your service. With OCaml you have really good consistent performance out of the box with almost no tuning and a single binary to deploy.
You could make an argument that the JVM’s (and Scala’s) support for parallelism is compelling for a high-performance streaming service. That’s a pretty good argument, but if the transformations are simple enough then most of the time will be spent in (streaming) I/O, which OCaml supports well with Lwt (promises). I suspect that you will get similar performance–but the only way to verify is to write a test implementation in both and check.
P.S.: yes, there will be a lot of churn as everyone scrambles to:
- Learn the new Scala 3 features and remove the deprecated ones
- Learn the new syntax and contend with the decision by different libraries to either move to the new one or stay with the old one
- Publish all these changes to Maven Central etc.
I think there will be periods of churn where people are waiting for libraries to be updated.
2 Likes