Make lis build actually produce a binary

[ekisu]

This is mostly a UX quirk for me, but it's a bit weird that lis build produces intermediate code but lis run produces a binary and runs it.

My suggestion is to make lis build actually produce the binary, and rename the current lis build command to lis transpile/lis generate or something.

[ivov]

Thanks for your feedback :)

Gleam and ReScript use build to produce source, Go and Rust and Zig use build to produce an executable. The binary from lis run is only a side effect. The intent is for the user to access the target dir and take it from there with the Go toolchain. Open for discussion whether Lis should take on this responsibility as well.

[rsyring]

As someone who hasn't done much with go, avoiding it mostly due to some of the typing deficiencies, footguns with nil, and verbose error handling, I'm finding myself interested in working with go through Lisette. I'd like to see it handle more rather than less, at least for the standard use cases.

I'd like to see a build command that produces an executable like Cargo, etc. does.

[ekisu]

As for Gleam/ReScript, I'd argue that in those languages it makes sense for the final output to be source code because in the target languages you usually run the program through an interpreter/JIT. Same for TypeScript, languages that compile down to Lua, etc.

IMO Lisette is closer to something like Vala, V-lang, or Chicken Scheme. Those transpile to C, whose end result is a binary, and the default "build" commands in those (valac file.vala, v file.v, csc file.scm) produce an executable binary.

[syedways]

While those languages may be the closest analogues to Lisette in term of ideology/goals, I agree with ekisu that Lisette is fundamentally different from them because Go compiles to native machine code and doesn't need the BEAM or a JS engine to run the produced code.

I definitely think that the build command should produce a binary.

[rsyring]

My suggestion is to make lis build actually produce the binary, and rename the current lis build command to lis transpile/lis generate or something.

lis build --src-only rather than a separate command?

[RestartFU]

I do agree with that, I believe it should produce a binary like Go and Rust, as this is probably the target audience anyway

[enquora]

I do agree with that, I believe it should produce a binary like Go and Rust, as this is probably the target audience anyway

This presupposes that no external processes are involved or necessary - such as running tests or packing operations against the generated Golang code (e.g. usingzig to build cross-platform binaries where C FFIs are involved and would otherwise require multiple compilation toolchains).

fwiw, while Lisette syntax is Rust-oriented, the language capabilities themselves are more closely aligned with OCaml.
Perhaps someday we will be able to mimic its module system.

I hold a strong belief that lis should not provide project orchestration any more inclusive or tightly coupled than it currently is.
Further functionality is the proper province of a true orchestration system like make.
The current implementation occupies exactly the ideal middle ground which the Golang toolchain does.
I do not have a single Golang project which does not require orchestration beyond the capabilities provided by the native toolchain.
make is your friend, solving exactly this problem for a half century - do not reinvent the wheel.

I am porting the toolchain for a non-toy language and development environment which is currently hosted in Javascript/Node/npm.
The build orchestration is also self hosted - and a fragile mess.

The ported toolchain targets precisely the level of orchestration provided now by Lisette and Golang themselves.
Anything more will be outsourced to the developers' orchestration platform of choice.
Tests which move off this sweet spot have proven it to be the correct choice.

[ivov]

Thanks @ekisu and everyone else. After more thought and research, I agree with your arguments and am reversing my position. These lis verbs will move to a phase ladder, each one doing one more step than the last:

verb	effect	artifact
lis emit	write Go source	target/*.go
lis build	lis emit then go build	target/bin/{name} binary
lis run	lis build then run binary	target/bin/{name} binary + execution

Landing in the next breaking change release. Edit: Released with lisette-v0.4.0