opendylan VS zig

Carp, Lux and Dale are 3 I'm familiar with.There's also Dylan, though that one dropped its parentheses. But if we go by the brackets, technically, we can argue that any expression-based languages is a Lisp. I once wrote a Lisp to JS transpile whose output had more parens than the input. :)

Julia is a Lisp in the same form as Dylan.

If OP thinks C is difficult, Rust will give him a huge headache. I'd suggest looking at Zig instead.

If you have an idea on how to better make formal method interfaces composable (via package manager), take a look at https://github.com/ziglang/zig/issues/14656. I was thinking on something akind to refinedC, but I have no idea which formal models are composable and where this could be useful in combination with IO.

Simplicity again, but this time via expressiveness of comptime. A lot of type-level things which are complex in Rust would be natural in Zig. An example here is this PR, where I make a bunch of previously concrete types generic over a family of types. In Zig, that amounts to basically wrapping the code into a function which accepts a (comptime type) parameter. That's a bog standard mechanical generalization. In Rust, doing something like that would require me to define a bunch of traits, probably with GATs, spelling out huge where clauses, etc. Of course, with Zig I don't have a nice declaration-time error, but the thing is, the complexity of the code I am getting an error is different. In Rust, I deal with a complex type-level program which has a nice, in principle, error. In Zig, the error is worse, but, as the program itself is simpler, the end result is not as clear cut. The situations flips if we go complex cases. In Zig, AOS<->SOA transformation is just slightly-clever code, in Rust, that would require leaving the language of types and entering the language of macros.

https://github.com/ziglang/zig/issues/544

Maybe? They say their stage2 parser accepts them now.

For my interests (DPDK, NIC, low level storage I/O etc.) I have high hopes for Zig. And for reasons other have explicated over the last year on HN, I think it'll work much better than Rust.

Readers should have realistic expectations. It's not substantially downhill to write C like code. I ran into this bug right off the bat. TL/DL: Zig linkers does not pull in dynamic libs. It finds static libs but alas the .tsk doesn't give expected behavior anyway:

https://github.com/ziglang/zig/issues/14939

A. Kelly (head Zig dev), to his credit, seems to already be on top of in this through a related bug:

https://github.com/ziglang/zig/issues/14963

I didn't expect to run into link problems on day 1.

No, it won't work. It'll say "actual" is undeclared.

https://github.com/ziglang/zig/issues/4437 is tracking the issue. I think std.testing is going to see some major changes, so it's possible this gets fixed. But going from the responses in that issue, I think that fix might be more of a side effect, since there doesn't seem to be too much sympathy for the issue as-is.

Then you better refill your Zoloft because it looks like there's going to be one last big disruption before it's over. https://github.com/ziglang/zig/issues/1097#issuecomment-1404...

Xtensa support (esp32). Will be interesting how this will be for Rust and Zig support for esp32

https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ...

https://www.phoronix.com/news/LLVM-Xtensa-Backend

https://github.com/espressif/llvm-project/issues/4#issuecomm...

https://github.com/ziglang/zig/issues/5467#issuecomment-1465...

A bit late but one more option for this is the SegmentedList (std.SegmentedList). It's basically an array list but instead of reallocating, it allocates new space for the new items and keeps the old ones in place. I head Andrew talk about this in one of his streams and thought it was an awesome idea.