On the contrary, I like it when the interface to my tools err on the side of precision at the cost of verbosity. I can always write a shell script or Makefile that does all the boring stuff once I've learned what the inputs mean, but if a tool only provides an overly simplified interface, it is much less obvious what it's doing, or what the other options might be, if any.
What does `go build` do? What files does it implicitly rely on? I have no idea. But I have a pretty good idea of what that `austral` command is going to do without having read any documentation about it.
You might, but I don't. In the argument `--entrypoint=Hello:main`, where does `Hello` come from? Is it some root module? What about `main`, is that some default, or the name of a file without an extension? This strikes me as just enough verbosity to be confusing, and not enough to be explicit.
Right above that line in the docs is a pretty clear view of 'Hello' and 'main'. Its a file "hello.aum" which declares a module 'Hello' with a function called 'main'. You compile the file to be an executable by giving it function to run as the entrypoint. This really couldn't be clearer I dont think.
The idea is the compiler has a bunch of explicit flags, but the build system (which doesn't exist yet) will have the `foo build`, `foo run` etc. commands and find the files using a package manifest.
Essentially like `cargo` vs. `rustc`. I have a little prototype of the build system in Python but haven't pushed it up yet.
what's encouraging you to conceive of the build system and the language as separate things? I never understood why most people making new languages seem to want to have each of these be distinct—why not just define the build using the same language?
So there's differing views on this, Zig famously has the build system built in.
To me, having them separate forces you to keep things simple, because the build system can't communicate with the compiler except through compiler-provided interfaces.
Also, I think I like about languages like C, Rust, is that: if I wanted to, I could implement the build system without forking the compiler. In C specially because Make will print all the compiler invocations for you. It lets people build tooling that is not part of the compiler.
I think it's good from a simplicity perspective that language users can figure out what set of compiler invocations a build file "compiles down" to.
Realistically your provided build tool won't be everything. Cargo is enough to build my toy projects and even some fair size software written mostly in Rust, but it's not enough to build Mozilla, or Linux, or Android, or other large systems with a bunch of Rust in them - including Rust's own compiler and standard library.
But, when you get big enough to where this sort of provided tool isn't enough, chances are tooling is now somebody's actual problem anyway, if you're a for-profit somebody's job is to look after the tooling, you can invest in learning a specialized tool or even writing one because that's a proportionate effort, it makes sense.
What does `go build` do? What files does it implicitly rely on? I have no idea. But I have a pretty good idea of what that `austral` command is going to do without having read any documentation about it.