[pbarnes_1]

This is cool but everything is too verbose.

`austral compile hello.aum --entrypoint=Hello:main --output=hello`

vs

`go build`

Etc etc.

[TOGoS]

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.

[badrequest]

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.

[ithkuil]

Feel free to invoke "go tool compile" manually. "go build" is just a frontend

[zetalyrae]

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.

[adamrezich]

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?