Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
1–10 of 47 posts
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#2It is great when there is a standard that works well for everyone.
It is great when there is competition to that bloated monopoly everyone currently uses.
I don't understand my own cognitive dissonance on this topic.
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#3Rust indeed does have an embarrassing excess of diversity problem, made worse by the fact that async isn't in the standard library (outside bare minimum stuff like Future) and async libraries can't really be async runtime neutral. (This is going to improve with async traits.)
It's probably an inevitable result of Rust having a thinner standard library than Go, Java, C#, or other heavier languages. It's supposed to be systems language after all.
Another reason though is that Rust is a rich language with a very powerful type system, and rich powerful languages invite programmers to show off. One of the greatest things about Go is how boring it is. It doesn't give you a lot of room to show off by writing clever code, so instead you have to show off by making a great application. But some of this is unavoidable if you want what Rust delivers: a near-zero-overhead systems language with hard safety and automatic memory management without GC. That's dumping a heavy load on the type system, and Rust does deliver pretty well.
I try to exercise discipline when writing Rust and not show off by being more clever than I need to be. I do write some hand-whittled performance code here and there in high-performance applications, but I try really hard to avoid using unsafe. I've found that you usually can.
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#4Rust indeed does have an embarrassing excess of diversity problem, made worse by the fact that async isn't in the standard library (outside bare minimum stuff like Future) and async libraries can't really be async runtime neutral. (This is going to improve with async traits.) It's probably an inevitable result of Rust having a thinner standard library than Go, Java, C#, or other heavier languages. It's supposed to be…
> It doesn't give you a lot of room to show off by writing clever code, so instead you have to show off by making a great application.
I agree with your comment as a whole, but I have also seen plenty of dumb Go code. hey, lets toss out all compile time type checking:
https://johnstarich.com/go/pipe/pkg/github.com/johnstarich/g...
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#5> Do huge swaths of Rust users value vanishingly small performance gains over memory safety, in a language that prides itself on being able to provide speed and safety?
I mean, yeah, probably? It was meant to appeal to people who were still writing things in C/C++, who are by definition people with those values. For general-purpose use the language was always "OCaml but with vanishingly small performance gains".
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#6Rust indeed does have an embarrassing excess of diversity problem, made worse by the fact that async isn't in the standard library (outside bare minimum stuff like Future) and async libraries can't really be async runtime neutral. (This is going to improve with async traits.) It's probably an inevitable result of Rust having a thinner standard library than Go, Java, C#, or other heavier languages. It's supposed to be…
> by the fact that async isn't in the standard library
I wish async/await were not in the language
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#7It is great when there is a standard that works well for everyone. It is great when there is competition to that bloated monopoly everyone currently uses. I don't understand my own cognitive dissonance on this topic.
[dead]
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#8> or even just skipping blank lines, hyper does things its own way.
Ugh. IMO a bit benefit of Rust is that you can’t do wild-west-YOLO buffer twiddling without “unsafe,” so people will write better code.
But it really looks like httparse missed the memo.
https://github.com/seanmonstar/httparse/blob/v1.8.0/src/iter...
iter::Bytes looks like an awkward wrapper around slices with all the safety removed. So you can port nasty C-style code right over.
Seriously, it should not be hard to efficiently strip a prefix off a u8 slice in safe Rust. For example, split_first.
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#9> Simpler is better: Complex problems require complex solutions, but we should strive for simplicity in our software. Code is a liability—less code is less that could go wrong, and less to debug when things do go wrong!
This seems to confuse complexity with features. If a library has 100k lines of code but the parts you use are only 1k lines of code then why is that worse than a library with 1k lines of code?
> I want a single HTTPS connection. I don’t need persistent sessions with connection pools and cookies. I don’t need an async runtime.2 I need a glass of scotch, a socket, and a few syscalls. In the same vein,
That's true right until the moment you do need them and then you need to rewrite a lot of code. Especially great fun when the thing you're connecting to assumes everyone has this feature and you spend hours or days debugging things.
Modular, popular and well structured libraries with all the features one might reasonably need are my preference. Minimalism in lines of code is as much a trap as a minimalism in benchmark performance.
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#10Rust indeed does have an embarrassing excess of diversity problem, made worse by the fact that async isn't in the standard library (outside bare minimum stuff like Future) and async libraries can't really be async runtime neutral. (This is going to improve with async traits.) It's probably an inevitable result of Rust having a thinner standard library than Go, Java, C#, or other heavier languages. It's supposed to be…
> by the fact that async isn't in the standard library I wish async/await were not in the language
However other people wished it was. So here we are.