Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thoughts on Rust, a few thousand lines in

rcoh.me

Post reply on HN
Print view View original

131–140 of 183 posts

Re: Thoughts on Rust, a few thousand lines in

#131

Post by steveklabnik »

da_chicken wrote: post #128
steveklabnik wrote: post #81

Earlier quoted context omitted.

As stated below, indexing is an O(1) operation, and that is a O(n) operation. > If a string is an array of characters It is not, it is an array (technically vector) of bytes.

Who cares if it's O(1) if it causes a panic? What good is high performance if it doesn't complete or isn't safe? At the very least, shouldn't there be an O(n) method to do character-wise slicing?

panics are safe. You expect the “I don’t have a bug” case to be fast.

You can, but it depends on what you mean by “character”, as that’s not a concept in Unicode. Every kind of thing you could mean has a method, specific to it, since they’re different things.

(char in Rust is a Unicode scalar value, and you can collect into a Vec and then slice it, as an example of one of those things. And that’s still O(1) at the cost of using up to four times the memory.)

Re: Thoughts on Rust, a few thousand lines in

#132

Post by StavrosK »

pornel wrote: post #96
throw0u1t wrote: post #26

One thing I don't like about Rust is how taking a slice of a string can cause a runtime panic if the start or end of the slice ends up intersecting a multi-byte UTF-8 char. I would prefer it if this feature didn't exist at all rather than cause runtime panics. https://play.rust-lang.org/?gist=e02ce5e9aacfee3a2b4917d5624...

It's not a problem in practice, because you'd use something like `.char_indices()` iterator, or result from a substring search, etc. to get correct offsets in the first place. It's not useful to blindly read at random offsets in UTF-8 strings. If it didn't panic, you'd get garbage. If offsets were automatically moved to skip over garbage, you wouldn't know what you're getting, and your overall algorithm would likely…

What does zero-cost mean in this context? It must cost something to run, no? Or is it basically a compiler hint instructing the next function to treat the data as pure bytes?

Re: Thoughts on Rust, a few thousand lines in

#133

Post by mquander »

f2f wrote: post #105
daboross wrote: post #91

Earlier quoted context omitted.

Could you site this? I've looked at ilovecaching's comment history (at least up to ~60 days ago) and they seem consistent on being a networking programmer who uses C++. Was there a particular comment you found which would indicate this isn't the truth?

nb: you mean "cite". why would you make me do this? you can doxx people on your own dime... still, for posterity: https://news.ycombinator.com/item?id=18328964 "...now I am working full time as a Rust developer" https://news.ycombinator.com/item?id=18310666 "As a long time Erlang developer..." https://news.ycombinator.com/item?id=18265199 "As someone who has worked two jobs now writing, deploying, and operating Erlan…

I guess I'm glad that someone sits around looking through comment histories skeptically, but I don't see what about these comments seem suspicious to you.

Re: Thoughts on Rust, a few thousand lines in

#134

Post by fxfan »

steveklabnik wrote: post #78
sephoric wrote: post #76

Earlier quoted context omitted.

What's the point of the [] version then? It seems inherently more dangerous, and Rust emphasizes safety. I know it wants to be pragmatic as well as safe, but this seems like a strange default.

There's a few things that come into play here: First of all, panics are perfectly safe. None of this has to do with safety guarantees. Second, the [] syntax is controlled by the Index trait, which returns an &T, not an Option . It does this due to Rust's error handling philosophy. There's two kinds of errors: recoverable and unrecoverable errors. When something shouldn't fail, unless there's a bug, you shouldn't be u…

Scala programmers would recognize this as the difference between () and .get(). I hope rust copied scalas syntax- its much cleaner, rather than trying to be nice to the established system languages (c/c++)

This would also free up the [] to be used for generics and avoid syntactical warts like :: parsin

Re: Thoughts on Rust, a few thousand lines in

#135

Post by UncleEntity »

v_lisivka wrote: post #122
hinkley wrote: post #97

Earlier quoted context omitted.

This seems specious to me. The only way to get an invalid index in a string in any language is that you either have an array index arithmetic error or you are blindly operating on a string you haven't validated . If you want all the data after a : character, you slice on the index of the :. The character after it is going to be the beginning of a UTF-8 character. You do not under any circumstances guess that the colo…

