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

221–230 of 307 posts

Re: Assorted Thoughts on Zig and Rust

#221

Post by nemo1618 »

haberman wrote: post #163

Very interesting set of observations. As a C and C++ programmer, I am feeling more and more excited about Zig. One thing that feels missing from Zig though is encapsulation. I don't believe that you can declare struct fields private, such that they can only be accessed by methods. This seems really important to me, not only as a technical means of enforcing invariants, or hiding internal-only implementation details t…

I'm 90% in favor of this; the 10% comes from the few times where I've wished that a particular field was exported, and I know it would be safe to access, but now I need to open an issue or submit a patch, wait for it to be merged upstream, update the dependency version...

Give that Zig is a low-level language where "unsafe escape hatches" are the norm, it wouldn't surprise me if this ended up being an optional compile-time check rather than a mandatory one (as a sibling comment suggested).

Re: Assorted Thoughts on Zig and Rust

#222

Post by nicoburns »

skohan wrote: post #178
steveklabnik wrote: post #173

Earlier quoted context omitted.

I am not saying you should love the module system, just trying to provide some context. (Everyone seems to love and/or hate the module system for various, opposing reasons. It is a great mystery to me. Explaining the module system is like, kind of my white whale.)

Yeah I just think it’s a trend with rust where when a new user complains about a beginner-unfriendly feature, often they are met with an explanation of some esoteric benefit. I just wonder how much of that is as-hoc reasoning, and it doesn’t seem like it’s a particularly good sign.

I actually the module system is one of the few exceptions where it's actually poorly designed. It could very easily have a 1:1 mapping to the filesystem with no need to declare modules to use them. Lot's of people apparently don't like that idea, but most other module systems do it that way, and IMO it would be a lot more intuitive.

Re: Assorted Thoughts on Zig and Rust

#223

Post by nicoburns »

mumblemumble wrote: post #220
murkt wrote: post #194

Earlier quoted context omitted.

If you want to communicate intent, put an underscore in the field name, like it's being done in Python. `field` is "you are invited to read/write this directly", `_field` is "please don't read/write this."

Even in a lot of languages that do have "private", it's still pretty consent-based. Java and C#, for example, don't prevent you from mucking with private members, they just make it inconvenient to do so. I used to be suspicious of the Python approach, because it doesn't even pretend it's enforced by anything but the honor system. But I've discovered that, in practice, my Python-using colleagues are no less likely to…

Indeed. JavaScript also doesn't have private fields. But in practice using an undocumented field means "I'm familiar with the internals of this library and willing to check for breaking changes on every update".

There are lots of footguns in JS, but I've never seen this cause issues.

Re: Assorted Thoughts on Zig and Rust

#224

Post by dinglejungle »

dnautics wrote: post #128
creata wrote: post #122

Earlier quoted context omitted.

Oh, so is the point that in Zig, functions with comptime parameters are more or less identical to regular functions in that regard?

Exactly. You can also use non-comptime functions in comptime, if it avoids certain types of stateful behaviour.

An example of this in the Zig math tests, where it tests calling the same function at both comptime and runtime: https://github.com/ziglang/zig/blob/33c4ad7f3a79aad5d7ea481a...

Re: Assorted Thoughts on Zig and Rust

#225

Post by dom96 »

steveklabnik wrote: post #169
skohan wrote: post #168

> Zig is dramatically simpler than rust... Most of this difference is not related to lifetimes. I've been thinking about this recently: the borrow checker gets a lot of attention, but I think the majority of the learning curve of rust is actually due to "unforced errors" in the language UX which have nothing to do with the language's core USP's. For instance, the module system just seems needlessly complex. Like you…

mod.rs isn't needed anymore; back in 2018 we fixed that: https://doc.rust-lang.org/edition-guide/rust-2018/module-sys... > why there can't be sensible defaults to define modules based on the file system structure alone. There could be, and in fact, I personally advocated for them. But there was significant community pushback; it turns out many people like to "comment out" entire modules when doing big refactorings. T…

