Live data from Hacker News

Thoughts on Rust, a few thousand lines in

rcoh.me

171–180 of 183 posts

Re: Thoughts on Rust, a few thousand lines in

#171

Earlier quoted context omitted.

That's not trivial and different languages vary in how they handle new line characters even. https://stackoverflow.com/questions/44995851/how-do-i-check-...

You can still split non-ASCII text on ASCII newlines, and quite often that's exactly what needs to be done.

And usually, you don't want it to cost O(n) on top of whatever parser you ran to find those newlines.

Re: Thoughts on Rust, a few thousand lines in

#172
post #63

Earlier quoted context omitted.

It's not clear to me what you're suggesting; is it that String shouldn't have supported indexing in the first place? That code does work, but you have a &[u8] not a &str.

But neither AsciiString. It has a as_str method, but it's still a kludge. This example was basically a suggestion to throw0u1t: if they want to cut in the middle of the utf-sequence for whatever reason, they can [edit:] do it without extra crates. What I don't understand is why slices are indexed in bytes and not in objects. If String has an ability to check that we're cutting in the middle of the character sequence,…

It does: `s.chars().take(3)`. It just does it with iterators rather than with indexes because that better communicates the performance characteristics.

Re: Thoughts on Rust, a few thousand lines in

#173
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…

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…

I agree with you. I guess the best solution would be something in between “await” and goroutine.

My understanding is the main issue with “await” model is that you only abstract The Task model.

Running task don’t gave a real ID and stack like “Go” and “Erlang” you can list all running fiber how much memory and CPU they use ...

I believe you could write your own event loop easily in Go if they exposed the internal api used to pause and resume goroutine, you can already pause goroutine by having them wait on a mutex and resume them from your custom event loop by releasing that mutex.

Re: Thoughts on Rust, a few thousand lines in

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

Goroutine are very different from thread in practice.

you don’t have to pay the memory usage and context switch cost you would have if using large amounts of threads.

It’s also faster to do IO processing from a single thread in batch instead of having one OS thread per request.

Re: Thoughts on Rust, a few thousand lines in

#175
post #174

Earlier quoted context omitted.

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.

Goroutine are very different from thread in practice. you don’t have to pay the memory usage and context switch cost you would have if using large amounts of threads. It’s also faster to do IO processing from a single thread in batch instead of having one OS thread per request.

Context switches on I/O are the same for 1:1 and M:N because you're eating the cost of a kernel to user context switch either way.

Memory usage per thread is a property of the GC, not M:N threading. You can have very small stacks in a 1:1 implementation too.

Re: Thoughts on Rust, a few thousand lines in

#176
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…

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…

> Rust at one time had a fiber model, but it was removed in favor of Futures.

No, fibers were removed with nothing to replace them. The futures as we know them today did not exist in the far, far past when fibers and the whole runtime thing got dropped.

Re: Thoughts on Rust, a few thousand lines in

#178

Earlier quoted context omitted.

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

Any idea how it handles indexing? Does it convert everything to 32 bit chars and ignore graphemes?

Re: Thoughts on Rust, a few thousand lines in

#179
post #143

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…

Futures and fibers are not mutually exclusive, as shown in the latest (2018) Oracle Code One keynote speech, where they demoed project Loom (basically you can wrap a fiber in a CompletableFuture, in the same fashion you can wrap a thread/execution context and expose it in a CompletableFuture). That being said, the JVM team seem to have come to a similar conclusion that using fibers is the least invasive way in terms of syntax as compared to async.

Re: Thoughts on Rust, a few thousand lines in

#180

Earlier quoted context omitted.

Couldn't syntax like `a_string[..3]` be made to result in compilation errors in Rust? Since that'd almost always be a bug? (right?) And in the rare cases, when it's not a bug, then one can just use `as_bytes` which would be good to do in any case, to indicate to other humans that this is not a bug. B.t.w. I love the error message `[..3]` generates: "thread 'main' panicked at 'byte index 3 is not a char boundary; it i…

We could have never implemented Index for String, sure. We have though, so removing it would be a breaking change.

Ok (Maybe a compile time warning? that doesn't break the build)
Post reply on HN