Hacker News Reader

Comment by mordnis | Hacker News Reader

Well, for example, every function that allocates expects allocator as an argument, it is not abstracted away. Resource deallocation is not abstracted away, you have to explicitly free your resources. Ever function that uses IO expects it as an argument. It doesn't have operator overloading, which is also an abstraction.

It is a very explicit language.

View on HN

I left the "mostly" in my comment because custom allocators is one area where Rust as an ecosystem is still in need of some work, and I'm aware of that - hell, in part because of TigerBeetle's blog posts on the subject.

Everything you're describing is a stylistic preference, though - and doesn't contribute to bloat, which is what the parent comment was implying. If your program is bloated, that's on you to clean up - it doesn't matter if it's in C, C++, Rust, or Zig. Every single one of these languages has nothing that stops you from getting it right.

(A weird aside but the downvotes on this chain are just odd to me. I'm not telling y'all to not write Zig, chill already)

Look, I'm working on an async I/O engine, not unsimilar to Tokio. I started running benchmarks only to realize that I'm significantly faster than Tokio. Go, which is a garbage collected language with preemptive scheduling, is also faster than Tokio on these benchmarks. And Tokio is fast, I'm not claiming it's not. Rust developers program in terms of traits, and borrow checker behaviours. That's fine if you want enterprise kind of safety by tooling. It's just not enjoyable to me and that seems fairly common view. There are people who enjoy languages like Rust, Scala, Haskell. They allow you to create your own world in the type system and that's fine, but it is more disconnected from the actual computer the code is running on.

I was hacking on a thing in Rust that beat Tokio pretty significantly in some benchmarks. There seems to be a lot of overhead introduced by it.

> I started running benchmarks only to realize that I'm significantly faster than Tokio.

In single threaded, sure. To my knowledge you're not faster in multi-threaded contexts.

> Rust developers program in terms of traits, and borrow checker behaviours.

You don't have to do that, though. People have experimented with other approaches besides what you see in e.g tokio.

Local allocators are also in the works for Rust, as well as a general effect system (including potentially an IO effect). Rust also doesn't have fully general operator overloading, it currently uses traits instead. (Though explicit local notations are generally a better way of handling operator semantics, and a future edition of Rust could potentially achieve this via macros.)

Reply on news.ycombinator.com