Nice to hear that there has been some progress here. I recall trying Rust 4+ years ago and my experience with the module system really left a lot to be desired from someone most experienced with Python's module system.

Re: Assorted Thoughts on Zig and Rust

#226

Post by k__ »

estebank wrote: post #218
k__ wrote: post #213

Earlier quoted context omitted.

Thanks! I'm basically looking for a comparison of classes and ADT, I guess. You said, applying your class-based way of doing things didn't work, so I asked myself how would you do it the ADT way.

ADTs are only concerned with the "shape" of the data and what interactions you can have. It is related to classical OOP in the sense that the "interactions" you can have are equivalent to the message passing from the original conception of OOP[1]. The distinction is similar to database design in SQL: the Schema is how the data is laid out and what the relationship between tables is (ADTs) while the queries is the ope…

Hm, but composition over inheritence was already mainstream when I studied 10 years ago.

Also, ECS design is a thing in game development.

Are ADTs taken these concepts into language design?

Re: Assorted Thoughts on Zig and Rust

#227

Post by snovv_crash »

layoutIfNeeded wrote: post #25
the_mitsuhiko wrote: post #2

I quite honestly wonder sometimes why Rust excited me so much when I first started using it, but I do not get such excitement from Zig. Nowadays it's very easy to be excited about Rust because it demonstrated that ownership works but when I started using it, there was still garbage collection etc. Zig looks really cool but it feels like it has a high chance of being a niche language. Rust never felt like that.

In my experience software developers getting excited about their tools rarely lead to good outcomes for the projects they're working on.

Same. Make the tools boring so the excitement can go into the product.

Re: Assorted Thoughts on Zig and Rust

#228

Post by moldavi »

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.

This isnt quite true, the borrow checker forces us to use things like RefCell, or Vec with (generational) indices, which all have run-time overhead. (this isnt even counting those who use Rc)

Re: Assorted Thoughts on Zig and Rust

#229

Post by pron »

Rusky wrote: post #215
pron wrote: post #209

Earlier quoted context omitted.

Sorry, I don't see it that way (and I don't entirely agree with your characterisation of what new Rust changes do, certainly not all of them). I think that both Rust and C++ are fundamentally built around a design concept that I find distasteful and wrong-headed for low-level programming -- https://news.ycombinator.com/item?id=24840818 ; I guess you can call it too much implicitness aimed to make the language appear…

That's much closer to a substantial and fair similarity between Rust and C++! Indeed, if I understand you correctly, it's a major cause of both languages' slow compile times, and a source of a lot of difficulties for humans learning and writing both languages. But this makes me suspect we may be using very different definitions of "accidental complexity" here: Your usage seems to apply to programs, which wind up over…

By accidental complexity I mean aspects that go beyond what you would write in pseudocode when describing an algorithm, and in a language it means the number and "depth" of features dedicated to those aspects relative to the language's total.

Re: Assorted Thoughts on Zig and Rust

#230

Post by jcelerier »

Rusky wrote: post #207
jcelerier wrote: post #202

Earlier quoted context omitted.

> There is even undefined behavior if you mess up namespacing! (Undiagnosed ODR violations are every experienced C++ programmer's nightmare.) so, uh, how does Rust define behaviour if you export a same-name symbol from two rust dlls and load it from some executable ?

It carefully designs its name mangling such that this doesn't happen in the first place, even in the presence of multiple slightly-different builds of a library. The only way to get matching names is to ask for them explicitly, via FFI.

> It carefully designs its name mangling such that this doesn't happen in the first place, even in the presence of multiple slightly-different builds of a library.

but, after checking apparently this adds a hash of the function to the name mangling - how does that work when you want to call it from another language ? e.g. for instance you can call C++ code directly through some dialects of Lisp, Perl , ADA, or D (AFAIR) as they all have libs or mechanisms that kinda understand C++ name mangling - how are you going to do the same with, from what I'm seeing, "name_of_the_file::name_of_the_function::some_hash" ?

> The only way to get matching names is to ask for them explicitly, via FFI.

and what happens if you have two libraries which expose the same extern-C function name ?

Post reply on HN