A Tour of Scala VS scala-cli

Martin Odersky is just a very nice guy and I get the impression that he isn't keen on saying "no", which is how you end up with a language that allows you to use xml tags inline (no longer supported in Scala 3),

https://github.com/scala/scala-xml/wiki/Getting-started

The "opinionated" Scala are the Typelevel and Zio stacks, which are very cool.

The problem with the "better Java" approach is that although it has helped Scala's growth a lot, it has also made it susceptible to Kotlin. The Scala code that doesn't use the advanced type magic can be straightforwardly rewritten in Kotlin instead. Kotlin also stops your bored developers from building neat type abstractions that no one else understands.

People who use Scala only has a "better Java" can now use Kotlin has a "better "better Java"".

https://github.com/scala/scala-xml/releases is now published separately from the main language.

It defines a DSL for your build that looks roughly like Scala code. But… it’s not! And there is a confusing “resolution” system for build tasks/settings. It’s also slow as shit. See https://www.lihaoyi.com/post/SowhatswrongwithSBT.html for a comprehensive takedown. If you’re interested in just playing around with scala I would use

https://scala-cli.virtuslab.org

Or for larger projects, the thing the author of the linked article is plugging (mill).

Scala CLI has replaced the default runner since Scala 3.5, so you can effectively do `scala run`, `scala fmt`, and so on. On the Java side, I believe JBang provides a very similar developer experience.

Fundamentally it's hard to reconcile both worlds though. Building non-trivial multi-module projects on the JVM is inherently complex especially when you throw in multiple build targets, multiple toolchains, multiple platforms...

With simpler build tools (like in Go or Rust) you shift this complexity elsewhere, typically in a Makefile and/or a Docker/OCI based build pipeline, and these can get pretty complex too. Let alone distributed build tools like Bazel.

- https://scala-cli.virtuslab.org

- https://www.jbang.dev

First of all, the development of our data pipeline will not be based on SBT projects. We will use the Scala CLI, a command-line tool that allows compile, run, test and package Scala code. Based on the Scala CLI, we can develop Scala scripts in a very practical and fast way!

That has not much to do with the JVM. See Scala CLI[1] for instance, the developer experience is pretty similar to Cargo.

The thing is, with any non-trivial project, zero to hello world isn't a very useful metric. Gradle (and Maven, sbt, ...) do a lot more than Cargo, and their usage is primarily optimized for complex multi-modules projects.

[1] https://scala-cli.virtuslab.org

Scala CLI v1.0.5 was released. https://github.com/VirtusLab/scala-cli/releases/tag/v1.0.5 This includes:

The new official Scala build tool / compiler front end (scala-cli) is amazing,

https://scala-cli.virtuslab.org/

The thing that really struck me after years of python is how it lets you out dependencies directly in a comment on top of a script and it will download and run with them automatically, without poisoning any system settings. It's so simple!