dotty VS Mill

> 1) The language is too unstable

Thankfully not anymore. They got their act together and have been maintaining compatibility since Scala 3.0.0 has been released in May 2021, which is almost 4 years and counting.

https://github.com/scala/scala3/releases/tag/3.0.0

Scala 3.x is to remain compatible for the whole 3.x series (think of semantic versioning). There's no Scala 4 (breaking with Scala 3) in sight.

Also, Scala 3 and Scala 2.13 JARs are also compatible with each other, which helped with the transition.

> 2) The tooling around it is not the best

sbt may not be good. But Mill is much better than either Maven or Gradle. Especially Gradle. Bleep is also promising.

Scalafmt is widely used and liked. Scalafix -- the linter/fixer -- is used a bit less, but still of a good quality.

Dotty? Was it still the name later?

http://dotty.epfl.ch/

I think this might be related to this issue.

You can look (and EPFL collect feedback) about EPFL implementation of async/await: https://github.com/lampepfl/async. Also you can look at dotty ticket about this: https://github.com/lampepfl/dotty/pull/16739

The reason I’m not currently an opaque type user as they do not play well with the tagless final style we use, though I am patiently awaiting some attention on my bug report: https://github.com/lampepfl/dotty/issues/17281

Links: - https://dotty.epfl.ch/ - https://scala-native.org/en/stable/ - https://www.scala-js.org/ - https://typelevel.org/ - https://zio.dev/ - https://github.com/scala-native/scala-native/pull/3120 - https://github.com/lampepfl/dotty/pull/16517 - https://dotty.epfl.ch/docs/reference/experimental/index.html - https://scala-cli.virtuslab.org/ - https://scalameta.org/metals/ - https://docs.scala-lang.org/scala3/guides/migration/compatibility-intro.html - https://www.scala-lang.org/blog/2023/04/18/faster-scalajs-development-with-frontend-tooling.html - https://www.scala-lang.org/blog/2022/08/17/long-term-compatibility-plans.html

Scala Native has much more control on how the Scala AST is compiled, and can easier workaround platform limitations, eg. lazy vals in Scala 3 required reflection config for Native Image (see this and that), while in Scala Native we could mitigate problems with unsupported usage inside in other ways within the compiler plugin.

By the way, you might be interested in this recent PR which overhauls the scala 3 macro docs: https://github.com/lampepfl/dotty/pull/17060.

For example, this issue (https://github.com/lampepfl/dotty/issues/12840) was blocking the migration, it was reported more than a year ago and the fix was finally released a month ago (https://github.com/lampepfl/dotty/releases/tag/3.3.0-RC2).

A big problem with Bazel not mentioned here is the complexity. It's just really hard for many people to grasp, and adopting Bazel at the two places I worked was a ~10 person-year effort for the rollout with ongoing maintenance after. That's a lot of effort!

IMO Bazel has a lot of good ideas to it: hierarchical graph-based builds, pure hermetic build steps, and so on. Especially at the time, these were novel ideas. But in Bazel they are buried behind a sea of other concepts that may not be so critical: `query` vs `aquery` vs `cquery`, action-graph vs target-graph, providers vs outputs, etc. Some of these are necessary for ultra-large-scale builds, some are compromises due to legacy, but for the vast majority of non-Google-scale companies there may be a better way.

But I'm hoping the next generation of build tools can simplify things enough that you don't need a person-decade of engineering work to adopt it. My own OSS project Mill (https://mill-build.org/) is one attempt in that direction, by re-using ideas from functional and object-oriented programming to hopefully make build graphs easier to describe and work with

For some reason everyone wants to talk about Monads, but really the other types here are just as interesting. For example, Applicatives are less dynamic than Monads in that you can't `flatMap`/`bind` to decide on the "next" thing to evaluate based on the previous value, but in exchange you get a "static" tree (or graph) of Applicatives that lends itself much better to static analysis, optimization, parallelism, and so on.

For example, Haxl (https://github.com/facebook/Haxl) uses this to optimize and parallelise remote data fetching, which is hard to do with Monads since those are inherently sequential due to the nature of `flatMap`/`bind`. My own Mill build tool (https://mill-build.org/) uses an applicative structure for your build so we can materialize the entire build graph up front and choose how to parallelize it, query it, or otherwise manipulate it before we actually start evaluating the individual steps

Monads seem to have this strange aura around them that attracts certain kinds of personalities, but really they're just one abstraction in a whole toolkit of useful abstractions, and there are many cases where Applicative or some other construct are much more suited

This might be a bit of a shameless plug, but because you ask :)

Regarding no sbt, I would highly recommend to have a look at the mill build tool https://mill-build.org. I personally find it very pleasant to use as a replacement for sbt, mostly because of the following points:

- it uses regular Scala code to define a build

In most build tools, caching is opt in, so most things dont get cached and instead are wastefully recomputed. In Bazel caching is the default so everything is cached. Even tests are cached so if you run a test twice on the same code, the second time it is skipped

- Dependency bazed test selection: You can use bazel query to determine the possible targets and tests affected by a code change, allowing you to trivially set up CI to only run tests downstream of a PR diff and skip unrelated ones

- Automatic sandboxing of your build steps in CGroup/NS containers, to ensure your build steps do not make use of un-declared files.

- At my last job we extended these cgroups to limit CPU/Memory usage as well, which eliminates the noisy neigjbour problem and ensures a build step or test gets the same compute footprint whether run alone during development or in parallel on a CI worker

- Built in support for seamless shared caches (e.g. I compile something on my laptop, you download it to your laptop for usage)

- Built in support for shared compute clusters (e.g. I compile stuff and it automatically happens in the cloud on 96 core machines)

- Support for deep integration between multiple languages (e.g. building a Go binary and Rust libeary which are both used in a Python binary, which is then tested using a Bash script)

If you never hit these needs, you don't need Bazel. If you do hit these needs, most other build tools simply do not cut it. We're trying to support some of these use cases and provide an alternative in https://mill-build.org, but Bazel really is a high bar to reach in terms of features that support latge monorepos

Starlark is definitely a mixed experience IMO.

On one hand, having a "hermetic" subset of Python is nice. You can be sure your starlark codebase isn't going to be making network calls or reading files or shelling out to subprocesses and all that. The fact that it is hermetic does help make things reproducible and deterministic, and enables paralleization and caching and other things

On the other hand, a large Starlark codebase is a large Python codebase, and large Python codebases are imperative, untyped, and can get messy even without all the things mentioned above. Even though your Starlark is pure and deterministic, it still easily ends up a rats nest of sphagetti.

For https://mill-build.org we went the opposite route: not enforcing purity, but using a language with strong types and a strong functional bent to it. So far it's been working out OK, but it remains to be seen how well it scales to ever larger and more complex build setups

Author here. Unfortunately this is because my own experience with Gradle is not up to date; I've only lived in the Gradle Groovy world! If anyone is interested in helping out, I have a 1500USD bounty on porting a gradle.kts build to Mill, so we can do a fair up-to-date comparison https://github.com/com-lihaoyi/mill/issues/3670

https://mill-build.org/ you'll need to know some Scala

I had filed a GitHub ticket, but it was closed as "out of scope". I'm not sure why the maintainers insisted on perpetuating the ambiguity, and would like to know your opinion about the following. None of the references above answer these very basic and very important questions.

It was my case, but https://github.com/com-lihaoyi/mill made my life easier