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

41–50 of 133 posts

Re: Five Years of Rust

#41

Post by k__ »

steveklabnik wrote: post #30
bryanlarsen wrote: post #22

Earlier quoted context omitted.

The "2018 edition" of Rust made breaking changes to the syntax (but the core stayed compatible, so 2015 edition and 2018 edition Rust can be used simultaneously on the same project). They then said that they'd probably do the same thing in 2021. Now they're debating whether a 2021 edition is needed since there aren't any breaking changes with broad support except for the removal of deprecated syntax and APIs. This is…

I don’t think there’s consensus around very large things, but there are some regrets that are commonly expressed about smaller stuff. For example, lots of people think the PartialEq/Eq split was a mistake. I like to half-joke that String should have been StrBuf. Macros have several flaws and are under-developed, etc. There are also some thoughts about Rust-like languages with some differences, see https://boats.gitla…

I saw that the Piston developers created Dyon which could be seen as a Lua in the Rust spirit. No garbage collection, only lifetimes.

https://github.com/PistonDevelopers/dyon#list-of-features

Re: Five Years of Rust

#43

Post by jdub »

empath75 wrote: post #14
sandGorgon wrote: post #5

Is the current status of Rust that it is slower than Go ? According to this previous post - https://news.ycombinator.com/item?id=23058147

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.

Re: Five Years of Rust

#44

Post by ChrisSD »

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).

I think that's a good thing. A C "enum" is just a shorthand for declaring an int alias and some constants. You can do that in Rust easily enough.

A Rust enum is an actual enumeration type, which C does not have. This is far more powerful.

Re: Five Years of Rust

#45

Post by qwe098cube »

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

Re: Five Years of Rust

#46

Post by asdkhadsj »

jrimbault wrote: post #26
empath75 wrote: post #8

Earlier quoted context omitted.

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

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)

Re: Five Years of Rust

#47

Post by asdkhadsj »

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.

While I agree with you, I think you underestimate the number of features that help Rust be great in the face of a Lifetimes and Generics. One feature tends to lead to another. For example, Traits with Associated Types are amazing, but they then lead to a desire for GATs. GATs aren't (in this context) some fancy feature of its own, it fills in a noticeable void in an existing feature, Traits.

So many of these features Rust adds just fill in holes in an already extensive ecosystem.

I agree some feature development could be toned down to mitigate the moving target problem.. hell I think last years poll expressed roughly that. But, I think there's still a ton of features yet to come that merely complete what we already have.

Re: Five Years of Rust

#48

Post by rcxdude »

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 not particularly adventerous as far as PL theory is concerned: all of the ideas in it are actually quite old (just newer than the ideas in established languages, like C). It's fundamentally quite pragmatic and you see that in most of the decisions it makes. I also don't agree that minimal features is necessary for success (even though it may be a desireable attribute of a language). Many extremely successful languages have piled on features over time, some in a far less reasoned way than rust (C actually a big outlier in how slowly it has evolved: C++, Java, C#, python, perl, PHP, etc are all large languages, with complexity in terms of number of features similar to Rust).

Re: Five Years of Rust

#49

Post by ReactiveJelly »

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.

The ecosystem _is_ one of my favorite parts of Rust.

Building C++ (or C) projects is such a clusterfuck that it's given rise to header-only libraries.

In Rust, everything is "cargo build", and adding a dependency is one line. This has only failed for me when there's a dependency on a C system library that I can't satisfy.

Is it bad to have too many dependencies? Sure, maybe. Is that an excuse to have artificial friction? No. I eagerly await the day when meson or conan or whatever becomes The C++ Dependency And Package Manager.

My other favorite part of Rust is the elitist language features like iterators, immutable borrows, functional programming, etc.

Re: Five Years of Rust

#50

Post by aliceryhl »

empath75 wrote: post #14
sandGorgon wrote: post #5

Is the current status of Rust that it is slower than Go ? According to this previous post - https://news.ycombinator.com/item?id=23058147

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.

I have the opposite feeling. Every time I do something that could be expensive or incorrect, the language makes sure that I notice, which I find extremely helpful in writing fast code the first time around.
Post reply on HN