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

121–130 of 133 posts

Re: Five Years of Rust

#121

Post by steveklabnik »

littlestymaar wrote: post #109
steveklabnik wrote: post #105

Earlier quoted context omitted.

> Why couldn't There may be possible ways of doing this, but you're approaching this from the wrong angle. Right now , this is not possible, due to policy. This policy is informed by the technical restrictions right now. There may be possible ways in the future to handle this, but as of right now, there are not. The reason this is true right now is that there is one copy of the standard library for every program. So…

This isn't the answer I wanted, but it's a good answer. Thank you

You’re welcome. (I imagine that you’d get the same version conflict situation with your idea btw: std::2018::Option is not the same type as std::2021::Option.)

Re: Five Years of Rust

#122

Post by twic »

masklinn wrote: post #116
twic wrote: post #84

Earlier quoted context omitted.

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?

I'm thinking of the need to have blocks wrapping expressions in types [1]:

  const X: usize = 7;
  
  let x: RectangularArray;
  let y: RectangularArray;
Simple cases are fine, but i suspect a lot of real-world use of const generics are going to require blocks.

AIUI, this is only because was chosen as the container for type arguments, and > is also a legal operator in expressions. So, for example, if Rust had used Scala-esque [] for type arguments, this would not be a problem.

[1] https://rust-lang.github.io/rfcs/2000-const-generics.html#ap...

Re: Five Years of Rust

#123

Post by doteka »

mlindner wrote: post #119
doteka wrote: post #87

Earlier quoted context omitted.

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?

Yeah, sure. What I have seen a lot when hiring, is "magpie developers". These guys always have the hippest CV - if it's on the HN front page regularly, you bet it's on there.

We found in practice, these people tend not to be the best additions to a team. They are mostly interested in the new thing, and only for so long as it is new. When something new comes along, that's what they want to flock to. They'll be an endless source of rewrite suggestions, but tend to struggle when they need to actually dive in and solve complex problems with these tools.

In contrast, we are not really using Rust because it's the new thing on the block. We are using it because we write complex software that needs to run fast for the business to be viable, and Rust's got the best tradeoffs for that right now. If Rust wasn't a thing, we'd likely be using C++.

Re: Five Years of Rust

#124

Post by doteka »

mlindner wrote: post #119
doteka wrote: post #87

Earlier quoted context omitted.

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?

Also, a word of advice: the language in use should be one of the last things you're considering when looking for jobs. It really doesn't make a difference in your day-to-day happiness.

Instead, try to look for a team you fit in with, a manager you can trust, growth opportunities, and the chance to work on interesting projects that have impact. Case in point, one of my most enjoyable (and beneficial to my career) jobs was mostly Java 8 - and that's certainly near the bottom of my "good programming languages" list.

Re: Five Years of Rust

#125

Post by Uther »

twic wrote: post #122
masklinn wrote: post #116

Earlier quoted context omitted.

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

I'm thinking of the need to have blocks wrapping expressions in types [1]: const X: usize = 7; let x: RectangularArray ; let y: RectangularArray ; Simple cases are fine, but i suspect a lot of real-world use of const generics are going to require blocks. AIUI, this is only because was chosen as the container for type arguments, and > is also a legal operator in expressions. So, for example, if Rust had used Scala-esq…

While I would prefer brackets, that would not be enought to solve all the problems since, there would be conflict with array syntax too.

Re: Five Years of Rust

#126

Post by twic »

Uther wrote: post #125
twic wrote: post #122

Earlier quoted context omitted.

I'm thinking of the need to have blocks wrapping expressions in types [1]: const X: usize = 7; let x: RectangularArray ; let y: RectangularArray ; Simple cases are fine, but i suspect a lot of real-world use of const generics are going to require blocks. AIUI, this is only because was chosen as the container for type arguments, and > is also a legal operator in expressions. So, for example, if Rust had used Scala-esq…

While I would prefer brackets, that would not be enought to solve all the problems since, there would be conflict with array syntax too.

But the square brackets used in array access nest, so the parsing is never ambiguous.

The reason > needs braces is that without them, if you're parsing and so far you've seen these characters:

  let y: RectangularArray
You don't know if that final > is ending the argument list, or is a greater-than operator, with the rest of an expression coming after it.

But if it was square brackets, then a closing square bracket on its own can only ever be the end of the list:

  let y: RectangularArray[i32, X, 2]
Because if it was closing an array access, there would have to have been an opening square bracket:

  let y: RectangularArray[i32, X, a[1]

Re: Five Years of Rust

#127

Post by athriren »

doteka wrote: post #124
mlindner wrote: post #119

Earlier quoted context omitted.

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

Also, a word of advice: the language in use should be one of the last things you're considering when looking for jobs. It really doesn't make a difference in your day-to-day happiness. Instead, try to look for a team you fit in with, a manager you can trust, growth opportunities, and the chance to work on interesting projects that have impact. Case in point, one of my most enjoyable (and beneficial to my career) jobs…

This is all very good advice.

Re: Five Years of Rust

#128

Post by littlestymaar »

steveklabnik wrote: post #121
littlestymaar wrote: post #109

Earlier quoted context omitted.

This isn't the answer I wanted, but it's a good answer. Thank you

You’re welcome. (I imagine that you’d get the same version conflict situation with your idea btw: std::2018::Option is not the same type as std::2021::Option.)

Even if std::2018 is just doing: `pub use std::2021::Option`?

Re: Five Years of Rust

#129

Post by masklinn »

Uther wrote: post #125
twic wrote: post #122

Earlier quoted context omitted.

I'm thinking of the need to have blocks wrapping expressions in types [1]: const X: usize = 7; let x: RectangularArray ; let y: RectangularArray ; Simple cases are fine, but i suspect a lot of real-world use of const generics are going to require blocks. AIUI, this is only because was chosen as the container for type arguments, and > is also a legal operator in expressions. So, for example, if Rust had used Scala-esq…

While I would prefer brackets, that would not be enought to solve all the problems since, there would be conflict with array syntax too.

That's what I originally thought about, but the thing is `]` in and of itself is not an operator while `>` is, so

    foocorge>
"is" valid syntax while

    foo[bar, qux]corge]
is not. The former requires some sort of disambiguation, while the latter is not. Put an other way, in terms of syntax `[]` always parses the same way (with `[` is infix and `]` terminates it), there can be ambiguity between indexing and generics but it doesn't really matter for the original parsing.

For `` however, the parsing itself can be ambiguous as `>` could either be the terminator of an earlier `` operator. That is where the issue lies, you can't know how to build the AST without either explicit disambiguation, or infinite lookaheads.

Re: Five Years of Rust

#130

Post by Manishearth »

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.

This does not seem simpler to me, this seems easier to mess up. The most common use case is dropping all fields.

Furthermore, you still have to special-case Drop because now you have to support destructive destructuring for Drop types because it isn't allowed anywhere else.

And plus, if you forget to do this, the failure mode is a stack overflow.

The current design is absolutely based on practical requirements here, it is not a retroactive justification. This is by and large how destructors work, for good reason.

Post reply on HN