The current build using rust unstable/nightly?

[TotiTolvukall]

Hi,

I'm wondering if it is such a good idea to use the unstable channel as a dependency for the build?

thor:~/source/repos/External/edit> cargo build Compiling smallvec v1.15.1 Compiling libc v0.2.174 Compiling toml-span v0.5.2 Compiling edit v1.2.1 (/home/thor/source/repos/External/edit) error[E0554]: #![feature]` may not be used on the stable release channel
--> src/lib.rs:4:1
|
4 | / #![feature(
5 | | allocator_api,
6 | | breakpoint,
7 | | cold_path,
... |
11 | | maybe_uninit_uninit_array_transpose
12 | | )]
| |__^

For more information about this error, try rustc --explain E0554.
error: could not compile edit (lib) due to 1 previous error`

Is using the unstable channel of Rust really needed?

[lhecker]

I'm wondering if it is such a good idea to use the unstable channel as a dependency for the build?
[...]
Is using the unstable channel of Rust really needed?

The short answer is: Yes, it is.

Before I give a generic but detailed response for something you may already know, is there something specific you'd like to know?

[TotiTolvukall]

I simply was on general terms as from where I am, prereleases of compilers are generally seen as "fun toys but not intended for real work" - so I was a bit taken aback when I saw a Microsoft owned project advocate the opposite.

Perhaps it's a non-issue with Rust - I'm not vested well enough in the Rust ecosystem to know what applies there in contrast to C# and friends.

[lhecker]

The official Windows release binaries are built with the stable compiler toolchain via RUSTC_BOOTSTRAP=1, which is now documented as an official opt-out for the stability guarantees.

My own reason is that I really don't care about any of the stability guarantees that Rust gives me at this point in the project (age = <<1 year). What I primarily care about is how fast I can implement new features, prototype, etc., and, in that regard, nightly Rust is tremendously better than stable Rust. For instance, I've finished implementing replacements for allocator_api over the weekend, and the result is just straight up bad. There's now a "split brain" between stdlib and custom types and you can't mix & match them well. It's really really not a great experience all around.

I've come to my own personal conclusion that I should've really tried harder selling Zig internally at Microsoft (which is currently not endorsed for internal use) or perhaps stuck with C for longer...

[thekovic]

I wish you good luck with Zig - it seems like a useful tool for interop between C and something-nicer-than-C.