illumos support

To be clear, the OmniOS distribution of illumos. But if you can make it work on OmniOS, I think it should work on illumos in general.

illumos has Firefox and thus also has a decent Rust compiler to bootstrap Adept 3.x

[IsaacShelton]

Ah cool yes that's great.

As I've been adding in support for other operating systems for Adept 2, I've been thinking about how to support as many operating systems as possible for Adept 3.

Yes this is a little more complicated, since Rust support isn't as common as C support, but as long as it has a Rust compiler, I'm trying to make it so that at least the traditional "oneshot" compiler will run. (Services such as the language server, incremental compilation, and background compilation may require additional compiler code depending on the platform, we'll see)

I'm trying to limit the dependencies as much as possible and to only simple things. It would be great if one day this compiler could be rewritten in itself, since Rust is not a great language for handling the sorts of "async compute" that's necessary in this more featured version.

---

For Adept 3.x to be ready though, there's basically three most difficult areas remaining that I'm designing:

• Incremental compilation, caching, and background compilation - I'd like to have a background daemon that automatically incrementally compiles and caches results for near-instant build times (even faster than Adept 2). This will also serve as the backbone for the language server, so work isn't duplicated between incremental compilation and LSP requests.
• The async system - will probably be some easier to understand version of "algebraic effects". These are similar to a superset of exceptions that allow resuming zero, one, or more times after catching (although ours will probably will be implemented as zero-cost). We'll probably have a strictly typed version that enables stackless futures and scoped implementations of interfaces (strict interface implementation consistency is another part of this that will take some work to figure out). First class continuations will probably be supported too since they're kind of necessary for this anyway.
• Dependent types - I'd like to have the ability to use expressions in a type context, this might be simple since we already have full support for compile-time evaluation of expressions, functions, etc., but might be more complicated for more non-integer data types. Not sure how far this rabbit hole is worth going down. Also to have refinement qualifiers, e.g. func concat(list_a #len<$A_LEN> List<$T>, list_b #len<$B_LEN> List<$T>) #len<$A_LEN + $B_LEN> List<$T> { ... } (syntax not final of course). Not something that's always worth specifying, but can be useful in libraries for cases when the lengths can be determined statically to provide type guarantees that would normally have to be asserts.

The other areas of the design that I'm building are most constrained by these. It may be a few years until the base language is ready, but these three unknowns have the potential to influence everything else. (And after these, is maybe borrow checking, formatter, documentation generator, etc.). Once it's the base language is ready, it should be able to run on IllumOS day 1.