Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Assorted Thoughts on Zig and Rust

scattered-thoughts.net

Post reply on HN
Print view View original

131–140 of 307 posts

Re: Assorted Thoughts on Zig and Rust

#131

Post by dnautics »

flohofwoe wrote: post #15
weinzierl wrote: post #4

Earlier quoted context omitted.

While Zig is an awesome project I feel a little bit the same. My two cents are that it is because Zig, as innovative as it is, has nothing that other languages couldn't copy or assimilate. With Rust it is a different story, because the ownership model cannot be plugged into other languages without changing them fundamentally. My prediction is similar to yours that Zig will be an important research project but not go…

Rust and Zig target different audiences though. It's often been said before, but Rust is mainly a C++ replacement, while Zig is mainly a C replacement. I have switched from C++ as my default-language to C a few years ago, and having dabbled a bit in both, I feel a lot more attracted to Zig than Rust for future projects (and mostly for the same reasons why I switched from C++ to C). If Zig can settle in the niche that…

> Rust and Zig target different audiences though.

You would think that, but for example I think that, for example, Oxide should definitely have picked zig, if it were more ready. Obviously it's not, and oxide wants to ship now.

Re: Assorted Thoughts on Zig and Rust

#132

Post by wk_end »

optymizer wrote: post #80
lambda_dn wrote: post #11

I think Zig's biggest advantage is that it's just C without the warts, or footguns as is said in the Zig world. The comptime feature is probably the most exciting thing I've seen in a while. I've looked at Rust and feel it's more of a competitor to C++, Java and C#. Whereas Zig is C done right.

I've been enjoying D as "C done right". I find it a pleasure to use.

D is much more "C++ done right" (and then some). C and Zig are very barebones, close-to-the-metal language. D has garbage collection, classes, templates, exceptions, built-in dynamic arrays and hash tables, and on and on and on. The "Features Overview" page makes me go cross-eyed [1].

Yes, you can turn many of these things off or ignore them and just use D as a better C, but the same could be said of C++ (for some definition of "better"). Or most languages, really, if you squint enough.

[1] https://dlang.org/comparison.html

Re: Assorted Thoughts on Zig and Rust

#133

Post by auggierose »

giraj wrote: post #108
auggierose wrote: post #102

None of these languages represent the medium term future, but are certainly interesting milestones along the way that will inform it. The real future though is theorem proving systems, and generating code from them. I don't mean so much Agda, Idris, etc., which try to approach theorem proving from a programmer's point of view. But theorem proving systems that embrace the full spectrum of abstract and correct thought.…

Could you elaborate or illustrate what you mean by "theorem proving systems that embrace the full spectrum of abstract and correct thought"? As a mathematician (and programmer on the side) who regularly works in Coq, my impression is that Rust does represent "the future of programming" (or rather, my ideal of it). Type systems are the only mechanism (that I know of) for formally ensuring properties of programs, and p…

Very interesting, I don't know many mathematicians working in Coq. What is your field?

Re: Assorted Thoughts on Zig and Rust

#134

Post by drcode »

martinhath wrote: post #61

This is a really great writeup! I was using Rust as my main programming language from some months before 1.0 up until maybe early 2019. I have only written somewhere in between 100 and 1k lines of Zig, but generally feel that I agree with most of what's being brought up here. Here's a mind dump: > Zig manages to provide many of the same features with a single mechanism - compile-time execution of regular zig code. Th…

The only place where the lack of closures in zig has been clunky for me so far is for when your firing off new threads and need to hand-package all the data for the new thread. Since this is something that one only does infrequently, it's not the end of the world.

Re: Assorted Thoughts on Zig and Rust

#135

Post by asddubs »

_u9xp wrote: post #121

Zig has very little focus on safety and has had several regressions related to security and correctness, most of which Andrew has said he doesn't care about as much. This concerns me greatly. The discord community operates like a cult (sound familiar, Rust community?) and any criticisms or anything not exuberantly positive results in a flame war. I saw all of that happen several times so far with the community and it…

>Zig has very little focus on safety and has had several regressions related to security and correctness, most of which Andrew has said he doesn't care about as much.

can you be a bit more specific?

Re: Assorted Thoughts on Zig and Rust

#136

Post by drcode »

pizza234 wrote: post #38

I think this an argument like the following is not really meaningful: > Most of this difference is not related to lifetimes. Rust has patterns, traits, dyn, modules, declarative macros, procedural macros, derive, associated types, annotations, cfg, cargo features, turbofish, autoderefencing, deref coercion etc Nobody forces beginners to write macros. Beginners are only macros _users_. With time and experience, the ne…

Sure, the rust language is "simple" if you abstain from using 80% of the features of rust, but then it would be impossible to write non-trivial programs. Zig, on the other hand, gets rid of this 80% as well, AND still lets you write non-trivial programs.

