Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Five Years of Rust

blog.rust-lang.org

Post reply on HN
Print view View original

51–60 of 133 posts

Re: Five Years of Rust

#51

Post by bluejekyll »

brutt wrote: post #36
jasode wrote: post #10

Now that there's been 5 years since v1.0, is there any consensus on design mistakes that Rust made? Any mistakes that people wish they could turn back time and do differently but can't because it would break compatibility with too much existing code out there? That's the more interesting list to me.

Incompatibility between C enums and Rust enums forces to use integers instead, which leads to errors. (Rust doesn't allow to enum variables to be forward compatible, i.e. it cannot have a value outside of enum).

To future proof an enum in rust you use the #[non_exhaustive] annotation.

For C compatibility you have lots of options like #[repr(C)] or #[repr(i32)] to be C compatible. So not sure what you are referring to?

Re: Five Years of Rust

#52

Post by mindv0rtex »

I hope Rust adds the major anticipated features (GATs, const generics, specialization) soon, or alternatively decides to not implement them altogether. I'm a rather new Rust developer, but still I very quickly ran into the issue of needing a nightly version of rustc because one of my dependencies (PyO3) relied on one of these features. It would be awesome to have some periodic updates from the compiler team on the progress thereof.

Re: Five Years of Rust

#53

Post by aliceryhl »

empath75 wrote: post #8
ojnabieoot wrote: post #6

The progress on the error messages truly is worth highlighting, and kudos to the team for all the hard work there. It's one of the hardest things to get right in a programming language, particularly if that language has a fussy compiler.

I’ve been using the anyhow crate and it’s made error handling almost painless.

Anyhow isn't really about error handling, but about error reporting. With an ordinary enum error, I can match and easily handle the error if I want to handle some errors in special ways. If I want to handle an anyhow error, I have to do string matching on the message, or try to downcast it, which is cumbersome.

What anyhow makes easier is to collect many types of errors together and reporting the errors to the user.

Re: Five Years of Rust

#54

Post by lzutao »

mindv0rtex wrote: post #52

I hope Rust adds the major anticipated features (GATs, const generics, specialization) soon, or alternatively decides to not implement them altogether. I'm a rather new Rust developer, but still I very quickly ran into the issue of needing a nightly version of rustc because one of my dependencies (PyO3) relied on one of these features. It would be awesome to have some periodic updates from the compiler team on the pr…

We need more volunteers to help implement those features!

Re: Five Years of Rust

#55

Post by baq »

rat9988 wrote: post #18
empath75 wrote: post #14

Earlier quoted context omitted.

As someone who is not a particularly good programmer who has done quite a bit of coding in both at this point, it seems to be easier to accidentally write extremely slow code in rust than it is in go, but once you start optimizing, rust will generally be faster, sometimes by quite a lot. I’ve also run into fewer pathological cases as I’ve learned more of the idiomatic rust patterns.

>it seems to be easier to accidentally write extremely slow code in rust than it is in go Never felt about it this way.

likely depends on your background; if you come from GC languages and are used to everything-is-a-reference, you might end up surprised that Copy types are a thing. right after that you might want to box everything so .clone() works everywhere when you find that some types aren't Copy.

Re: Five Years of Rust

#56

Post by rvz »

qwe098cube wrote: post #45
arcadeparade wrote: post #40

What’s the best resource to get started with Rust and make a desktop app?

https://areweguiyet.com/ gives a broad overview, but is slightly outdated i believe. I recommend all raph linus' research on this topic, fairly recent blog: https://raphlinus.github.io/rust/druid/2019/10/31/rust-2020.... Personally I used iced [1] a bit and found it very pleasant to use. iced is cross platform, sponsored and very active. https://github.com/hecrj/iced

Well, at least read the small prints and footnotes of this GUI library.

> Iced moves fast and the master branch can contain breaking changes!

Even in general, this crate is not even 1.0 or stable for production use. I'd rather wait until it is mature before touching it. Until then, Qt is the way to go.

Re: Five Years of Rust

#57

Post by mindv0rtex »

lzutao wrote: post #54
mindv0rtex wrote: post #52

I hope Rust adds the major anticipated features (GATs, const generics, specialization) soon, or alternatively decides to not implement them altogether. I'm a rather new Rust developer, but still I very quickly ran into the issue of needing a nightly version of rustc because one of my dependencies (PyO3) relied on one of these features. It would be awesome to have some periodic updates from the compiler team on the pr…

We need more volunteers to help implement those features!

Is there a meaningful help that a Rust beginner can provide here?

Re: Five Years of Rust

#58

Post by bluejekyll »

mindv0rtex wrote: post #52

I hope Rust adds the major anticipated features (GATs, const generics, specialization) soon, or alternatively decides to not implement them altogether. I'm a rather new Rust developer, but still I very quickly ran into the issue of needing a nightly version of rustc because one of my dependencies (PyO3) relied on one of these features. It would be awesome to have some periodic updates from the compiler team on the pr…

Technically speaking, those are implemented, just not stabilized, if you’re using them in the nightly, they’re just disabled in stable.

So I would anticipate they will eventually stabilize like many other features have and become part of stable.

Re: Five Years of Rust

#59

Post by bennofs »

carlmr wrote: post #34
easytiger wrote: post #21

Rust mods have to stop listening to the elite language intelligentsia. Successful eco systems are pragmatic and idiomatically straightforward. Everything & the kitchen sink in a language is not a recipe for success. Every language that has a long lifespan spent a long time in feature minimal stasis too. The world won't learn a moving target.

Rust is barely a moving target since 1.0. If you only read the version releases it might seem so, but for the pragmatic programmer not much is changing. Many of the changes concern very special features that only a few libraries make use of. As a library user you don't need to learn them. I learned Rust a few years ago and without keeping up with the latest changes too much I still feel confident I can work on curren…

Having these "very special features" means that there are some things with are added to the language but rarely used. That means that you might come across code in a library that you don't understand, especially if you're not using those features in your own code.

So, I think the argument that "very special features" shouldn't be counted toward language complexity/growth is wrong, IMO. I would even say that there needs to be even more focus on those features, since they tend to be not widely known, not familar, and often there is less documentation about them, so the likelyhood that they make code hard to understand is even higher.

This is not to say that those features are unnecessary. I just don't think the justification "they are not what a pragmatic programmer will see" is good.

Re: Five Years of Rust

#60

Post by sanxiyn »

jdub wrote: post #43
empath75 wrote: post #14

Earlier quoted context omitted.

As someone who is not a particularly good programmer who has done quite a bit of coding in both at this point, it seems to be easier to accidentally write extremely slow code in rust than it is in go, but once you start optimizing, rust will generally be faster, sometimes by quite a lot. I’ve also run into fewer pathological cases as I’ve learned more of the idiomatic rust patterns.

And yet, a lot of experienced programmers have noted that even when they write their first time naïve Rust, it turns out to be really fast.

For example, Bryan Cantrill wrote about his experience in "The relative performance of C and Rust". I found the post fascinating.

http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa...

Post reply on HN