Hacker News Reader

Comment by thenewwazoo | Hacker News Reader

I went into this expecting yet another barrage of complaints about lifetimes, but was very pleasantly surprised. This is probably one of the most thoughtful experienced-programmed new-to-Rust reviews I've read in a long, long time. I frankly don't have much to add, except to say that, once you really understand the language and start building complex projects, this article really does describe the real issues you run into.

View on HN

I think I am familiar with Rust–I spent a week or so working with it–and I ran into many of these exact issues. I appreciate it very much when someone can give a viewpoint of of using a language beyond the superficial one ("arrays start at one in Lua"), or complains about something core to the language ("C pointers are confusing") and actually says something you will run into but is not obvious from having a basic knowledge of the thing ("while Python supports functional programming, it does not do so very well"). Rust's (intentionally) anemic standard library, strange dance around nightly ("we never break things…except in nightly, which we know you are using for your project because we gated all the features behind it") and a general sort of superiority towards npm when cargo/crates.io shares many of the same issues are the ones I ran into personally. And again, you don't have to be an expert to see these, but they're in this sweet spot between nonobvious and "something that'll go away if you use the language more".

"we know you are using [nightly] for your project because we gated all the features behind it"

yes, that kinda sucks.

The asm!() to llvm_asm!() was a pain.

Shouldn't it have been a simple find-and-replace?

> Shouldn't it have been a simple find-and-replace?

For a single crate, sure.

When you're managing multiple crates, an older nightly compiler version (because the software hasn't been tested much on the newer nightly), and git submodules... it isn't so easy.

I wasn't actually doing the work, but from the outside it seemed like a pain.

The silver lining is that the reason for that change was because a proposal for stable inline assembly is actually making progress now, which is IMO fantastic and long overdue.

I am curious which features you and your parent use that are still nightly only! The majority of our users are on stable, but there's always gonna be some cutting edge stuff that people use.

(I'm a big user of asm! myself, but other than that, stick to stable.)

Recently I had to install nightly just to profile my build.

> which we know you are using for your project because we gated all the features behind it

I don't think that's really fair, or at least hasn't been true for a long time now. Use of the stable channel far exceeds use of nightly according to all the surveys. At my company we've always stuck to the stable channel, and even in my own personal projects where I have no need for stability, I don't remember the last time I used a nightly feature, simply because I haven't found the need to...

I don't believe there are many cases left where you're forced to use nightly: most of the cases where people are using it is because there's a "nice to have" feature, not because that feature is actually essential. Even rocket, which was famed for using a ton of nightly features, now works on stable Rust.

Anyone doing OS development is still on nightly last I checked but aside from that stable has the features most people need.

I'm curios which features OS development need from nightly. Maybe inline assembly?

I've been doing some bare metal embedded projects in Rust and didn't need nightly for quite some time.

I use the following in my kernel project: asm, const_fn, const_generics, exclusive_range_pattern, global_asm, panic_info_message, start, untagged_unions.

Of those, I could get away with just global_asm, start, and const_generics if I had to, but the others certainly make my life easier in a kernel space without an allocator.

I'll be the first to admit that some of those are "I'm just going to embrace nightly if I'm stuck on it anyway".

If you want to profile your builds or compiler, nightly is still required.

That's beside the point of what's being discussed here. The concern is that using unstable feature flags in your code, which only work on nightly, allows your code to be broken by compiler upgrades. But using nightly doesn't magically introduce unstable feature flags. There's no compability hazard from merely compiling a compiles-on-stable codebase with a nightly compiler for whatever reason.

Sorry if I thought tooling capabilities were a relevant compiler feature then.

> strange dance around nightly ("we never break things…except in nightly, which we know you are using for your project because we gated all the features behind it")

Creating a beta channel or getting more of those features released in stable requires money or time.

There is a beta channel already. But you'll only get the features which will land in the next stable release anyway 6 weeks in advance.

It's a hard balance to keep. On the one hand you don't want to hold back features that you know people need, but on the other hand - once something is in stable rust the design is kind of locked in forever.

It's still a fairly young language - I think it's a good thing they're being conservative with not setting too much in stone prematurely, while still having stuff released as part of nightly to see relatively widespread use. As the language matures more and more you will see less and less important features that are missing from stable.

Imo lifetimes aren't that complex. They're just a wholly new programming language feature - learning lifetimes is hard because you're simultaneously learning the syntax and the concept.

Compare to something like generics where it's roughly the same idea in most languages that feature them, you just need to learn the syntax and maybe some edge details that differ between languages (Contravariance and Covariance say hello!).

If you've ever helped someone who's entirely new to programming learn their first language you might see some parallels with experienced programmers learning entirely new features like lifetimes.

I don't think the problem with lifetimes is that they are complex, it's that other languages handle lifetimes for you, but Rust outs to onus on you to manage them. C++ also has complex object lifetimes but if you don't invoke that complexity you don't need to deal with it.

>C++ also has complex object lifetimes but if you don't invoke that complexity you don't need to deal with it.

I would tend to disagree?

In C++, I regularly ran into issues where I "invoked" the complexity with memory/object management completely incidentally, and as the saying goes, shot myself in the foot (or rather, both feet, because lifetime management issues often result in heisenbugs and other really nasty phenomena).

Rust makes that complexity explicit, which is really an analogous argument as with static/dynamic typing; it's not that the dynamic languages "handle typing for you", and "static" simply requires more work. Rather, you're forced to deal with it at the very start, instead of down the road.

Then again I'm rather new to Rust, so I might misunderstand you?

You're quite right, but it's worth being mindful that for many projects, down the road never comes. It's a very expensive insurance policy.

The only way to handle lifetimes is:

A) Introduce burden on programmer

B) Introduce burden on runtime (GC basically)

You just get to pick your poison. Do you want the upfront cost in syntax (Rust) or do you want the down the line cost (C/C++).

Coming from a dynamic typing background, I have to say Rust didn't feel much worse than Scala or OCaml to me.

Reply on news.ycombinator.com