Live data from Hacker News

Was Rust Worth It?

jsoverson.medium.com

661–670 of 736 posts

Re: Was Rust Worth It?

#661

Earlier quoted context omitted.

Can you help understand why somebody wouldn't use Tokio/why it didn't "win"?

Tokio isn't the fastest conceivable runtime. Tokio isn't the smallest conceivable runtime. Tokio isn't the simpilist conceivable runtime. Tokio does not port to all conceivable environments. Tokio isn't the async-std runtime. And so, for some or all of these reasons, right or wrong, various Rust libraries wed themselves to runtimes other than Tokio. You can thunk around these things, but it's miserable, yielding subt…

Is this to say async-std is faster + smaller + simpler + more portable than Tokio?

Re: Was Rust Worth It?

#662
post #231

I wrote a lot of rust, but after some years it still feels unproductive. I do a lot of zig now and I am like 10 times more productive with it. I can just concentrate on what I want to code and I never have to wonder what tool or what library to use. I know rust gives memory safety and how important that is, but the ergonomic is really bad. Every time I write some rust I feel limited. I always have to search libraries…

You should try diving into num for like a month and see how you like it. It's different enough that you need to go past a certain kind of ledge to start liking it. Or at least that was my experience. For me, it shares the most important benefits of Rust but with quite a lot more ergonomic coding model.

Nim on paper is great; it has many advantages over Rust in the general purpose "niche". Tragically, it's kind of stillborn. It's older than Rust, has orders of magnitude less mindshare, and has no companies with serious technical reputations backing it.

Re: Was Rust Worth It?

#663
post #12

Earlier quoted context omitted.

And the horrible decision to not make library-level ("module") and code-unit-level ("package") namespacing orthogonal. The former was an afterthought tacked on since the package system was designed to be used only within Google's monorepo and little care was paid to how it would work when it was released to the public and used more generally.

I want to understand what you just said, but I fear watering your language down a bit might be a tall ask with some people. Would you be willing to eli5 what you believe Go did that was a horrible decision with regards to module/package namespacing?

I think what they mean is: if you see a line like `import git.example.com/foo/bar/baz`, that could be package `baz` inside module `git.example.com/foo/bar`, or it could be package `bar/baz` inside module `git.example.com/foo`.

Also, even if you know it's the latter, package namespacing isn't strictly related to directory structure, so `bar/baz` has no specific meaning outside of the context of a go import. They could have used any other separator for package components - `git.example.com/foo:bar:baz` - but instead they chose the slash, making the scheme both technically ambiguous and easy to confuse for an HTTP URL.

Re: Was Rust Worth It?

#664

Earlier quoted context omitted.

https://play.rust-lang.org/?version=stable&mode=debug&editio... In this case, the first two errors are clear. The next 3 provide multiple, redundant context blocks. The upshot is that this simple example results in rustc printing 11 lines of useful error messages and 86 lines of useless messages. Add to that the fact that the useful error messages need not be at the top or bottom of the error list, they can be anywhe…

That is a different problem than the one I thought you were seeing. We do spend a lot of time trying to silence errors that are irrelevant. We also get a lot of complaints when fixing a single error produces a wave of new errors that were hidden due to failures in earlier stages. It's a balancing act. Also, specific errors are verbose in order to give people a fighting chance to fix their issue. An error that is too…

> Could I ask you why you didn't consider doing so when you first encountered this problem?

Thanks for looking into it. I have a filed a bug against Rust before, but that was a clear bug, not a poor error message. Remember, the only time a user sees something like this is when they are trying to do something else. The only reason I looked into it just now is because you explicitly asked.

Re: Was Rust Worth It?

#665

Earlier quoted context omitted.

> Everything is a Box >. This is closest to dynamic garbage-collected languages, but with vastly improved performance. Why the `Box`?

