Coming from a java developer background, I cannot help but ask what is the need to rebuild the wheel when Maven appears to be an adequate build tool for enterprise environments? Is it just merely some type of academic exercise to need to create so many new build tools? Of course I am just learning Scala but so far have not seen the reason or need to use anything except maven and eclipse? What am I doing wrong ? Since so many in this forum seem to push sbt, now Mill and all those other things assciated with scala; i.e. play , … Is it possible that this is what is holding scala back from entering the mainstream more rapidly ?
I don’t think so; if anything, I would imagine that one might argue sbt is partly holding it back, thus things like Mill (though I don’t think I’d go that far). But why not maven? If you are doing exclusively jvm stuff and nothing too unusual, maven is great. But Scala isn’t just the JVM these days. Mill is meant to be a more natural, language based approach, and more flexible. See bazel for another build tool used in the industry with somewhat similar goals (but different priorities).
you are probably right. I just do not know anything about all those other build tools. I know there are many that use Gradle as a build tool now in the JVM environment , but not as many as maven yet. Gradle is yet another build tool that uses a language to do it work, Groovy. I guess part of the issue I have with the newer build tools is that they all require you to learn another language. And … I guess there is nothing wrong with learning another language. For some reason I feel that the build tool itself should be language agnostic. ( if that is the correct use of the word )
I agree about being language agnostic in the sense of possibly supporting many languages, but I feel that in the general sense, a build is a program itself, and benefits from a good general purpose language. This is the approach of CBT and Mill; I always felt Gradle was more like SBT: it uses a language, but also adds a lot of syntax and magic logic behind the scenes, further confusing things, IMO.
I find that Maven hits the balance between the simplicity of a language-agnostic solution and the power of a language-embracing situation exactly wrong. It is huge and complex, comparable to a language, yet it is inflexible and constrained, as if it were simple. The same was true of ant, except it was even more awkward to use.
One direction to go is cargo, Rust’s build tool. It takes simple toml files as input. You can’t do very much, but it’s incredibly simple to do anything that you can possibly do.
Another direction to go is sbt. It basically takes Scala as input. Unfortunately, it is mired down with a complex build model with hard-to-discover logic and features. mill improves on this considerably. If you know Scala, it’s better than trying to use Maven because not only is it faster to learn how to do everything (because you already know Scala and can discover most things that are available from the command-line), it also gives you the full power of a programming language (one you already know, if you’re writing Scala).
Trying to use mill to build Rust programs would be weird, though. Rather than use mill itself, I imagine that you’d want a rust-mill that uses a similar logic to (Scala) mill but is coded in idiomatic Rust. As long as you’re going to be using Scala, though, I can’t think of any downside of using mill except possibly that some feature that you need is built-in in Maven and isn’t available in mill and also isn’t easily emulated with a bit of Scala code.
We’ve been using Scala since 2009 and have never moved away from Maven. It (still) serves its purpose, supports a wide range of plugins we need, and is easy to use for new developers.
I’m not sure if easy to use for new developers is true. As a single data point, I never can get it to do anything.
That said, if you’re happy with the tools you’re using and don’t feel you’re being limited by them, I don’t think there is a compelling reason to try others, apart from curiosity. If you’re fine where you are, by all means!
I see I was unclear; By “new developers” I mean developers who come from the “java camp”, not novices. By “easy to use” I mean because Maven familiar to them it’s easy to continue using instead of learning another build-tool.
That said; I really admire the efforts of Li Haoyi, and Mill seems like a step in the right direction for a build-tool, so I hope it’ll gain momentum.
You may have a different experience from most Scala users, who are using sbt right now. We are having an ongoing problem with sbt’s startup and build speeds. We all know the tricks that help to speed things up but sometimes you just can’t avoid restarting sbt to rebuild, and then the slowdown hits you.
Your question is not inherently bad but I’d recommend trying Mill with a simple example project to see its benefits–specifically speed and simplicity.
I use Maven for many projects that involve clients because it is so universal. But truly it is far behind the “state of the art”. I have been using Mill on a new project with great success, and I find I can do a lot more with than can be done with Maven, and its also pretty easy to use once you decide to dive in and learn it.
I’m Li Haoyi fan, though, for a long time. I’ve decided that pretty much any tool he signs his name to is well thought out and solve a real-world problem well, so is worth looking into.
We used Maven when we started our company. In the end Maven is language-agnostic unless you want to write plugins in which case you need to use Java. SBT came about as a build tool which is language-agnostic unless you want to write plugins in which case you need to use Scala. Since we are a Scala shop moving to SBT and building helpful plugins in our language of choice was a natural fit.
At first glance I would say Mill is re-inventing the wheel except the re-inventor is Li Haoyi. I’m gonna sit in the stands for a while eating my popcorn and watching the show but I have no doubt I’ll be building projects with Mill one day.
)