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

31–40 of 183 posts

Re: Thoughts on Rust, a few thousand lines in

#31

Post by dbaupp »

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

String slicing using byte indices has to exist in some form, since it is the only thing that is efficient (O(1)). But, I guess it could have used syntax other than somestring[...].

Re: Thoughts on Rust, a few thousand lines in

#32

Post by Thiez »

gpm wrote: post #23
cphoover wrote: post #10

I've not done any rust dev before but the whole variable shadowing thing really scares me, in that it makes it not obvious where the initial declaration comes from. This seems difficult to reason about.

I've done a fair bit of rust development and never found that to be an issue. It probably helps that the only ways to introduce new variables are all very distinctive: let [new variables] = [expr]; if/while let [new variables] = [expr] { [new variables scoped here] } for [new variables] in expr { [new variables scoped here] } fn name([new_variables]) { [new variables scoped here] }

You forgot `match` and closures. But in general I think new variables can be created in all contexts where a pattern can be used.

Re: Thoughts on Rust, a few thousand lines in

#33

Post by pmarreck »

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

Does this bug exist because it would be too expensive to check every string before slicing? (Being Rust-ignorant), can you not type a binary as UTF-8? Are there 2 versions of string functions, fast ones that assume ASCII and slow ones that assume UTF-8?

Re: Thoughts on Rust, a few thousand lines in

#34

Post by ilovecaching »

I'm a network engineer, and I've done C++ for over a decade now. One of the nice things about Rust is that they decided to go with async over fibers, which is in line with how most high performance C++ is written. The Rust team also isn't rushing Future out the door, so it's coming along much nicer than the C++ Future, which is usually replaced because it's not monadic.

Rust is great, and I highly recommend learning Rust if you want to become a better C++ developer. C++ introduces a lot of unnecessary headaches Rust completely solves. Rust is worth the switch if only because reading error messages from expanded templates is horrible compared to type system that actually understands type parameters.

I'm really bullish on Rust becoming even more mainstream, to the point anyone can pick it up and use it in their business without a second thought by 2020.

Re: Thoughts on Rust, a few thousand lines in

#35

Post by steveklabnik »

pmarreck wrote: post #33
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...

Does this bug exist because it would be too expensive to check every string before slicing? (Being Rust-ignorant), can you not type a binary as UTF-8? Are there 2 versions of string functions, fast ones that assume ASCII and slow ones that assume UTF-8?

Every string is checked. But UTF8 is a multi-byte encoding, and slicing works per bytes, so you if you slice in the middle of a multi-byte character, you may get nonsense. The error happens because of this checking, not in spite of it.

String always assumes full UTF-8. You could make an AsciiString type if you wanted, but it's not provided by the standard library.

Re: Thoughts on Rust, a few thousand lines in

#36

Post by hamaluik »

StreamBright wrote: post #15
UK-Al05 wrote: post #13

Earlier quoted context omitted.

You can't mutate variables in rust without declaring mut

But how do you know just by reading that code? It would not be obvious to me at all.

I guess if you don't know rust you might not? But one of the first things you learn about rust is the `mut` keyword.

Re: Thoughts on Rust, a few thousand lines in

#37

Post by steveklabnik »

kazinator wrote: post #30

> Like Go, Rust can compile statically linked linux binaries. The GNU C library (needed not only by C programs for C things) doesn't support static linking, so the only way this is possible is to use another library entirely, or raw inlined syscalls (where applicable).

Yes, we have full support for MUSL. It's a

  $ rustup target add x86_64-unknown-linux-musl
  $ cargo build --target x86_64-unknown-linux-musl
away.

Re: Thoughts on Rust, a few thousand lines in

#38

Post by [deleted] »

pmarreck wrote: post #33
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...

Does this bug exist because it would be too expensive to check every string before slicing? (Being Rust-ignorant), can you not type a binary as UTF-8? Are there 2 versions of string functions, fast ones that assume ASCII and slow ones that assume UTF-8?

[deleted]

Re: Thoughts on Rust, a few thousand lines in

#39

Post by steveklabnik »

Thiez wrote: post #32
gpm wrote: post #23

Earlier quoted context omitted.

I've done a fair bit of rust development and never found that to be an issue. It probably helps that the only ways to introduce new variables are all very distinctive: let [new variables] = [expr]; if/while let [new variables] = [expr] { [new variables scoped here] } for [new variables] in expr { [new variables scoped here] } fn name([new_variables]) { [new variables scoped here] }

You forgot `match` and closures. But in general I think new variables can be created in all contexts where a pattern can be used.

Yes, in fact, it's always a pattern. Even let x = 5; is a pattern, just a very simple one!

Re: Thoughts on Rust, a few thousand lines in

#40

Post by gamegoblin »

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 is a common pattern in Rust to use [] for things that cannot fail and will panic otherwise and a method for things that can fail and return Option or Result.

e.g. my_hashmap["foo"] will panic at runtime if the key "foo" is not present, or return the associated value if it is. But my_hashmap.get("foo") will return None if "foo" is not present and Some(value) if it is.

Post reply on HN