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

151–160 of 307 posts

Re: Assorted Thoughts on Zig and Rust

#151

Post by giraj »

auggierose wrote: post #133
giraj wrote: post #108

Earlier quoted context omitted.

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?

My work is related to homotopy type theory. There are mathematicians working in Agda and Lean (2, but also 3) as well, but it certainly is a niche field.

Re: Assorted Thoughts on Zig and Rust

#152

Post by dnautics »

_u9xp wrote: post #139
asddubs wrote: post #135

Earlier quoted context omitted.

>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…

Looking at that unicode PR, It seems like the thought process is "we don't want to spend time fixing unicode security regressions until we have stabilized the rest of the language", the unicode library is totally broken rn, don't fix a minor part of the problem.

Re: Assorted Thoughts on Zig and Rust

#153

Post by robinei »

geodel wrote: post #114
robinei wrote: post #78

Earlier quoted context omitted.

I have the feeling that what will push Zig ahead is the uncanny sense of technical aesthetics shown by the creator. Unsexy details like language simplicity, what-you-read-is-what-runs, orders of magnitude faster compile times, effortless cross compilation and C interoperability. I have never seen anyone focusing so ruthlessly, so early, on nitty-gritty details of how to go about engineering a compiler and language th…

This is excellent point. Zig authors like Go authors prioritize software engineering and hence upfront work on tooling, fast compilers, cross compilation etc. Whereas a lot of upcoming languages in last decade are prioritizing PL design part, so tooling will be delegated to external projects. I have seen many say just combine PL design innovation and tooling part and it will be perfect but I think this will not happe…

I also think that engineering concerns can dictate or at least strongly influence language design. It can still lead to innovation though, like in the way Zig handles async/await, and how it will try to handle recursion.

It is just innovation mostly guided by practical engineering concerns. In this case: How to avoid requiring expensive heap allocation for async tasks, and how to be sure you don't crash from a stack overflow due to unexpected input for example.

I suspect that the excellent Zig comptime support is made possible by intentionally going for a pretty unambitious type system. Otherwise how could you soundly let arbitrary code generate a type? A fancy type system that wants to reason about that will fail, or at least cause the whole language to revolve around making that work.

I think you are right that it would be very hard for a language to innovate both here, and in the traditional PL-teoretical way.

Re: Assorted Thoughts on Zig and Rust

#154

Post by _u9xp »

dnautics wrote: post #152
_u9xp wrote: post #139

Earlier quoted context omitted.

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…

Looking at that unicode PR, It seems like the thought process is "we don't want to spend time fixing unicode security regressions until we have stabilized the rest of the language", the unicode library is totally broken rn, don't fix a minor part of the problem.

There is no excuse, in my opinion. The PR would have taken a step in a safer direction, even if the entirety of it is scrapped at a later date. It wouldn't have broken anything else in the codebase, and it was a completed, merge-able change.

Again, the frustration wasn't just from the PR alone - it was also the Discord flame war that ensued prior to the PR.

Re: Assorted Thoughts on Zig and Rust

#155

Post by [deleted] »

_u9xp wrote: post #144
gameswithgo wrote: post #124

Earlier quoted context omitted.

Every language has overzealous fans, when a language is new this is likely a largely percentage of the community. If you use that as a reason to avoid a language you will likely just end up avoiding new languages.

See my other comment. It's more the fact Andrew stepped into the conversation himself and just said "be nice" instead of addressing security concerns, just fueling the flame war even more. A response to a security concern should never be "fuck off".

[deleted]

Re: Assorted Thoughts on Zig and Rust

#156

Post by _u9xp »

dna_polymerase wrote: post #148
drcode wrote: post #126

Earlier quoted context omitted.

Any new language project in 2020, for good or ill, is going to be highly opinionated and self-select for people who share similar views on language design. When someone comes along on their discord and says "you need to have this security and correctness issue that I care about deeply fixed yesterday" you really can't be surprised if not everyone shares your urgency- There are probably other languages/communities tha…

Yes, a bit of tribalism seems to be ingrained in every online community these days. That clashes with a lot of people having pretty high expectations for code provided for free to them.

I don't see how those two things coincide at all. Further, your second statement is a strawman - for a project and community that touts being a serious replacement for C, there are indeed expectations about the security mindset of the individual providing the code. When the project has 7k+ stars on Github, clearly people are looking at it and using it. If the maintainer is being unsafe, it's ridiculous to imply nobody is allowed to be critical of that.

Re: Assorted Thoughts on Zig and Rust

#157

Post by higerordermap »

mwcampbell wrote: post #138
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.

If takes twice time to write?

Of course, I too believe statically verifying is important for mission critical software. But it comes with a cognitive overhead.

Re: Assorted Thoughts on Zig and Rust

#159

Post by higerordermap »

lifthrasiir wrote: post #119
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…

>> Zig manages to provide many of the same features with a single mechanism - compile-time execution of regular zig code. > This is a huge one for me, and I really don't understand why Rust didn't jump on this earlier. I believe this outcome was mostly defined by the history. Here is my reasoning: Rust, at least since 0.5, was undoubtly designed as a replacement for C++ (of course that doesn't necessarily mean that i…

> Much simpler type system, which compiles fast and makes the incremental compilation less concern for them.

Where is this "complex type system -> long compilation times" meme comes from?

Most of rustc's time is spent in llvm. And bottlenecks are identified as monomorphization, producing large amount of LLVM IR and lack of binary dependencies.

Type checking is a small portion of time, and not a bottleneck, IIRC.

Re: Assorted Thoughts on Zig and Rust

#160

Post by AnIdiotOnTheNet »

_u9xp wrote: post #146
vips7L wrote: post #145

Earlier quoted context omitted.

I had the opposite experience. They were welcoming and helped me solve some very off the beaten path issues.

They're fine if you don't bring up criticisms. God help your soul if you do.

I've argued with Andrew about Zig features and I never felt it was hostile in any way. In fact, I found him remarkably patient.

I was always on the IRC though. It could be the discord community is less mature.

Post reply on HN