Live data from Hacker News

Thoughts on Rust, a few thousand lines in

rcoh.me

91–100 of 183 posts

Re: Thoughts on Rust, a few thousand lines in

#91
post #88

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…

i admire you: you change your occupation every couple of days, as well as the languages you've replaced rust for :)

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?

Re: Thoughts on Rust, a few thousand lines in

#92
post #89

One thing Rust doesn't seem to be doing very well yet is guard clauses, specifically when handling Option . I've seen and appreciated the use of guard clauses in many languages, as a good way to quickly check for a few conditions at the top of a function, and return early if those conditions aren't met. Since it seems that Option are recommended in Rust, there's a lot of time you want to quickly return if `Some(x)` i…

You can use ? on an Option if your type returns an Option. If it returns a Result, you can use ok_or()?, and at some point in the nearish future, you can just use ?.

Re: Thoughts on Rust, a few thousand lines in

#93

Earlier quoted context omitted.

let foo = bar; let foo = bat; is shadowing let foo = bar; foo = bat; is a compilation-time error because foo isn't mutable. let mut foo = bar; foo = bat; is reassignment. in working code, either foo is declared as mutable or it's not, and it's pretty obvious from the code what's happening.

I guess. I would just never write code like that.

[deleted]

Re: Thoughts on Rust, a few thousand lines in

#94

Earlier quoted context omitted.

Go indexes bytes on strings, even though there's a builtin type called Rune which delimits utf-8 codepoints. This is yet another footgun. Is there a language that doesn't handle this poorly? https://play.golang.org/p/CkBp0w8T621

UTF-8 is at odds with efficient array indexing. I like pythons approach where bytes and strings are distinct types, though I have no idea what it is doing under the hood.

I actually had to work with Python strings at the C level recently, and their approach is pretty clever. IIRC, the runtime can take any common form of Unicode, and will store it. When you access that string, the accessor requests a specific encoding, and the runtime will convert if need be, and then store it in the string object.

So it handles the (very) common case of needing the same encoding multiple times (e.g. for all file paths on Windows), while not introducing too much overhead in memory or speed.

I could be mistaken on exact details though, especially since I recall there being multiple implementations even within py3.x.

Re: Thoughts on Rust, a few thousand lines in

#95
post #50

Rust is one of the few times where the language/ecosystem does precisely what I wished it would do. For instance, being able to partially destructure JSON into a struct in a typesafe manner is just awesome.

This sounds really useful, you don't happen to have an example of this do you? Thanks in advance!

https://gitlab.com/zanny/oidc-reqwest/blob/master/src/token....

You can declare structs that derive from Serde and convert to / from Json in a typesafe way.

Re: Thoughts on Rust, a few thousand lines in

#96

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 end up with nonsense (duplicated or skipped chars).

For algorithms that don't care about characters or UTF-8 validity, there's zero-cost `.as_bytes()`.

Re: Thoughts on Rust, a few thousand lines in

#97

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

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 colon is at position 6 in the string. That's not safe. Why are you going cowboy in a language that is so obsessed with safety?

Re: Thoughts on Rust, a few thousand lines in

#98
post #70

Earlier quoted context omitted.

Slicing on characters is a linear time operation and indexing is meant to be cheap.

That seems like taking it too far. It's like using pointer arithmetic to index a linked list on the assumption that the nodes happen to be allocated contiguously in memory. I mean, I guess the thinking is, indexing a Unicode string isn't cheap, but indexing strings used to be cheap once upon a time, when strings were encoded in fixed one-byte-per-character representations, so let's pretend that's still the case and p…

Safety is about memory safety. Immediately exiting your program is about as memory safe as it gets.

Re: Thoughts on Rust, a few thousand lines in

#99
post #28

Earlier quoted context omitted.

I'm curious as to why it isn't implemented in hardware. Is it really so rare to need to sort floats, or so common to need a different ordering when you do?

Of course sorting floats happens a lot. In practice one rarely encounters NaN's and ±Inf's, so fast comparison for concrete values is the default. I don't know why the 'slow' total order is not implemented in hardware though. But fortunately in comparison sort algorithms that run in O(n lg n) you can get away with doing an O(n) partitioning of the array into [-, +, NaN] and then applying a fast integer comparison ope…

> Of course sorting floats happens a lot.

Is this true?

I am actually struggling to remember the last time I did a sort with a float/double as the key--especially in a performance bounded context

... ...

Aha. Graphic engine. Octtree with coordinates.

I really had to think about that.

So, I'm a bit skeptical of float sorting happening a "lot".

Is this perhaps an ML primitive somewhere?

Re: Thoughts on Rust, a few thousand lines in

#100

Earlier quoted context omitted.

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.

TIL! I'm still learning Rust so it's good to learn this now! Thanks!

One approach to solve the slicing issue: https://play.rust-lang.org/?version=stable&mode=debug&editio...
Post reply on HN