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

Things Rust shipped without

graydon2.dreamwidth.org

Post reply on HN
Print view View original

191–200 of 330 posts

Re: Things Rust shipped without

#191

Post by agentS »

eddyb wrote: post #183
agentS wrote: post #179

Earlier quoted context omitted.

For servers that primarily speak RPC or HTTP, do you foresee Rust going thread-per-request or something more callback-y?

Neither. Existing successful solutions use tight event loops (the "Reactor pattern": https://stackoverflow.com/questions/3436808/how-does-nginx-h... ). There is a Rust library called "mio" which provides a lot of the plumbing for such systems: https://github.com/carllerche/mio . The path forward is likely going to involve adding a way to build cheap state machines (call them generators or async/await) with a clean sy…

> ... Reactor pattern ...

I don't understand, and the link seems unclear. Perhaps a more direct question: I get a request X, and I need to consult a backend service to answer the request. Do I write synchronous code calling that backend? Or do I have some callback mechanism?

> ... generators or async/await

Ah. This perhaps answers my question. Both of these are essentially compiler-written callbacks.

If this is going to be like C#, then I presume there will be a thread-pool where user code will execute. It seems like a non-ideal story for concurrency. Users will have to take inordinate care not to call any blocking code; otherwise they will prevent one of the threads in the pool from doing useful work.

Re: Things Rust shipped without

#192

Post by gilgoomesh »

asveikau wrote: post #75
Skalman wrote: post #59

Earlier quoted context omitted.

It's an encoding that isn't good at anything: it's neither ASCII-compatible (like UTF-8), nor fixed-length (like UTF-32), but because most characters require only 2 bytes, developers frequently assume that none require more, leading to bugs when a character eventually is represented by 4 bytes.

> fixed-length (like UTF-32), Utf-32 is only fixed length if you don't care about diacritics, variation selectors, RTL languages, and others. Unicode is not one code point or one char/wchar/uint32 per glyph.

You've changed topic from code points to grapheme clusters. Rust's character/string support is strictly for code points (the documentation is fairly clear about the distinction).

Few string libraries actually deal with grapheme clusters as the native underlying representation (Swift being a notable exception).

Re: Things Rust shipped without

#193

Post by sidarape »

asveikau wrote: post #75
Skalman wrote: post #59

Earlier quoted context omitted.

It's an encoding that isn't good at anything: it's neither ASCII-compatible (like UTF-8), nor fixed-length (like UTF-32), but because most characters require only 2 bytes, developers frequently assume that none require more, leading to bugs when a character eventually is represented by 4 bytes.

> fixed-length (like UTF-32), Utf-32 is only fixed length if you don't care about diacritics, variation selectors, RTL languages, and others. Unicode is not one code point or one char/wchar/uint32 per glyph.

My life is a lie.

Re: Things Rust shipped without

#194

Post by jlarocco »

I'm sorry, but I have a hard time being impressed by any of those. They're all just fixing things that were busted in C.

I mean good for Rust, but C is a pretty low bar. Does any language created in the last 20 years make those same mistakes?

Re: Things Rust shipped without

#195

Post by [deleted] »

steveklabnik wrote: post #109
veddan wrote: post #104

Earlier quoted context omitted.

Still, there are cases where fall-through can be useful: int remaining = length % 4; switch (remaining) { case 3: h ^= (data[(length & ~3) + 2] & 0xff)

https://github.com/pythonesque/fallthrough can emulate the fallthrough style if you really, really want to have it. It seems like it hasn't been updated in a while, though.

[deleted]

Re: Things Rust shipped without

#196

Post by Jweb_Guru »

steveklabnik wrote: post #109
veddan wrote: post #104

Earlier quoted context omitted.

Still, there are cases where fall-through can be useful: int remaining = length % 4; switch (remaining) { case 3: h ^= (data[(length & ~3) + 2] & 0xff)

https://github.com/pythonesque/fallthrough can emulate the fallthrough style if you really, really want to have it. It seems like it hasn't been updated in a while, though.

In the post-1.0 world, a repository not having been updated for a few months doesn't automatically mean it no longer works :P

Re: Things Rust shipped without

#197

Post by pcwalton »

giovannibajo1 wrote: post #178
pcwalton wrote: post #174

Earlier quoted context omitted.

Yes, that's what I meant by "strictly slower". At best, it can be optimized to something similar to what RAII can give you. RAII never has the overhead of the bad case.

I don't want to be excessively picky, but you said that is has "unavoidable runtime overhead", and that's true only in its rarest form (defer within a loop), which is a feature which you can't implement in RAII. IOW, defer is a superset of RAII. In all other cases (which is almost all usages), it is semantically equivalent to RAII, so the language doesn't force any runtime overhead. The only difference is that the co…

defer isn't a superset of RAII. defer is function-scoped. RAII is block-scoped. If you want to run code at the end of a block, you can do that with RAII and you can't do that with defer—and note that this is what causes all the codegen issues with defer.

Re: Things Rust shipped without

#198

Post by yazaddaruvala »

andrepd wrote: post #12

What about things that Rust shipped without that should have been included?

I really wish Rust/stdlib had been built around a good async io story. Right now it just feels neglected "because the crates ecosystem can deal with it".

I might be wrong here but it always seemed to me that Rust was built to replace C/C++ in critical infrastructure like Firefox, Nginx, Redis, etc. Basically critical network dependent infrastructure.

With respect (because I understand the difficulties that come with time constraints/resourcing/building an efficient async API), currently I'm not sure how Rust expects itself to be a viable replacement (let alone the best replacement) language for any of those types of applications.

Re: Things Rust shipped without

#199

Post by pcwalton »

agentS wrote: post #191
eddyb wrote: post #183

Earlier quoted context omitted.

Neither. Existing successful solutions use tight event loops (the "Reactor pattern": https://stackoverflow.com/questions/3436808/how-does-nginx-h... ). There is a Rust library called "mio" which provides a lot of the plumbing for such systems: https://github.com/carllerche/mio . The path forward is likely going to involve adding a way to build cheap state machines (call them generators or async/await) with a clean sy…

> ... Reactor pattern ... I don't understand, and the link seems unclear. Perhaps a more direct question: I get a request X, and I need to consult a backend service to answer the request. Do I write synchronous code calling that backend? Or do I have some callback mechanism? > ... generators or async/await Ah. This perhaps answers my question. Both of these are essentially compiler-written callbacks. If this is going…

> It seems like a non-ideal story for concurrency. Users will have to take inordinate care not to call any blocking code; otherwise they will prevent one of the threads in the pool from doing useful work.

The downsides of going M:N are worse. The cgo-like FFI performance problems, for example, are killer for Rust's use case.

Re: Things Rust shipped without

#200

Post by pcwalton »

Sanddancer wrote: post #188
lmm wrote: post #82

Earlier quoted context omitted.

Consistency is valuable. If some blocks have different rules to other blocks that's a real downside.

A foolish consistency is the hobgoblin of little minds. Sometimes a variation in rules allows for more clarity -- one could set their editor to make return a different color, for example, making it easier to glance at program flow. Then again, I'd argue that closures should allow returns too, like they do in C#. I'm an adamant supporter of the explicit camp -- when you have to debug things at 3 in the morning, someti…

Closures do allow returns in Rust.
Post reply on HN