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

71–80 of 133 posts

Re: Five Years of Rust

#71

Post by Manishearth »

Ericson2314 wrote: post #66
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 initiali…

> but Rust's Drop makes the same mistakes as C++: destruction needs to be for consuming data, not borrowing it and mutating it.

but Rust's drop isn't for that purpose. It's not for the actual cleanup of the struct and its children it is for additional cleanup before the children are deleted. So it has to be mutable. The compiler synthesizes the "delete children" code.

(I don't understand your point about drop)

Re: Five Years of Rust

#72

Post by tragomaskhalos »

ReactiveJelly wrote: post #49
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 frict…

Related to this is how easy it is when looking at someone's code on say GitHub to (a) see how the whole project is structured - because it's basically always the same with the familiar landmarks of src/, cargo.toml etc, and (b) to track down the definition / implementation of a type or function (just by applying knowledge of the module system + looking at the mod and use statements). This is a completely different experience from trying to pick apart some C or C++, where you are, essentially, at the mercy of the implementor's idiosyncratic view of how code should be structured, and really need either an IDE or vast reserves of patience to help navigate it.

Re: Five Years of Rust

#73

Post by brutt »

bluejekyll wrote: post #51
brutt wrote: post #36

Earlier quoted context omitted.

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?

The problem is that #[repr(C)] enum is not compatible with C, even with #[non_exhaustive] annotation, and will never be, because C enum can be described in Rust terms as:

  #[repr(C)]
  enum Foo {
    A = 1, 
    B = 2,
    C = 3,
    UNKNOWN(i32),
  }
which is not possible to define in current version of Rust.

Re: Five Years of Rust

#75

Post by brutt »

ChrisSD wrote: post #44
brutt wrote: post #36

Earlier quoted context omitted.

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.

It's good thing, but it leads to error in code which must talk to C or network, where enum's are not cast in stone.

Re: Five Years of Rust

#76

Post by masklinn »

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

> Rust doesn't allow to enum variables to be forward compatible, i.e. it cannot have a value outside of enum

AKA Rust's enums are type-safe, not aliases for integers with some named constants.

Rather than Rust's, I'd say the mistake is C's enums. If you don't want enums, don't have them.

I guess that's one place where Go did something good: they didn't want to improve on C's enums with proper ADTs so they just stripped out the entire thing, an "enum" is an integer and a bunch of constants. Which you can also use to represent these non-enums in Rust though it doesn't have the iota / step convenience. A simple recursive macro might be able to handle it though.

Re: Five Years of Rust

#77

Post by mesaframe »

GolDDranks wrote: post #9
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

Rust is usually faster than Go. Note the edit in the previous post.

Well, I would say it's faster than Go almost every time.

Re: Five Years of Rust

#78

Post by eximius »

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.

No, this was intentional. The point was to see how the user base used the language before adding permanent language features.

Re: Five Years of Rust

#79

Post by pornel »

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.

It is great. Rust 1.0 with the old borrow checker required knowing where to strategically place extra curly brackets, and when to add `ref` or `.as_ref()` incantations.

Now with the smarter borrow checker and ergonomic improvements most of it is unnecessary, and the error messages know how to suggest the rest.

Re: Five Years of Rust

#80

Post by RazrFalcon »

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.

Three chars limit for keywords and some std types, e.g. `Vec`, `len`, `str`.
Post reply on HN