Mostly to mimic the data structures allowed in languages where objects are held by reference. In Python, I could write a tree structure as `namedtuple(“node”, [“lhs”, “rhs”])`. If I tried to write a similar structure in Rust as `enum Node{Leaf, Branch(Node, Node)}`, the compiler rightfully complains that it would have an infinite size. But the indirection introduced by Box would let it be stored as `enum Node{Leaf, B…

I think what the previous poster is pointing out is that Box> is an unnecessary double indirection.

Re: Was Rust Worth It?

#666
post #643

Earlier quoted context omitted.

> Rust is not completely memory safe since it let's you disable the borrow checker. No, it doesn't. What's interesting isn't so much that random HN posters believe this sort of thing, because hey, who needs to know anything about a topic to post their opinion on a forum right? No, what's fascinating is that this applies to people like Herb Sutter in his "cpp2" language, here's Herb: > I don’t like monolithic "unsafe"…

fn trust_me_i_dont_need_a_borrow_checker (x: &'a mut u32) -> &'b mut u32 { unsafe { core::mem::transmute(x) } } fn main() { let mut owned = vec![40, 2]; let mut_1 = trust_me_i_dont_need_a_borrow_checker(&mut owned[0]); let mut_2 = trust_me_i_dont_need_a_borrow_checker(&mut owned[1]); drop(owned); let undefined = *mut_1 + *mut_2; println!("The answer is {undefined}"); }

If unsafe disabled the borrow checker, you wouldn't have needed that transmute. But it doesn't, so you needed the unsafe transmute to make this work.

Re: Was Rust Worth It?

#667

Earlier quoted context omitted.

There's a clear distinction between someone who writes the code and everyone else in the world who works with the outputs of your code. Doesn't feel that way to me.

I'm sorry you're having a bad experience. I've found changing a couple habits developed in other languages helped me to have a good experience with Rust's diagnostics. 1. Reading the error messages. I was used to error messages verbosely printing a lot of details which were mostly irrelevant and letting the programmer sort it out, and I developed a habit of skimming them. I had a better time with Rust when I realized…

No thanks, that seems a long winded way of saying you're not welcome here unless you think exactly like me.

Re: Was Rust Worth It?

#668

Earlier quoted context omitted.

> Too many important low-level crates stuck at 0.x. Is it fair to say that Rust failed to supply a robust set of standard libraries comparable to other modern languages? Or was the language aimed at level geared towards implementing rather than providing libraries? If it's truly a systems language, then what library features are essential, and what are 'nice to have'?

There was a conscious decision to avoid providing a vast standard library because those inevitably become outdated with time. Building a standard library is relatively easy, maintaining for decades is hard. But it’s a trade off because there are concrete upsides to a large standard library. I wrote about this more - Rust has a small standard library (and that’s ok) - https://blog.nindalf.com/posts/rust-stdlib/

That does seem to align with my perception of where Rust wants to be: a low-level systems language. For example, the stdlib provide a time package that deals with duration and instant, sufficient to interact with file systems and such, but leaves dealing with dates, times, and all that complexity to the chrono crate.

What I would encourage the Rust community to focus on is adding security-sensitive functionality to the standard library. Not the big wad of complexity that is cryptography, but a standard PRNG/RNG/CSPRNG would fit.

Also, I do think it's a bit of a mistake to not at least define a relational database API. As it is we have sqlite, mysql, and postgres with similar but slightly different APIs.

Re: Was Rust Worth It?

#669
post #181

Earlier quoted context omitted.

> A conforming C++ compiler is forbidden from telling you in some† unknown number of cases that it suspects what you've written is nonsense, it just has to press on and output... something. It's not quite that bad - a conforming C++ compiler is permitted to error out and not compile the program. It just doesn't have to.

Many of the cases of IFNDR are semantic constraints, especially in C++ 20 and beyond. As a result of being semantic constraints it's generally impossible to diagnose this with no false positives. The ISO standard forbids such false positives so...

Can you give a more concrete example of the kind of thing you're talking about? Like, if you try to sort something and your comparator implementation for that type is not transitive, the compiler can silently produce a broken binary?

Surely in the undecidable cases the compiler is allowed to produce a binary that errors cleanly at runtime if you did in fact violate the semantic constraint, and any sane implementor would do that. (Not that any sane person would ever write a C++ compiler...)

Re: Was Rust Worth It?

#670

Earlier quoted context omitted.

A note on putting the hot path into C component: Writing performance-sensitive code in C/C++ and calling it via interop used to be the way to go during .NET Framework days but since then has become a performance trap. Especially for small methods, calling them through interop is a deoptimization because they cannot be inlined, and involve GC frame transition (which you can suppress) as well as an indirect jump and ma…

Thanks, I haven't had to do dropping to C for a while as the improvement in performance of dotnet along with features like AOT, Span etc close the gap enough for the domain I work in. Good to know you can remain within the framework and get decent performance though with the unsafe pointers/refs. Would be interesting to see a good benchmark using only C# with latest features and Rust, although I cognisant of the fact…

Rust standard library is far more conservative when it comes to vectorization and auto-vectorization is far more fragile than people think, both links - they beat it in performance significantly ;)
Post reply on HN