I just realized that I have bug in my GPS driver. It operates on ASCII data, so [] operator is safe, BUT data can be corrupted (low chance, but non-zero), so it can form valid multibyte character, so my code will panic on it, trying to parse and validate NMEA message.

Panicking on parsing corrupted data seem like a feature to me...

It's like the default rule in a lexer, if it ever gets to it then it's an unrecognized character and lexing stops so error handling can proceed.

--edit--

Which I now realize was probably your point.

Re: Thoughts on Rust, a few thousand lines in

#136

Post by burntsushi »

StavrosK wrote: post #132
pornel wrote: post #96

Earlier quoted context omitted.

It's not a problem in practice, because you'd use something like `.char_indices()` iterator, or result from a substring search, etc. to get correct offsets in the first place. It's not useful to blindly read at random offsets in UTF-8 strings. If it didn't panic, you'd get garbage. If offsets were automatically moved to skip over garbage, you wouldn't know what you're getting, and your overall algorithm would likely…

What does zero-cost mean in this context? It must cost something to run, no? Or is it basically a compiler hint instructing the next function to treat the data as pure bytes?

In this particular context, you can think of going from a `&str` to a `&[u8]` via `string.as_bytes()` as a safe cast. The in-memory representation remains the same, and the function call will almost certainly be inlined because its implementation is trivial.

Re: Thoughts on Rust, a few thousand lines in

#137

Post by fxfan »

f2f wrote: post #105
daboross wrote: post #91

Earlier quoted context omitted.

Could you site this? I've looked at ilovecaching's comment history (at least up to ~60 days ago) and they seem consistent on being a networking programmer who uses C++. Was there a particular comment you found which would indicate this isn't the truth?

nb: you mean "cite". why would you make me do this? you can doxx people on your own dime... still, for posterity: https://news.ycombinator.com/item?id=18328964 "...now I am working full time as a Rust developer" https://news.ycombinator.com/item?id=18310666 "As a long time Erlang developer..." https://news.ycombinator.com/item?id=18265199 "As someone who has worked two jobs now writing, deploying, and operating Erlan…

I think what you're posting definitely sounds suspicious and a lot of rust users are doing it for the hype but.

1) rust genuinely is a great language and his opinion in the comment is something I have as a professional c++ programmer or the past

2) his comment history is only suspicious and only mildly, there's nothing outright contradictory. I would give him the benefit of doubt.

Re: Thoughts on Rust, a few thousand lines in

#138

Post by TheCoelacanth »

brianberns wrote: post #83
steveklabnik wrote: post #78

Earlier quoted context omitted.

There's a few things that come into play here: First of all, panics are perfectly safe. None of this has to do with safety guarantees. Second, the [] syntax is controlled by the Index trait, which returns an &T, not an Option . It does this due to Rust's error handling philosophy. There's two kinds of errors: recoverable and unrecoverable errors. When something shouldn't fail, unless there's a bug, you shouldn't be u…

Does Rust support a monadic coding style (like Haskell "do" blocks or F# computation expressions)? That would allow you to work with Options without having to explicitly unwrap them.

Not generic monads, but it does have the `?` operator for Option (similar to Haskell Maybe) and Result (similar to Haskell Either) which would support a similar syntax to using `do` with the Maybe monad

Re: Thoughts on Rust, a few thousand lines in

#140

Post by oconnor663 »

hu3 wrote: post #127
steveklabnik wrote: post #123

Earlier quoted context omitted.

Panics are memory safe, so that’s still more safe than many parsing bugs.

The issue does not mention memory safety and neither did I. Honestly, knee-jerk reactions like "BUT MUH MEMORY SAFETY" doesn't inspire confidence specially when it couldn't help saving that dev from the troubles and bugs documented in the issue. To quote a few: > it was a hassle to track down because Rust itself didn't complain and the panic message during serialization wouldn't tell me which file of the hundreds of…

Safe in rust usually has a very specific meaning: https://doc.rust-lang.org/nomicon/what-unsafe-does.html
Post reply on HN