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

141–150 of 183 posts

Re: Thoughts on Rust, a few thousand lines in

#141

Post by paulddraper »

fxfan wrote: post #134
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…

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

Scala and C++ syntax are rather similar, no?

Re: Thoughts on Rust, a few thousand lines in

#142

Post by TheCoelacanth »

da_chicken wrote: post #80
steveklabnik wrote: post #35

Earlier quoted context omitted.

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.

The obvious follow up question would be: so why is slicing a string a byte-wise operation and not a character-wise operation? If a string is an array of characters, why does it let me refer to individual bytes without explicitly casting it to a byte array? How often comparatively do you want the nth byte compared to the nth character? I would suspect that's pretty rare.

How often do you actually want the nth character as opposed to the nth grapheme?

There is pretty much no case where indexing by character actually makes sense because it is almost always incorrect and it is always inefficient.

Indexing by byte is rarely useful, but it does have some usefulness since it can be used correctly and efficiently since you can easily find the next or previous character by searching a maximum of four bytes for the a byte that has a MSB of 0. If you want to do something like get a &str that would fit in a n-byte buffer, then byte indices will let you do that efficiently and correctly.

Re: Thoughts on Rust, a few thousand lines in

#143

Post by skyde »

ilovecaching wrote: post #34

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 am a big fan of rust but I don’t think the Async using the ”await” keyword or using Future/promis is the way to go.

I wrote a large web app in scala using Futur only and it turned into a monster because of it. Even if you don’t use callback you still need to manualy unwrap them and they pollute your méthode signature.

Then more recently I wrote a pub/sub server in c# using the “await” keyword. While much better it still polute your method signature and make the debugger and stacktrace useless. Also you still have to think about trying to no make anything that could block spinlock or calling api that are not Async ex: Createfile

Compare this to Golang where project like Groupcache (1) have super clean code that replaced a thousand line of code C++ system at google.

Why do you think Golang fiber/gorotine are worse ?

(1) https://github.com/golang/groupcache

Re: Thoughts on Rust, a few thousand lines in

#144

Post by pcwalton »

skyde wrote: post #143
ilovecaching wrote: post #34

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 am a big fan of rust but I don’t think the Async using the ”await” keyword or using Future/promis is the way to go. I wrote a large web app in scala using Futur only and it turned into a monster because of it. Even if you don’t use callback you still need to manualy unwrap them and they pollute your méthode signature. Then more recently I wrote a pub/sub server in c# using the “await” keyword. While much better it…

Goroutines are just threads, with a particularly idiosyncratic implementation. You can use threads and blocking I/O in Rust too.

You wouldn't want a Go-like M:N solution in Rust. It would be slower for no reason.

Re: Thoughts on Rust, a few thousand lines in

#145

Post by comex »

dkarl wrote: post #70
richardwhiuk wrote: post #64

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…

Indexing a Unicode string is cheap... if you have a byte index. If you want to count out some fixed number of codepoints, then of course you've just moved the cost to calculating the corresponding byte index. But counting codepoints is almost always the wrong thing to do anyway [1]. In practice, it's more common to obtain indices by inspecting the string itself, e.g. searching for a substring or regex match. In that case, it's faster for the search to just return a byte index; there's no benefit to having it return a codepoint index, and then having to do an O(n) lookup when you try to use the index. And byte indices obtained that way will always be valid character boundaries, so you can use [] without worrying about panics.

You suggest just using a byte array instead, but then you'd lose the guarantee that what you're working with is valid Unicode. Contrary to your assertion, it is useful to have a type that provides that guarantee, yet which can still be operated on efficiently.

[1] https://manishearth.github.io/blog/2017/01/14/stop-ascribing...

Re: Thoughts on Rust, a few thousand lines in

#146

Post by comex »

pcwalton wrote: post #144
skyde wrote: post #143

Earlier quoted context omitted.

I am a big fan of rust but I don’t think the Async using the ”await” keyword or using Future/promis is the way to go. I wrote a large web app in scala using Futur only and it turned into a monster because of it. Even if you don’t use callback you still need to manualy unwrap them and they pollute your méthode signature. Then more recently I wrote a pub/sub server in c# using the “await” keyword. While much better it…

Goroutines are just threads, with a particularly idiosyncratic implementation. You can use threads and blocking I/O in Rust too. You wouldn't want a Go-like M:N solution in Rust. It would be slower for no reason.

> You wouldn't want a Go-like M:N solution in Rust. It would be slower for no reason.

Depends on how many threads you have and what OS you’re running on.

Re: Thoughts on Rust, a few thousand lines in

#147

Post by harrisi »

bsder wrote: post #99
stabbles wrote: post #45

Earlier quoted context omitted.

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?

Languages that only have floats, such as JavaScript and Lua, certainly sort floats quite often.

Re: Thoughts on Rust, a few thousand lines in

#148

Post by ilovecaching »

skyde wrote: post #143
ilovecaching wrote: post #34

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 am a big fan of rust but I don’t think the Async using the ”await” keyword or using Future/promis is the way to go. I wrote a large web app in scala using Futur only and it turned into a monster because of it. Even if you don’t use callback you still need to manualy unwrap them and they pollute your méthode signature. Then more recently I wrote a pub/sub server in c# using the “await” keyword. While much better it…

The answer to this question is quite involved. As you may already know, Rust at one time had a fiber model, but it was removed in favor of Futures.

One big advantage of Futures is they are decoupled from their execution environment.

For example, different types of executors can be used depending on the type of Future. For example, you may have an IOThreadPoolExecutor to handle accepting and responding to connections that should spend very little time blocking and a CPUThreadPoolExecutor for offloading heavy processing. In Go, you have no say in how goroutines are scheduled, you sacrifice control to reduce complexity.

Another big one in network programming is the polling mechanism. In Go, you have no control over your polling mechanism, whereas with a Future is decoupled from the event loop, and you can write your own event loop on any experimental kernel APIs you'd like.

Rust made the right move because in Rust, just as in C++, we want maximum control. Futures are more primitive, and it's possible to build coroutine models on top of them, but not vice versa.

Re: Thoughts on Rust, a few thousand lines in

#149

Post by AlphaSite »

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…

Python does something similar with [] vs .get()

Re: Thoughts on Rust, a few thousand lines in

#150

Post by atombender »

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…

Talk about cherry-picking. It's pretty clear from those comments that they've worked with Erlang before, as well as Haskell and C++, and that they've transitioned to use Rust.

For example, in the same comment that begins with "As a long time Erlang developer", they later continue: "I’m more optimistic about Rust ... We’ve been able to scale Rust to handle the same load as our Erlang cluster". So there's no contradiction here.

Post reply on HN