Re: Assorted Thoughts on Zig and Rust

#137

Post by dnautics »

mtzet wrote: post #83
steveklabnik wrote: post #77

Earlier quoted context omitted.

(By the way, Hacker News doesn't support markdown; indent your code by two spaces, rather than using fences. https://news.ycombinator.com/formatdoc ) Just a few small things: > This is a huge one for me, and I really don't understand why Rust didn't jump on this earlier. Doing this well is not easy. Exposing a full language at compile time isn't a difficult feature, but doing compile-time execution in a sound, safe w…

> Doing this well is not easy Does this also apply to the in-language build system? Given both Rust and Zig's ergonomics, it just seems so brilliantly simple (at least in hindsight) to let the build system be a library. Is it just coincidence that I've only heard of this approach for zig and Jonathan Blow's language, or is there a technical reason this is more difficult than it seems?

> Is it just coincidence that I've only heard of this approach for zig and Jonathan Blow's language

It's also a feature in elixir (Mix). Interestingly elixir also has a comptime concept, so I think having comptime makes having a build library more sensible.

Re: Assorted Thoughts on Zig and Rust

#138

Post by mwcampbell »

pron wrote: post #67

> As long as all unsafe code obeys the aliasing and lifetime rules, rust protects completely against UAF. Zig has little protection. ... now. The goal is to have full protection against UAF (in safe-mode only, of course).

> (in safe-mode only, of course)

Then it seems to me that Rust still has an advantage, in that it offers full protection of UAF with zero runtime overhead.

Re: Assorted Thoughts on Zig and Rust

#139

Post by _u9xp »

asddubs wrote: post #135
_u9xp wrote: post #121

Zig has very little focus on safety and has had several regressions related to security and correctness, most of which Andrew has said he doesn't care about as much. This concerns me greatly. The discord community operates like a cult (sound familiar, Rust community?) and any criticisms or anything not exuberantly positive results in a flame war. I saw all of that happen several times so far with the community and it…

>Zig has very little focus on safety and has had several regressions related to security and correctness, most of which Andrew has said he doesn't care about as much. can you be a bit more specific?

A regression appeared where members were accessible outside of their scopes even without the `pub` modifier. This took months to fix and the person bringing it up initially was yelled at about not understanding programming languages in the discord channel.

Another one I personally brought up was that the standard library's utf-8 module had a decoder that panics on invalid input sequences, certainly setting consumers up for DOS attacks with malformed utf-8 inputs. EDIT: DOS vulnerability is still there (https://github.com/ziglang/zig/blob/master/lib/std/unicode.z..., PR to fix that was closed https://github.com/ziglang/zig/pull/4929). I never responded to the PR because it was at that moment I decided to abandon Zig altogether.

The response to the latter was pretty much "the standard library isn't meant to be used right now", to which I really don't have a response. There was a very, very long and heated argument in the discord channel about it where instead of addressing the concerns about DOS and security I was instead insulted for apparently trying to taint an otherwise perfect language.

The community is vile and the few examples I've seen of the maintainer disregarding safety and security in this way don't give me any amount of confidence in the project overall.

EDIT: Worth mentioning, the syntax and semantics surrounding Zig are not new ideas. I'm sure another project will pop up at some point to compete; many discussions I've seen in the language design channels on IRC and a few discord servers have many people arriving at similar conclusions Zig has made, without knowing Zig even exists. I think we're slowly converging on a language that looks a lot like Zig, but I don't think Zig will be its ultimate incarnation.

Re: Assorted Thoughts on Zig and Rust

#140

Post by auggierose »

qayxc wrote: post #112
auggierose wrote: post #102

None of these languages represent the medium term future, but are certainly interesting milestones along the way that will inform it. The real future though is theorem proving systems, and generating code from them. I don't mean so much Agda, Idris, etc., which try to approach theorem proving from a programmer's point of view. But theorem proving systems that embrace the full spectrum of abstract and correct thought.…

> The real future though is theorem proving systems, and generating code from them. I've heard the same thing about model-driven development 25 years ago. Outside of some very small niches, it's pretty much dead now. > But theorem proving systems that embrace the full spectrum of abstract and correct thought. And here's where reality and the ideal world collide: the vast majority of applications consists of incomplet…

The "generating code from them" brings the bad vibe of useless UML tools with it, but I put it in there anyway, because that's how it is going to be.

There is room for "experimental" programming of course, where you experiment with stuff and you are glad that you get it somehow working in the first place. But should stuff that peoples lives depend on depend on experimental software like that? No. And as software more and more becomes part of our lives, I don't see much software for which that attribute does not hold.

Same goes for hardware.

Post reply on HN