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

61–70 of 133 posts

Re: Five Years of Rust

#61

Post by FreeFull »

bennofs wrote: post #59
carlmr wrote: post #34

Earlier quoted context omitted.

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 nee…

I'd say having special features is ok, as long as these criteria are met:

1) It's obvious the feature is being used.

2) The feature is easy to look up without knowing what it's called, just based on how it's been used.

3) It's easy to understand what the feature actually does, with the appropriate context.

Re: Five Years of Rust

#62

Post by swsieber »

mindv0rtex wrote: post #57
lzutao wrote: post #54

Earlier quoted context omitted.

We need more volunteers to help implement those features!

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

Many tickets are scored with a difficulty, and sometimes comes with a mentor: https://github.com/rust-lang/rust/labels?q=E-

I think there are meaningful things a beginner can do. I'd be surprised if improving error messages would be terribly hard. And working on the small issues will help you become familiar enough to help with the bigger things.

Edit: Also perhaps a way to get some exposure to the rust compiler is to help implement lints (in clippy) - it's basically a compiler plugin and relies on the same things available in the compiler.

Re: Five Years of Rust

#63

Post by cesarb »

ainar-g wrote: post #15
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.

One way to reason about what could have been done better from the beginning is looking at stuff that is marked as [deprecated] in the standard library. E.g. how the "try!()" macro was deprecated in favour of the "?" operator.

I would say the try!() macro is an exception to that rule: if the ? operator existed since the beginning, it would be seen as "too much magic" (in a language that already used up most of its "strangeness budget" in lifetimes/borrowing), while try!() is just a very simple macro you could write yourself, with no special compiler support. Only later, after people got used to try!() everywhere, the ? operator became viable, as "just a shortcut to try!() with better precedence (and it also works on Option)".

That is, there's a path dependence, where the existence of try!() made the ? operator viable.

Re: Five Years of Rust

#64

Post by davidhyde »

arcadeparade wrote: post #40

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

Search for the following in your browser: “the rust book” for the official free online rust book. “rustlings” for a set of code exercises to get you used to fixing your code when the compiler shows you an error. “iced github” for a cross platform gui library and, lastly, “rust by example book” for a different angle on learning the language.

Re: Five Years of Rust

#65

Post by BiteCode_dev »

fastball wrote: post #42
busterarm wrote: post #25

Earlier quoted context omitted.

That's a feature of several languages right now/at times.

I agree. That's how I've felt about Python with every release since 3.5

And yet there are people complaining it's too slow, or too fast.

I don't think there is any pace of language evolution that will never be criticized.

Re: Five Years of Rust

#66

Post by Ericson2314 »

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.

I've been complaining for a long time that `Drop` is fundamentally wrong. Rust's "just write a new function" fixed C++'s "construction is mutation of location", but Rust's Drop makes the same mistakes as C++: destruction needs to be for consuming data, not borrowing it and mutating it.

Now, we can't just do

  drop(T)
because of DSTs, so we we'll need a new type of consuming reference. And the dual to that, an initializing reference, would also solve the problem of creating DSTs with preallocated memory.

Now both could use MaybeUninit, but it would be better to just have types that vary with the CFG, so one can insure that no matter how one get to point b, the memory is now initialized.

Re: Five Years of Rust

#67

Post by jasode »

cesarb wrote: post #63
ainar-g wrote: post #15

Earlier quoted context omitted.

One way to reason about what could have been done better from the beginning is looking at stuff that is marked as [deprecated] in the standard library. E.g. how the "try!()" macro was deprecated in favour of the "?" operator.

I would say the try!() macro is an exception to that rule: if the ? operator existed since the beginning, it would be seen as "too much magic" (in a language that already used up most of its "strangeness budget" in lifetimes/borrowing), while try!() is just a very simple macro you could write yourself, with no special compiler support. Only later, after people got used to try!() everywhere, the ? operator became viab…

>if the ? operator existed since the beginning, it would be seen as "too much magic" [...] That is, there's a path dependence, where the existence of try!() made the ? operator viable.

Yes, C++ creator Bjarne Stroustrup made a similar observation:

- For new features, people insist on LOUD explicit syntax.

- For established features, people want terse notation.

There seems to be an invisible "Overton Window" of evolving programming language features and syntax.

Re: Five Years of Rust

#68

Post by JeanMertz »

asdkhadsj wrote: post #46
jrimbault wrote: post #26

Earlier quoted context omitted.

Just to point out for other readers, nowadays to make a custom error type you just need : - an enum (or struct) - its Display implementation - its Error implementation, now just one function And a few `impl From for MyError` to make the try? operator work. For a library it's really not that much work. And even that can be simplified further to a few derive macros with another library : thiserror.

To simplify even more, you don't actually need `Display` or `Error` impls. I use Error enums frequently without display or Error impls. Though, with better backtrace support coming it'll be handy to have Error and the Backtrace related APIs implemented. (Sidenote, I don't use `impl Error` because I never use `Box `. Which isn't to say that's correct, just to say that I've never had the need to implement it)

Even though GP meant to highlight compiler error messages, I also have to take my hat off for the library/application error-handling story in Rust.

Using a crate such as thiserror[1] combined with displaydoc[2] makes handling errors in a structured manner a great experience. I love how the error handling story has evolved over the last couple of years in Rust, and it really feels like we're entering into the final stretch of fine-tuning to get the best possible experience.

And yes, anyhow[3] is also great, it serves a different purpose, but I frequently reach for all three crates.

[1]: https://crates.io/crates/thiserror [2]: https://crates.io/crates/displaydoc [3]: https://crates.io/crates/anyhow

Re: Five Years of Rust

#70

Post by ellw »

WilliamEdward wrote: post #39
Multicomp wrote: post #35

Is now the time to start learning rust? In your estimation, are there going to be lots of job opportunities for people who have 15 years experience with rust? I primarily live in the .Net world, but rust seems extremely close to f# in terms of compiler safety, and I'm trying to decide what programming language to learn next.

Plenty of big name companies (discord, amazon) and even universities (georgia tech) are using and teaching rust. That's enough for me to say you should jump on the train.

Another example would be Dropbox which quite recently published this great blog article about "Rewriting the heart of our sync engine" in Rust [1].

[1] https://dropbox.tech/infrastructure/rewriting-the-heart-of-o...

Post reply on HN