Zig as an alternative to writing unsafe Rust(zackoverflow.dev) |
Zig as an alternative to writing unsafe Rust(zackoverflow.dev) |
The benefits of Rust's (wonderful) model around references and lifetimes come at a significant cost to ergonomics when having to go into the Mordor of some C library and back. I usually find myself wishing I could have some macro where I just write in C and have it exposed as an unsafe back in Rust. I know I can do this by just writing a C dylib and integrating that, but now I've got two problems.
Even still, I prefer writing unsafe Rust to writing C. std::mem::ptr forces me to ask the right questions and reminds me of just how easy it is to fall into UB in C as well.
In D you can just import a .c file mycfile.c with:
import mycfile; // C file filled with C functions
I'm not sure it's what you're looking for, but it seems like a good starting point.
As for the general thrust of your comment and the article, I agree. It'll be interesting to see what changes come to make things nicer.
This transpiles C to Rust at compile time, though it requires a nightly compiler and hasn't been updated in some time. But it's exactly what you're looking for. C code in, unsafe Rust code out.
This freaks me out the most in networking code, where there is all kinds of casting of structs (esp. if you blindly copy-paste examples from StackOverflow) and performance usually matters. Rust has inspired me to take more time to profile C code to see whether strict aliasing (strict overflow, etc.) actually make a significant enough improvement to merit the UB-risk, review time, and acid in the stomach.
There’s a macro for doing this with Assembly, I can imagine one could be made for C. But why wouldn’t you just write unsafe rust at that point?
Writing basic data structures isn't a niche, esoteric edge case. There may be a crate that "solves" what you're trying to do. But does it rely on the std---(i.e., is it unusable for systems programming)? Is it implemented making gratuitous copies of data everywhere? Does it have a hideous interface which will then pollute all of your interfaces? Does it rely on 'unstable' features?
Then, there's the 'community.' It seems to consist solely of extremely online people who get a dopamine hit from both telling people they're doing things wrong and creating the most complex solutions possible. They do this under a thin veneer of forced niceness, but it's not nice at all.
I don't think this is correct: Rust makes writing unsafe Rust correctly more onerous than writing C, but the actual rules for undefined behavior are the virtually same as in C: if you alias where you must not, or mutate where you must not, etc. you're in exactly the same boat.
In other words: Rust makes it hard to write unsafe Rust correctly, but no harder than writing well-defined C. The only difference is that Rust raises the safety expectations by default, making unsafe Rust look more difficult than C.
OK, for a garbage collector, maybe you have to, because you're taking over memory management yourself. But very, very rarely do you need to do that. And when you do, you need very thorough testing, test tools, and documentation.
I just got done chasing someone else's pointer bugs with valgrind and gdb, in C code from a public crate three levels down from my code. Valgrind was useful in locating the area of trouble. The code there had too much unnecessary pointer manipulation, and offsets obtained from input which might be un-initialized memory. This never happens in safe Rust. Which is the whole point.
Most things for which C programmers use pointer arithmetic can be expressed as slices. Slices are pointer arithmetic, but with size information and sound rules.
(I'm a bit cranky this week. I've spent the last few weeks finding bugs in Rust crates that ought to Just Work.)
If rust can pair with a proof checker and let user write some correctness proof, it can be way more useful than the current borrow checker.
Though I think at that point you might as well formally verify zig as a means to get memory safety, resource provenance, and data race safety.
The idea that memory safety must be baked into the type system is belief by the existence of provenance tracking macro/crate in rust since that exists specifically to track memory in unsafe; rust is basically 'discovering' a need to inventing what zig will need to invent for memory safety.
The only way we can do proofs (on certain things) is restricting code, like non unsafe rust.
If it would be feasible, why wouldn’t we just continue to use C and be happy with our verified C codes?
And do you have any examples of where UB from unsafe rust leaks to outside the program? Surely you would look back at the unsafe code always to fix it.
1. You don't need to refcount everything. In Swift objects have to be refcounted and heap allocated. In Rust you only use it selectively in cases where shared ownership is really necessary, and otherwise still have an option of using exclusive ownership, value types, etc.
2. You can still borrow Rc's contents locally and use it as a plain reference, so hot loops and leaf functions don't pay the price. Often you may need to touch the refcount only once when building a data structure or passing data to a closure, and then on use it via a temporary reference. In Swift the refcount is updated much more often, and there are only limited cases where ARC optimizer can skip it.
I was already using debug allocators in Visual C++ 5.0, with a memory report at the program exit.
For the latest documentation,
https://learn.microsoft.com/en-us/cpp/c-runtime-library/crt-...
I realise that these VMs are going to be totally idiomatic Zig/Rust, with the most straightforward implementation possible, and little-to-no performance tuning, but even so - that's gotta be a typo, right? Or it's actually finding `fib(350)`? Or each "run" is actually finding `fib(35)` 100 (1000?) times?
(I eyeballed the assembly to make sure the native implementation was recursive, but that's the extent of my rigor - consider these napkin numbers.)
I should have been expecting it. You're testing the performance of the runtime, not the program, so of course you want a bad implementation of the algorithm to stress the runtime as much as possible.
(My tail-call Python implementation tops out at fib(997) in 720ms. Calling fib(998) gives me a "RecursionError: maximum recursion depth exceeded". AIUI python is never going to optimise away tail calls, but because the tail-call variant is O(n) anyway it still works out orders of magnitude faster.)
Try it here, I had Bing AI write it out - https://play.rust-lang.org/?version=stable&mode=release&edit...
The boundary is awkward and creates complexity.
I wrote a post about problems writing a garbage collector in C++, e.g. annotating the root set, and having precise metadata for tracing.
http://www.oilshell.org/blog/2023/01/garbage-collector.html
https://news.ycombinator.com/item?id=34350260
I linked to this 2016 post about Rust, which makes me think the problem could be worse in Rust, although I haven't tried it:
http://blog.pnkfx.org/blog/2016/01/01/gc-and-rust-part-2-roo...
I didn't write as much about bindings to native C++ code, but that's also an issue that you have to think about carefully. CPython has kind of been "stuck" with their API for decades, which exposes reference counting. So it's extraordinarily difficult to move to tracing GC, let alone moving GC, etc.
---
On the other hand, there was also a paper that said Rust can be good for writing GCs.
Rust as a Language for High Performance GC Implementation
https://dl.acm.org/doi/pdf/10.1145/2926697.2926707
However, I'm not sure it addresses the interface issue. One lesson I learned is that GCs are NOT modular pieces of code -- they have "tentacles" that touch the entire program!
That said, C++ is pretty good at "typed memory" as well, and I think it's more pleasant than C. That is, you get more than void* and macros. So I can believe that Rust has benefits for writing GC.
Not sure about Zig -- I can believe it's a nice middle ground.
(Safe) Rust indeed limits the user to a compile-time deallocable subset of what’s expressible (RC being an escape hatch), which depending on the problem domain may be too limiting.
I’m willing to forgoe certain rust features in exchange for simplicity.
https://web.archive.org/web/20230307172822/https://zackoverf...
Don't get me wrong, it's great to have this directly enabled in "safe" mode like Zig does it. But to use that to say Zig is more safe is extremely misleading.
var ptr: [*]u8 = @ptrCast([*]u8, &slice[0]);
var ptr = slice.ptr;
Or am I missing something
I wonder if *mut [u8] would be a workable alternative to &mut [u8]. I haven't looked into creating such pointers yet, but `fn f(a: *mut [u8]) {}` is legal while `fn f(a: *mut [u8]) { a.len(); }` doesn't compile on stable due to https://github.com/rust-lang/rust/issues/71146. Looks like raw slice pointers aren't fully baked yet.
Bun repo is filled with issues surrounding segfaults, but I guess it gave them the advantage to get up and running quickly.
So, saying, that e.g., Zig is generally better or worse than Rust doesn't make any sense to me, as both Languages have a different purpose.
I would much rather use Rust to write a Webserver (in production) than in Zig, simply because Rust serves this purpose better than Zig does. And i personally can consider Zig to be my favourite Language.
I would also never (at least right now) write Website frontends in either Zig or Rust, i think JavaScript in this case, is the obvious choice, because it has been developed (over years) for this (and unfortunately other) use case(s).
I have never read anything that suggest or argued Zig as better than Rust, or "Rust vs Zig". Not on HN, not on Reddit, not on Twitter. In fact this link / title is the first one. ( I do wish the title was "Unsafe Rust" to better reflect on the content. )
There are however plenty who still prefer Zig over Rust, even knowing when Rust is better.
I also want to note RESF generally does not consider "unsafe" Rust to be Rust.
Edit: LOL I knew this would be heavily downvoted.
I've observed that certain programming languages have a culture of complexity. I'm not sure why this is. I can only speculate its because these programmers are working on "boring" problems so they make busy work for themselves OR their beginners who think this is how "real programmers" work.
While I think calling them "idiots" is a bit strong, I think this quote from the late Terry A. Davis is worth remembering: “An idiot admires complexity, a genius admires simplicity [...] for an idiot anything the more complicated it is the more he will admire it, if you make something so clusterfucked he can't understand it he's gonna think you're a god cause you made it so complicated nobody can understand it.”
I think go is a good example for this fallacy, it claims that it is a simple language, but ad absurdum asm should also be trivial to understand as every line is also easy to grasp, right? Low expressivity just creates chaotic complexity, won’t reduce it.
It's a bargain. Rust is pretty great, but it doesn't make some things easy because it would make everything else hard.
This comment is amusing, mostly because Perl is so full of tradeoffs. Do you want to write something to do some string parsing quickly? Great language, maybe. Do you want to understand what you've written later? Maybe not so great.
> Writing basic data structures isn't a niche, esoteric edge case.
Not if you're using C, because the batteries are definitely not included. Want a resizable array, or hashmap? The answer is DIY. Not in the std library. Whereas all are provided by default in Rust. Picking a basic data structure off the shelf is a pretty nice feature for most applications.
That said -- should you really need a custom implementation of a linked list, and you need to write and rewrite such an implementation all the time -- I'd understand if Rust wasn't your first choice.
> Then, there's the 'community.'
And I'm not sure anyone loves this attitude either. Keep it technical.
Still, we, the Rust community, should take the high road and respond to the criticism by assuming that it's valid and asking what we can do better. I, for one, don't want developers to reject my Rust-based library because of the community's reputation, especially once my library has a C API.
If I didn't include that proviso, I'd have someone arguing with me to the death about how I'm completely wrong and an idiot who doesn't understand the Correct Way of doing things.
I totally disagree with that claim. The easy thing to do is not use unsafe Rust. You can use stringly-typed datastructures with lots of refcounting or copying, just like Perl, without ever venturing into unsafe Rust.
> Writing basic data structures isn't a niche, esoteric edge case. There may be a crate that "solves" what you're trying to do. But does it rely on the std---(i.e., is it unusable for systems programming)?
In what world is Perl suitable for systems where possible memory allocation is a problem?
Maybe it isn't an edge case (although it should be) it also isn't `easy` in a non GC'd language, and a huge source of memory bugs.
I wouldn't say it makes the 'easy stuff hard' as much as the 'hard stuff appropriately difficult'.
writing data structures _properly/well_ was never easy
it just looks easy and is nearly always a sub-par solution
e.g. a list in many lisp like languages seems simple, until you look under the hood what magic tends to be used by more advanced compilers to make that list work fast
the think people most commonly got wrong which was supposedly easy when programming when I was school/stadium where data structures, even comparatively simple ones like double linked lists
it's like sorting, sure you find docents easy to implement sorting algorithms everywhere, but then when you look at the properly implemented sorting build ins of standard libraries their complexity is hundreds of times that of quick sort or similar
It very much should be though! That's exactly the type of thing that should be written once by someone who knows what they're doing, and then reused 1000000 times. People slapping together a quick data structure is a huge problem in C.
* Why does C# require a break; under switch?
* What about the "Most Vexing Parse"?
* Why does Zig change capitalization of @import and @TypeOf?
Rust is an extremely "guessable" language. It's highly likely that experimenting with syntax will succeed in Rust, which is a syntax feature that I have seen nowhere else.
The Rust borrow checker imposes a style that is safe, but is not the only safe way to write that program.
> Writing basic data structures isn't a niche, esoteric edge case.
Writing basic data structures isn't "easy stuff" in any low level language. It isn't in Zig by any means, nor in C nor in C++
Similarly, in Rust you have to be careful to never instantiate a value that is out-of-range for a given type (e.g. a bool with value > 1), even if you will never read or access that value before it is changed to something valid. In C this same concern does not exist since it is not insta-UB in the same way.
Sure they do: C has a well-defined notion of const-correctness. If you mutate through a `const`, you're invoking undefined behavior.
Both C and C++ allow you to strip `const` from a const-qualified value or reference, but only under the condition that you don't actually modify that value.
Edit: which, in case it isn't clear, means that Rust's UB is exactly the same as C's in this case.
const int x = 123;
const int *px = &x;
(*(int*)px) = 456;
1. Creating a mutable reference when there's other references to the same memory around, even if you don't use/deref that mutable reference, is considered UB in Rust; References there have the `dereferenceable` LLVM attribute, so the compiler is allowed to insert use/derefs at will to facilitate optimizations [0]. C's pointers are more like Rust's raw pointers: they only have to be valid upon use not at creation.
2. References in Rust are transient (as noted in the blogpost) so holding a mut ref to T means you also hold a mut ref to all its fields/subfields semantically. If you're doing intrusive or self-referential data structures, it often requires having UnsafeCell fields to soundly create isolated mut refs from top-level shared refs. Problem being that core, language-level traits in Rust like Iterator and Future (generated by async blocks) take mut refs so implementing them (which is practically useful) on types with intrusive fields potentially being used elsewhere is UB [1]. This doesn't exist in C with no `dereferenceable` & opt-in `restrict`. It's still an unresolved issue in Rust though [2] where they had to disable LLVM annotations on problematic types/traits to avoid miscompilations [3]. Some of these footguns can be avoided by not using references and the core language traits (like the blogpost did), but they found that to not be a great programming experience.
3. Because of `dereferenceable` (again) instances of a type must be valid in-memory representations at all times, even when unused [4]. If you want invalid/uninit representations, you wrap the type in `MaybeUninit` which is fairly unergonomic. C doesn't have this issue as its only UB to deref invalid pointers or branch on invalid values (same case in Rust), not have invalid values at all.
[0]: https://github.com/rust-lang/rust/issues/94133
[1]: https://gist.github.com/Darksonn/1567538f56af1a8038ecc3c664a...
[2]: https://github.com/rust-lang/rust/issues/63818
If you're looking for a full blown SMT solver and general purpose dependently-typed PL have a look at F*
int x = 123;
const int *px = &x;
(*(int*)px) = 456;
I say "basic" in quotes because once you factor in the concurrency, ownership and memory safety concerns that are optional in other languages, but mandatory in Rust, there really isn't a simple implementation of these structures that is provably correct anymore.
TypeOf returns a type. Corresponding to how type names are uppercase.
I have to disagree. I think this meme/issue has been talked to death. And I'm sure I find retrograde, sour-pussing about Rust just as distasteful as others find dewy Rust optimism. The answer is -- they're both silly. Draw the line at speaking about the tech or the comment or person in front of you. Speaking about stereotypes in "communities" is about as vacuous as a Valley Girl's/Perl programmer's head[0].
[0]: a joke!
Anyway, shit posting aside. I do agree with them that the Rust community is a bit eager to suggest rewriting stuff in Rust.
However... I think this has always been the case for every developer who likes a language. I've seen Ruby devs talk with a passion for Ruby, and Elixir devs about Elixir, and Haskell devs about Haskell. You get the point.
Except I suspect Rust just incredibly grids the gears of some C++ devs. I see how it can be irritating, especial if they've decided C++ is the language they "settled in" with. There's the implied (and irrational) existential threat that this new technology is going to ruin their future prospects. This is probably subconscious and also completely irrational. C++ is too big and too commercialised to go away anyway.
I've seen a similar thing when TypeScript was being adopted and I was pushing for TypeScript (or Flow) adoption at work.
Some people seemed to have an allergic reaction to any mention of TypeScript.
There was people calling the TypeScript community toxic, immature, incompetent, holier-than-thou for arguing why types make code easier to maintain and write. And some of the arguments were they don't want to use the language that had such a childish community.
Edit: On second thoughts I feel a bit like an asshole too, and a bit regretful and ashamed I stooped so low to even write this comment. Others wrote more level headed replies than I did, too. Anyway, let it serve me as a reminder not to engage with trolls in the future.
It was like this during the Usenet flamewars on C vs C++, and while I rejoice most C compilers now being written in C++, there are a few domains where C++ failed to take over C.
Rust advocacy strike force would do better to learn from history of programming languages adoption.
The only reason why some are suggesting they haven't seen RESF recently, is because it has gotten to the point where the backlash, which used to be a minority and voiceless finally becomes the mainstream. And so they back down.
And to the original question, and in my previous comment, when was the last time you saw people telling you to use Zig in a Rust thread? ZERO. The comments are mostly, if not 99% about how they couldn't deal with Rust's complexity, they call themselves an idiot and they only wanted a Better C, which the answer to that question is always Das C, Zig or some other contenders. In which Rust Fans will always find it offensive. Even mentioning Ada / SPARK being a languages aiming for correctness is somehow "trolling". And it is not the first time I have been told to stop mentioning Ada.
And yet, how many times has Rust Supporters came into a Zig thread ( or other language ) telling the world how Zig / X is memory Unsafe and Rust does it better? To the point so detrimental that they founder of Zig is crying or begging publicly to give Zig the language some breathing space?
And finally I want to add, HN has a link for front-page [1] where you could visit every post that was listed in the front page. And comments as well as user post are not deleted unless specific circumstances which requires Dang to manually operate. i.e All the evidence are still there.
Because it's a better answer than smearing a group of people.
> So I should tolerate your ideals while you have zero tolerance with mine? Does it sound familiar to some real world Silicon Valley politics?
I will say that your argument does feel like modern American politics in one way I notice -- it's all about vibes. It doesn't have anything to do with anything technical. It's all about how people (sometimes transitively) made you feel. And I'm sorry someone made you feel that way, but I'm not sure the way you're acting is conducive to feeling any better.
Rust isn't hard just for fun. It's hard because the code you've been writing for so long is actually bad and you've not been thinking it through appropriately. This is why we keep finding serious bugs in code that is decades-old, despite the belief that code so old must be well-tested by now.
I'm sure of one thing: we will find many and different bugs in decades old rust code one day, too. The problem with software is that it has code in it ;-)
I believe the tradeoff for this in Rust’s niche is absolutely acceptable, but it is still a tradeoff and might not be the correct choice in certain cases.
Sometimes Rust makes things hard because the invariants you want to express cannot be cleanly mapped onto Rust's type system. I described one such case here: https://blog.reverberate.org/2021/12/19/arenas-and-rust.html
(I've yet to see a C or C++ codebase where object provenance actually guarantees this; I've see a lot of C and C++ codebases with const-stripping induced UB.)
It’s not useful criticism to simply say “this community was such-and-such”. I’d expect them to do better. Speak specifically to people saying something you disagree with. Don’t let it fester within you and then take it out on a broad group.
And I know you didn’t do any of this, but you did seem to be defending some pretty low quality behaviour.
I would better argue that "your Rust program runs on top of my millions of lines of C code, so please pass to my C API a pointer or a reference to a pointer so I can screw it up, and now all your safe code guarantees are out of the window".
Also, using a (hopefully) well-tested library that someone wrote is absolutely a good (and only significant, as per Brooks) way to increase productivity - but also correctness! Do I really have to write a matrix library myself? Sure, I can probably write a function that multiplies two matrices, but will it have sane numerical stability? [1]How can I even test that out? It is a whole separate field, where I likely overestimate my knowledge about. Was it really worth that extreme amount of time to write an almost surely buggy and slower implementation than depending on someone else’s work?
The art of programming is also about knowing when to reach for other tools.
[1] Hell, multiplying multiple matrices already “needs” a dynamic programming algorithm to decide how to associate pairs of them
I don't agree with this. We also have stinginess and stubborness as potent weapons against complexity. If we are stingy with our time and effort then we insist on getting much use out of every tool we learn. We are stubborn, and so we do not add new tools quickly, or throw old ones away quickly, and we are skeptical of easy solutions. tldr: first cut away needless complexity, then use abstraction on what remains.
Rust also has const generics (but they are still a bit shabby in places last time I used them).
I for one never liked the constexpr semantic and syntax. Always felt like a... Little pebble in my shoe. Didn't quite annoy me enough not to use it since it was useful, but it was never a comfortable experience.
It is one of my favourite languages, but I also acknowledge that C compatibility is a big pain point for security.
No access to performant generic data structures is a major reason why truly performance oriented programs rather choose C++ over C.
I don't understand why this argument keeps coming up. Not all bugs are the same and when you make entire classes of bugs unrepresentable, that's a massive win, especially when they happen to be the class containing >60% of the highest severity bugs in C.
https://www.chromium.org/Home/chromium-security/memory-safet...
buffer overflows [0] [1], use after frees [2] [3], and other memory bugs [4] [5] [6] can appear in safe rust from unsound unsafe internals.
[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2887...
[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000...
[2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3116...
[3] https://github.com/rustsec/advisory-db/blob/main/crates/cros...
[4] https://github.com/rustsec/advisory-db/blob/main/crates/toki...
[5] https://github.com/rustsec/advisory-db/tree/main/crates/
From the link you’re sharing
> Fortunately, they are context-sensitive library APIs that are not usually used in a way that the bugs can be triggered. Many of them require very specific interaction to trigger (e.g., partially consume an iterator and zip() it with another iterator) that is not likely to appear in their daily usage.
Here’s a concrete example that shows the difference between how different languages approach CVEs. Rust is not the only language affected by this TOCTOU bug (https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html) but other languages finesse it by saying “all bets are off when you’re interacting with the filesystem”. Therefore no CVE for them, while Rust ends up looking insecure in the eyes of those who count CVEs.
What I’m saying is - don’t count CVEs without looking at the context and content of those CVEs. Don’t assume that some software is secure simply because they don’t file CVEs, because that’s an ostrich approach.
My point wasn't that rust is bug-free, but that certain classes of bugs will not exist in the safe portion, which significantly reduces attack surface.
Additionally, my point was to compare languages without safety guarantees like C to safe rust. Your statement is true, but it doesn't do anything to counter what I'm saying, which is that entire classes of bugs (namely the most common critical c bugs) are not found in safe rust, which is still the case.
Worded another way, within the boundaries of safe rust, you will not find a cause of a memory corruption bug. Things that can be the cause memory bugs include: unsound unsafe rust, c, kernel-level manipulation, random bit flips, malicious hardware, etc etc. I consider none of those to be bugs in safe rust, and additionally, they can cause bugs in all other programming languages as well.
I think there is a strong argument to be made that if you need a lot of unsafe, Zig is going to be the safer language.
I could see that. Haven't used zig but it does look very nice.
> in many places where unsafe ends up required
Yes, I definitely agree. I was specifically referring to the boundary of safe rust. I don't know how much more or less safe unsafe rust is vs c, but I do know that safe rust is certainly safer than c.
Not comment should be read as argument or part of a debate for or against using Rust or any other memory safe language. I made the comment because I've seen tool after tool come about to end the scourge of bugs in software... and so far my unconscious, untrained ability to find new and spectacular ways to create bugs has exceeded the ability of the makers of bug prevention tools to stop me.
The CVEs are counted as they're memory issues (not only logical issues) that can technically surface in safe Rust code and are also considered UB in other languages (those which finesse other conditions to be "unspecified" instead of "undefined") too.
CVEs have rating systems to better interpret their relevance. Whether these ratings incorporate how easy it is to trigger or how practical the damage could be is subjective. They primarily report potential exploits, not a standard for judgement. All this nuance though was lost with the parent commenter claiming "zero memory bugs in safe rust".
> Don’t assume that some software is secure simply because they don’t file CVEs
I agree. This extends across all languages. Another warning to add is that high profile security bugs can still occur without memory safety issues (with wormhole/dao exploits being practical examples).
Neither of us agree with a blanket assertion that code written in Rust is flawless and free of bugs.
This can be easily disproved by looking at the bugs fixed in the Rust compiler and standard library, and looking at open soundness issues in the Rust issue tracker.
I think CVEs are useful in tracking the security of your code, but can’t be meaningfully compared between languages. Different languages and ecosystems have differing bars on what needs a CVE.
The important takeaway is that while Rust and Rust code in general aren’t perfect, they’re still substantially better than the alternatives. Better is hard concept to convey and get people to buy into. They see a couple of bugs and say “well, there’s bugs either way so what difference does it make”.
For higher level domains where unsafe isn't required and some runtime overhead is acceptable, I believe there's real cases to be made that Rust can be substantially better than the alternatives; Can prevent logical UAF with borrowing, bound checks may be mostly elided, enforced language level checks for nullability like Option<&T> and valid values in general like enums, explicit error handling, etc.
For lower level domains however, I'm not sure that argument is as easy. Anecdotally, I work almost exclusively on systems like databases, schedulers, allocators, and similar. There, memory efficiency is an explicit feature via tricks that either Rust's borrow checker really doesn't like or are very awkward to do with its unsafe APIs; Non-linear/concurrent object lifetimes, self-referential & intrusive data structures, and reinterpret casting being the big ones.
If rust code makes it harder to do those things, while also providing little (never none) benefit over the alternatives (for reference, both Zig & Rust have checked {integer ops, slice access, nullability}, sum types, metaprogramming, rich error combinators, etc.) then it's harder to make the claim Rust is substantially better.
That said, your concerns are pretty valid, widely echoed and are being taken seriously. Writing unsafe code is a chore and it needn't be. I'm hoping the newly created Operational Semantics team (https://www.rust-lang.org/governance/teams/lang#Operational%...) makes progress here.
* Types in Rust use prefixing to create derived types whereas C family languages generally use postfixing. A pointer is i32, not int; an array [i32; 5], not int[5], etc. This makes special characters appear more heavily at the beginning of the scan line, and probably makes them slightly more noticeable as a result.
* Lifetimes have the form 'a, and that single quote is likely to bother a lot of people (I know it bothers me).
* Unqualified name lookup in Rust is a bit weaker than other languages, which makes the scope operator (::) more common.
* Passing in explicit generic type arguments for a function requires an extra :: for seemingly no reason.
* Similarly, macros require an explicit ! in the name to invoke. Given that println! (and formatting in general) is a macro and not a function, this means you get a lot of extra uses of ! that's unexpected for C family code.
* Again, the try operator (also decently common) is another random special character.
* Attributes also use #[] syntax, or sometimes #![]. While C++11 did use [[]] to designate its attributes, it's also something that always felt a bit ugly to me personally (I find the @Decorator() pattern from Java or Python to be a visually cleaner way to do attributes).
In short, Rust generally has a higher density of special characters than other C family languages, and I think that contributes to a sense of ugliness.
There is a very good reason for this. Behold, the Bastion of the Turbofish.
https://github.com/rust-lang/rust/blob/master/tests/ui/parse...
I think the thing people don't like about Rust is that it looks vaguely C-like but is clearly not C. People might like it better if it was further removed (aesthetically) from C's syntax. But then they would also complain.
I think there was no way for Rust to meet all its semantic goals and also make people happy about the syntax.
C++ on the other hand also is vaguely C like, but can look equally messy as typical Rust code.
OTH I find Makepad's Rust style very readable, but I can't quite put my finger on it what's different from other Rust code bases:
By removing the ugly "syntax" (and thus also removing important semantics), they're showing that the reason Rust has a lot going on syntactically is because the code is actually expressing important semantics. You can't have a nicer Rust syntax without losing semantics in the process.
var foo []my_struct = {{"foo", 1, "bar"}, {"foo", 1, "bar}, ...}
let foo = [MyStruct{a: "foo", b: 1, c: "amp"}, MyStruct{a: "bar", b: 1, c: "fff"}, MyStruct{a: "amp", b: 1, c: "aaa"} ];
const foos = [("foo", 1, "bar"), ("foo", 1, "bar"), ...];
for (str1, num, str2) in &foos {
// ...
}
Rust is more on the verbose/explicit side and I agree that can sometimes be annoying, but as autocompletion exists I can live with it.
I'm really new at Rust, but that was my takeaway, e.g. `String` has `String::new()`
These feature enablement blocks drive me crazy. You could go from codebase to codebase and it's almost like you are working in a different language depending on how many of these are enabled or not. I've been trying rust on and off since it's release, and I still have yet to feel like I have a grasp on some "core" subset of the language I can fall back on to solve most of my problems. I always have to scour documentation for the hot new thing to turn on or do, and this isn't to scorn innovation and change, but it does get exhausting at some point.
(Please release a spec)
(Though I do agree that Rust definitely moves fast, which is sort of understandable as a relatively newish language)
If you end up with a long::run::of::module::names, I find it all just blurs into one.
int foo(int a, float b);
fn foo(a: i32, b: f32) -> i32;
Or look at an array declaration:
int arr[5];
This kind of argument of course goes all the way back to AT&T vs Intel assembly syntax and I am firmly on Intel's side.
Pascal, Modula, and Ada are all type on the right languages and were also very influential in the historical development of programming languages. I happen to prefer types on the right for complex declarations. Note that Pascal and Modula were designed by Niklaus Wirth after he created Algol W; it seems he preferred types on the right.
Also this is an no-win situation. C++, Ruby, Perl, and others have used `::` as module-scoping syntax for decades. If Rust does something novel, it's penalized for being unfamiliar. If Rust uses syntax for which there's ample prior art, it's apparently line noise. If rust used a `.` as a separator, it's unclear if you're descending into modules or calling a function chain.
There's literally no way to win.
This is especially true when there's similarly named items from different paths. Best example is `Result`/`Error` types. eg: std::io::Result vs normal default Result vs other crate's Result type. Another example would be math types like Vec2 between game engine and egui. String in mlua vs std rust etc..
Usually you can get around this by importing it with a different name like `use mlua::String as LuaString`. but it is still something that you need to actively do.
> If rust used a `.` as a separator, it's unclear if you're descending into modules or calling a function chain
Interestingly, from the zig documentation:
Zig source files are implicitly structs, with a name equal to the file's basename with the extension truncated. @import returns the struct type corresponding to the file.
Yes there is? Follow what C#, F#, Java, TypeScript, etc. do
If I was to think about it: comparing rust to zig, zig benefits a lot from error and optional types having their own syntax rather than being treated like any other type. For example a return type of:
Result<Option<usize>, Error>>
!?usize
Disclaimer: I'm a zig fan and contribute monetarily so please weight anything I say on zig vs rust with that in mind. (I do write rust at work though)
The absence of default args is a deliberate choice, notice that Rust does have default type arguments in polymorphism, the absence of defaults for function parameters -- which would be technically easy to implement -- reflects a belief which I've come to agree with that overloading is a bad idea, and defaults most often in practice mean you're overloading.
For example, C++ std::ranges::binary_search uses defaults to present what are in effect at least two distinct features, as a single function, suiting C++ sensibilities, whereas Rust reflect almost the same capabilities as three functions []::binary_search []::binary_search_by and []::binary_search_by_key
For a very simple binary search, things seem pretty similar. In Rust we have a single parameter, for our searched-for element, and in C++ we can stop after that parameter, leaving the comparison function and projection as default for similar effect.
However for binary_search_by the C++ is contorted by this API shape. Instead of a callable to decide whether our search found what it was looking for, and if not where it is relative to the searched-for element, the C++ is obliged to carry that element (because it was an earlier parameter) even if it's unused - and then a comparison function which takes the element, and only then optionally a projection which you may or may not use.
And for binary_search_by_key the C++ is even more awkward, we have a good reason to use a value here, but we're obliged to specify the comparison function even though we only want to write a callable to make suitable keys (ie a projection), because of the order of the parameters.
These would be better served, as in Rust, by three distinct functions, with only the appropriate parameters for each function - even if you choose to actually implement the simplest in terms of the others, because of the documentation and the API shape afforded if you think about it as three things not one with defaults carefully tailored to allow all three uses.
Variadics is a genuinely useful feature, but to do it properly is very difficult, C++ 98 doesn't have anything better than Rust [C compatibility, with no real type checking], C++ 11 does have the outline of what you'd actually want, and C++ 17 has much closer to what I'd want to see in Rust some day.
Much of what you're thinking of in "weak generics" is probably deliberate constraints to only allow coherent things, in C++ they don't care if you want to make a Foo<NaN> even though that's nonsense, IFNDR gives them the ultimate out, your program has no defined meaning, so too bad.
There are some obvious things Rust wants to have but doesn't yet in this space, including broader const Generics (e.g. my OnewayEqual ought to be Oneway<Ordering::Equal>) but it's not going to pursue the irrational C++ exuberance because it's so quickly unsound. C++ doesn't care about that while Rust does.
I don’t really care for your examples of defaults being abused in C++, because all of rust’s workarounds like builder pattern and the default trait have the same potential to be misused while also impeding performance. They also suck for ergonomics, see bevy and polars. Rust already has a huge function colouring problem with async and mut and the lack of defaults only makes it worse.
Similarly for generics. Templates are simply better. Don’t use the power if you’re scared if it, that’s the great thing about freedom, you won’t be forced to. C++ can always do something the Rust way, nullifying everything you’ve said, but the other way around is not true. Rust sacrifices the complex case to make the simple case a little simpler and just leans on macros to do everything else. “Rust just allows coherent things” is a typical example of the bullshit rust programmers spew when they don’t have an actual response but want to say something anyways because it’s completely wrong. Plenty of useful template functionality is impossible to replicate in rust. For example:
String::new() just makes you an empty String, which, since an empty String doesn't own any storage and doesn't contain anything, is very cheap (and indeed constant evaluable), likewise Vec::new() makes an empty Vec.
What your parent commenter wants is for Rust to make the appropriate MyStruct, but without them needing to say MyStruct each time, which would have worked in e.g. C or Go.
Having to name the fields is only part of the pain. You also have to redundantly repeat the struct name. I don't see any fundamental reason why something like this shouldn't be valid:
let foo: [MyStruct; _] = [{a: "foo", b: 1, c: "amp"}, {a: "bar", b: 1, c: "fff"}, {a: "amp", b: 1, c: "aaa"} ];
fn make_struct(x: (&str, u8, &str)) -> MyStruct {
MyStruct { a: x.0, b: x.1, c: x.2 }
}
let foo = [("foo", 1, "amp"), ("bar", 1, "fff"), ("amp", 1, "aaa")]
.map(make_struct);
Since it's a macro there's no impact on runtime performance, but on the other hand it's more work to debug it. Learning declarative macros in Rust is much nicer and safer than learning C macros, but nowhere near as powerful as Rust's horribly unsafe proc macros.
There's no reason you couldn't match on struct fields positionally as well. It would actually be quite convenient for cases like struct Point { x: f64, y: f64 }.
Side note: matching f64 by value isn't a good idea either way, is deprecated and will become an error in the future.
I wasn't thinking about matching floats by value, just destructuring a Point to obtain the coordinates as separate variables. Come to think of it though, as Rust already allows
let Point{x, y} = pl
My overall point here isn't that Rust has made bad design decisions. It's just that the end result of a bunch of sensible design decisions is that initialising arrays of structs is clunky. It might well be that this problem isn't fixable without creating other, worse, problems. However, I think it's a problem that's emblematic of what the OP was talking about. We have here a language that's so concerned with solving difficult problems in clever ways that it's ended up backed into a corner when it comes to something as ridiculously simple as initialising an array of structs.
fn someFunction(a: usize) !usize {
if (a < 10) return error.LessThanTen;
const b = try anotherFunction(a);
return 2 * b;
}
fn anotherFunction(x: usize) !usize {
if (x < 20) return error.LessThanTwenty;
return x * 3;
}
error {
LessThanTen,
LessThanTwenty
}
Note the "(mostly) equivalently" was a reference to the fact that Zig errors can't (currently) contain any other information, whereas an error in rust can carry other information.
Also note that the compiler can't infer the error type in all case, for example in the case of a recursive function. In that case you do need to explicitly write out the error set.
1. Doesn't that risk introducing accidental breaking changes by adding a new error to the set in the implementation, since the set of errors is inferred from the implementation? Having a compile error in this case in Rust is often the last barrier standing between me and an accidental major semver bump (since callers have to exhaustively match on the error conditions) 2. Can you have data in the variants of the error enumeration?
Yes, though at least the language gives you tools to make it more convenient. In the previous examples that would be constructors, and macros can help too (`println`, `vec` etc. exist for that reason).
I myself like to create tiny macros to shorten things like `UnicodeSegmentation::graphemes(s, true).count()` when I have to properly handle unicode. Sure I would prefer to have it be shorter from the start, though that wouldn't make it as obvious how expensive the operation is compared to just getting the size in bytes.
Do you have an illustrative example? (I'm not implying it's not possible, just trying to think of a good example so I can give a good answer)
> since callers have to exhaustively match on the error conditions
If it's exhaustiveness that you're referring to, zig will make you handle all the possible errors (you can still do a catch all type thing when handling errors, which has the potential to "hide" an error that you otherwise wanted to handle explicitly).
> Can you have data in the variants of the error enumeration
No, they compile to just integers. Essentially it compiles to the same as C function that returns an `int` representing the error (with your actual return type passed in as a pointer, say).
Another limitation of zig error values is I think they're globally scoped, so you potentially could have two libraries have clashing error names that you then can't differentiate (I don't know if there are any plans to try and resolve that).
I will say that this automatic error set inference gives writing zig code this lovely "flow", where I do some error checks at the top of the function and early return some errors (which I just invent the names of there and then) and then move onto the happy path of the function, happy in the knowledge that the error handling is already "correct" (in that if the error isn't handled it'll (typically) bubble all the way up to main and exit the program). Any refinement on how a specific error is handled, I can go back to an appropriate place in the call stack and handle it. I always feel like it's helping me write correct code.
Illustrative, I don't know, but I'll try to give more context.
When writing a library, it is important that public items (like functions and enum) don't change between minor versions so that client code doesn't need to update their calls to the library.
Sometimes when refactoring code you end up modifying how a library function is implemented. Maybe it will now depend on some file being present on the system, while previously it wouldn't, meaning that the absence of that file adds a new error variant to this function.
In today's Rust, since the Error type of a Result is an explicit part of a function's signature, such a change is very noisy to the library's maintainer: it entails either modifying the signature of the public function to return a different error type, or modifying the Error type itself, which is also public.
When this happens, the change needs to be reconsidered: either you can defer it to later, provide an additional function with that new implementation and error variant, try to make it work with the error types you already have, or decide in that it actually warrants a major version bump, in conscience.
By contrast, if the set of errors of a function is inferred rather than part of its explicit signature, it means that modifying the implementation you can add a new variant without even realising it (for instance, by mixing the variant name with a variant returned by a sibling function that you thought was already used by this function) and break semver in a much more silent way.
I guess it also makes life harder for tooling, since it has to parse the implementation of a function (and all its subfunctions) to rebuild the set of errors, as opposed to simply parse the signature of the top-level function.
> Essentially it compiles to the same as C function that returns an `int` representing the error
That feels very limiting, I often use error types to e.g., attach data about the error. Is there a more general mechanism for sum types for when this shorthand doesn't apply?
fn someFunction(a: usize) MyError!usize {
if (a < 10) return error.LessThanTen;
const b = try anotherFunction(a);
return 2 * b;
}
fn anotherFunction(x: usize) MyError!usize {
if (x < 20) return error.LessThanTwenty;
return x * 3;
}
const MyError = error {
LessThanTen,
LessThanTwenty
}
I agree it's limiting. It obviously is going to depend on your application, but I have largely done without annotating errors with extra information (that maybe speaks more to the seriousness of my zig projects than to that approach to error handling as being sufficient!).
One pattern I have used (in e.g. a parser) is additionally passing in a pointer to a sum type:
fn parse(allocator: *mem.Allocator, tokens: Tokens, parse_error: *ParseError) !AST
For what it's worth, if you expect this might happen, you should give the enum the [[non_exhaustive]] attribute. This attribute says I, the implementer, know how many of these there are, and in my code I can exhaustively enumerate them e.g. in a pattern match, however, you the 3rd party programmer using this crate, must assume you can't know how many there are, and therefore must write a default match to handle others, even if there seem to be no others when you write it.
Once you do this, you don't cause a compatibility break by adding a new item.