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

111–120 of 133 posts

Re: Five Years of Rust

#111

Post by Ericson2314 »

Ericson2314 wrote: post #93
Manishearth wrote: post #71

Earlier quoted context omitted.

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

> It's not for the actual cleanup of the struct and its children it is for additional cleanup I think that purpose is the tail wagging the dog, an explanation of the current method rather than an actual requirement. The simpler thing to do is just have drop on the aggregate calls drop on the fields, just as new on the aggregate can call new on the fields.

> (I don't understand your point about drop)

Ah I meant to write the function signature:

> fn drop(T);

contrasted with the:

> fn drop(&mut T);

that we have today

Re: Five Years of Rust

#112

Post by aey »

BiteCode_dev wrote: post #65
fastball wrote: post #42

Earlier quoted context omitted.

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.

Rust has been really great at incremental language upgrades because of clippy. Stuff get deprecated, clippy issues warnings, buy the time support is dropped your code has been patched.

It feels like we are in some new weird software engineering world where the code is only alive while its actively maintained and worked on. The libraries that are shipped in the OS seem as constant and fixed in time as x86, basically completely abstracted by the constantly evolving software on top of it.

Re: Five Years of Rust

#113

Post by zanny »

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…

Having both the terse and the verbose is so valuable for onboarding.

I feel like the reason pointers as a mechanism in native languages is such a barrier to cross for a newbie is because they are this magical star symbol * just floating around doing... something?

If people started out writing pointer foo instead of string* foo and had to use explicit derefrencing via name rather than by magical glyphs onboarding would be so much easier.

I think it applies to almost all programming concepts too. Starting a language with a baseline grammar of just function invocation -f(x) = y as .(...) - and extrapolating from there and introducing terse grammar progressively as shortcuts would serve much better to get concepts in heads rather than arcane ritualistic glyphs. Introduce x.add(y) then say x + y is the shorthand.

Rust does a really great job "functionizing" almost everything in the language - it has the add trait after all https://doc.rust-lang.org/std/ops/trait.Add.html. You can actually write tons of Rust in just function call form and make it look like Lisp.

Re: Five Years of Rust

#114

Post by alvarelle »

pornel wrote: post #82
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.

There isn't much. Rust has deprecated some mistakes (like Error::cause). The editions mechanism allowed fixing some issues (like unintuitive module paths). https://github.com/rust-lang/rust/issues?q=label%3Arust-2-br... • Struct literal syntax should have used C99 syntax. The language uses `name:type` everywhere except struct literals which use `name:value`, and this gets in the way of adding new syntax (type ascript…

What's magic in Box?

Re: Five Years of Rust

#115

Post by pornel »

alvarelle wrote: post #114
pornel wrote: post #82

Earlier quoted context omitted.

There isn't much. Rust has deprecated some mistakes (like Error::cause). The editions mechanism allowed fixing some issues (like unintuitive module paths). https://github.com/rust-lang/rust/issues?q=label%3Arust-2-br... • Struct literal syntax should have used C99 syntax. The language uses `name:type` everywhere except struct literals which use `name:value`, and this gets in the way of adding new syntax (type ascript…

What's magic in Box?

Dereferencing: https://manishearth.github.io/blog/2017/01/10/rust-tidbits-b...

Re: Five Years of Rust

#116

Post by masklinn »

twic wrote: post #84
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.

The planned const generics syntax is going to look pretty weird, because it builds on type generics. If Rust had chosen a different syntax for type generics, const generics might look less weird. The futures design was built with epoll in mind, and now people are trying to wrap it round io_uring, they are feeling some pain. Would a different design have worked better, without massive drawbacks?

> The planned const generics syntax is going to look pretty weird, because it builds on type generics. If Rust had chosen a different syntax for type generics, const generics might look less weird.

Could you provide an example? Because I don't really see it, except by requiring that non-const generics also be explicitly annotated?

Re: Five Years of Rust

#117

Post by masklinn »

empath75 wrote: post #110
baq wrote: post #55

Earlier quoted context omitted.

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.

Yeah it’s definitely around using clones everywhere.

I don't know that clones are problems in and of themselves rather than what they do behind the scenes: allocations. Cloning an Rc is completely innocent, cloning a HashMap> is deadly in a way you may not expect if you're used to shallow-copying hashmaps (or even deep-copying them).

And it's true that if you think of allocations as being no big deal unless you're aiming for very high performance, your Rust is going to be slow (also your C++ and your C).

Re: Five Years of Rust

#118

Post by mlindner »

brutt wrote: post #75
ChrisSD wrote: post #44

Earlier quoted context omitted.

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.

You can assign any value to a C enum, they literally are just integers.

Re: Five Years of Rust

#119

Post by mlindner »

doteka wrote: post #87
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.

My job is about 50% Rust, 40% Typescript, 10% Python with regards to language. I would say Rust is the best day to day experience out of these 3 except for glitchy editor tooling and the long compile times. We have 1000 line services that take close to 10 minutes for a release build which is not ideal. I would not necessarily suggest learning Rust to get a job though. We mostly stopped mentioning it in our job ads be…

> We mostly stopped mentioning it in our job ads because we don’t want people applying for the “hip stack”.

Can you elaborate on that? I'm maybe thinking of changing jobs soon and my #1 want is that I can commonly program in Rust as opposed to C. Why would you explicitly avoid mentioning Rust?

Re: Five Years of Rust

#120

Post by hu3 »

Tuna-Fish wrote: post #29
manaskarekar wrote: post #7

Earlier quoted context omitted.

While Go may be faster somewhere, that post was not a good comparison. See the discussion around it and the patches made by the community and the final results. See the individual benchmarks: https://github.com/christianscott/levenshtein-distance-bench...

And just to help the lazy people, after making the benchmarked loads equivalent, the results are: hyperfine go/out 'node javascript/main.js' rust/target/release/rust 1 Benchmark #1: go/out Time (mean ± σ): 1.888 s ± 0.013 s [User: 2.040 s, System: 0.045 s] Range (min … max): 1.875 s … 1.918 s 10 runs Benchmark #2: node javascript/main.js Time (mean ± σ): 4.257 s ± 0.033 s [User: 4.295 s, System: 0.042 s] Range (min ……

The Go and Rust program in that benchmark are really not equivalent. Rust is using threads.
Post reply on HN