I think most of the difficulty people experience is when they try to naïvely use references anywhere they would normally use a pointer. That mostly works for functions, but this ends up getting really confusing and difficult for data objects. Instead, people should really be using things like Rc which makes certain patterns much simpler. People seem to have this ridiculous notion that using Rc or heaven forbid Rc > i…
Zig as an alternative to writing unsafe Rust
211–220 of 230 posts
Re: Zig as an alternative to writing unsafe Rust
#212>There are endless debates online about Rust vs. Zig 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…
[flagged]
Using unsafe correctly isn't a mythical standard, that's the bare minimum for safety.
Re: Zig as an alternative to writing unsafe Rust
#213Earlier quoted context omitted.
> Rust is the inverse of Perl: It makes the easy stuff hard. 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. > Writin…
> 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.
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.
Re: Zig as an alternative to writing unsafe Rust
#214Earlier quoted context omitted.
> don’t count CVEs without looking at the context and content of those CVEs 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 incorpor…
I think we’re on the same page here. 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.…
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 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.
Re: Zig as an alternative to writing unsafe Rust
#215Bun repo is filled with issues surrounding segfaults, but I guess it gave them the advantage to get up and running quickly.
Re: Zig as an alternative to writing unsafe Rust
#216Earlier quoted context omitted.
> 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. 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 beg…
I don’t know, people who go too hard on simplicity often don’t even grasp the underlying problem in a given case (looking at this utterly dumb piece of text as an example: http://harmful.cat-v.org/software/ ) - sure, no sane people would want to deliberately introduce complexity/abstractions, but abstraction is the only weapon we have against complexity. Problems have an inherent complexity which simply cannot ever b…
Re: Zig as an alternative to writing unsafe Rust
#217Earlier quoted context omitted.
All of the "basic" data structures are already provided by either the standard library or crate ecosystem, so you'll rarely (if ever) need to write your own linked list or hash map from scratch. 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 structu…
Rust is supposed to be a systems programming language. If writing basic data structures was an edge case in it, the language would be broken. Luckily, in my experience it isn’t (at least not in this way).
Re: Zig as an alternative to writing unsafe Rust
#218Earlier quoted context omitted.
You are not alone. The other day I was checking out a new programming language and the author rewrote the unsafe rust part to zig: https://github.com/roc-lang/roc/blob/main/FAQ.md#why-does-ro...
This was quite literally the motive for this article.
Re: Zig as an alternative to writing unsafe Rust
#219Earlier quoted context omitted.
> 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.
I wish more of the Rust Community are like you and own up to the issue. And then I wouldn't have to keep repeating the same thing like I am a troll. The "Keep it Technical" has been the Rust community answer for years , is basically asking the rest of world to tolerate RESF ( Rust Evangelism Strike Force), while any push back against Rust ( or specifically RESF ) are "un-helpful" and they take zero tolerance. So I sh…
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.
Re: Zig as an alternative to writing unsafe Rust
#220Earlier quoted context omitted.
You must not see the C or C++ threads. :) Virtually every C or C++ thread on HN for the last several years is littered with comments from Rust zealots demonizing and condemning other humans for being working in C or C++ codebases.
C or C++ threads on HN are often not about something great. Recend thread on SHA-3 vulnerabilities as example [0]. If security standards providers fail to write secure C code where does this put average Joe? I mean the whole 'pride' threads of people who 'enjoy writing C' or C++ look as strange on HN as Rust brigading. Its funny how there is no C or C++ pride thread on a day when vulnerabilities hit frontpage. PS. I…
Virtually every thread means both positive, neutral, and negative stories.
Something about Rust makes people feel justified bullying people supporting their families laboring in C or C++ codebases. No other language community has this.
The other fallacy is equating laboring with pridefulness. I never said anything about pride. Most C and C++ programmers are very aware of the problems in their ecosystem and they are starting to solve the problems. The pace of those improvements might not be to your liking, but that doesn't mean it's even plausible to convince my boss to rewrite software in Rust or introduce Rust incrementally.
We are four levels deeper into this discussion and it seems the points in my original comment are only strengthened, as evidence in the replies.