Live data from Hacker News

Zig as an alternative to writing unsafe Rust

zackoverflow.dev

191–200 of 230 posts

Re: Zig as an alternative to writing unsafe Rust

#191
post #186
post #112

Earlier quoted context omitted.

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…

Complex problems and complex solutions are two different things. The genius is in solving complex problems with simple solutions. While it might seem that adding a crate to solve a problem is a simple thing, from the system programmer point of view (mine), it is not.

But it is simply not possible to solve many many complex problems with simple solutions, no matter how hard you try.

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

Re: Zig as an alternative to writing unsafe Rust

#192

Earlier quoted context omitted.

No arrow operator, no default args, no named parameters, no structure defaults and instead the incredibly verbose ..Default::default() + a trait impl as a substitute, no variadics, overall weak generics compared to C++ and a huge reliance on macros, etc etc. Rust programmers address this by calling everything rust does poorly an antipattern, ie. the “why would you do that” card.

The arrow operator is just a terrible idea, and it's weird that people defend it. It makes sense that C did this, it was a long time ago and compilers weren't very smart so C needs to make up for that, in C++ it's just carried over from C. 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 woul…

C compilers weren't smart.

Re: Zig as an alternative to writing unsafe Rust

#193

Earlier quoted context omitted.

> zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust 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/cvena…

Rust has a low bar for creating CVEs, because the standards for safety are higher. 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…

> 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 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).

Re: Zig as an alternative to writing unsafe Rust

#194

Earlier quoted context omitted.

There are a number of sources of noise in rust, but the one I find most annoying (because it's also so common) is the double colon. My current theory is that it's because the colon is the same height as lowercase letters. If you end up with a long::run::of::module::names, I find it all just blurs into one.

Okay but who is writing code like this instead of using `use`? 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…

> There's literally no way to win.

Yes there is? Follow what C#, F#, Java, TypeScript, etc. do

Re: Zig as an alternative to writing unsafe Rust

#195
post #189
post #89

Earlier quoted context omitted.

But also, where is this malevolent, toxic Rust community that disgruntled C++ developers always engage with? I've yet to encounter a single person from this unstoppable force of sanctimonious assholes ruining everyone's fun on non-Rust projects. By their accounts Rust is a mental health catastrophe for our industry. Anyway, shit posting aside. I do agree with them that the Rust community is a bit eager to suggest rew…

As polyglot dev, with love/hate relationship with almost any language worth using, until Rust gets free of "my compiler compiles yours", there is always an attack vector from those devs. 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 fro…

> until Rust gets free of "my compiler compiles yours"

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".

Re: Zig as an alternative to writing unsafe Rust

#196
post #191
post #186

Earlier quoted context omitted.

Complex problems and complex solutions are two different things. The genius is in solving complex problems with simple solutions. While it might seem that adding a crate to solve a problem is a simple thing, from the system programmer point of view (mine), it is not.

But it is simply not possible to solve many many complex problems with simple solutions, no matter how hard you try. 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 wil…

I would definitely do like you and reach for math libraries/crates whenever I can, since I suck at complex math. But this also means three things: there is the chance we are both no geniuses, we added a complex "black box" solution (who knows how this library/crate work?) and now we have to babysit a dependency.

Re: Zig as an alternative to writing unsafe Rust

#197
post #118

Earlier quoted context omitted.

Can you write a performant, generic vector data structure in C? Until then it is useless in my book.

So useless that Linux, gcc, and all UNIX system commands is written in C. But you're probably doing much more important things, right?

We should definitely appreciate the craftsmanship. This comment says everything, regardless of how trendy Rust might be, let’s respect the craft, your favourite language doesn’t make you more important. Legends!

Re: Zig as an alternative to writing unsafe Rust

#198

Earlier quoted context omitted.

My experience is that I see a LOT more complaints about these sorts of behaviors than I see the actual behavior. I think it's honestly just a meme that's gotten out of hand at this point. Speaking as someone who is not part of the Rust community and knows comparatively little about the language.

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 have never wrote a line of Rust in my life. 20+ years of C++ work.

[0] https://news.ycombinator.com/item?id=35050307

Re: Zig as an alternative to writing unsafe Rust

#199

Earlier quoted context omitted.

So useless that Linux, gcc, and all UNIX system commands is written in C. But you're probably doing much more important things, right?

We should definitely appreciate the craftsmanship. This comment says everything, regardless of how trendy Rust might be, let’s respect the craft, your favourite language doesn’t make you more important. Legends!

[deleted]

Re: Zig as an alternative to writing unsafe Rust

#200

Earlier quoted context omitted.

So useless that Linux, gcc, and all UNIX system commands is written in C. But you're probably doing much more important things, right?

We should definitely appreciate the craftsmanship. This comment says everything, regardless of how trendy Rust might be, let’s respect the craft, your favourite language doesn’t make you more important. Legends!

Rust is not my favorite language and I didn’t mean to speak anything negative about projects written in C, but I do think that those that become great did so in spite of C, not because of it.

No access to performant generic data structures is a major reason why truly performance oriented programs rather choose C++ over C.

Post reply on HN