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

211–220 of 307 posts

Re: Assorted Thoughts on Zig and Rust

#211

Post by p0nce »

twic wrote: post #130
flohofwoe wrote: post #43

Earlier quoted context omitted.

> ... for any of them to be using C over C++ these days. That's the old (and frankly: tiresome) mindset that C++ is a successor and improvement of C. After using "modern C" (as in C99 or later) for a while it becomes quite obvious that this isn't the case anymore, instead C++ was a fork of C and developed into a very different direction (including developing the original C subset into a non-standard C dialect). Espec…

> That's the old (and frankly: tiresome) mindset It really isn't. It's based on comparing the languages as they exist today. C++ is vastly more productive.

C++ is also faster thanks to template specialisation and the quick way you can make the right data structure.

Re: Assorted Thoughts on Zig and Rust

#212

Post by p0nce »

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?

The reason it isn't done more often is that it's too much on the imperative side vs declarative builds.

Re: Assorted Thoughts on Zig and Rust

#213

Post by k__ »

estebank wrote: post #198
k__ wrote: post #189

Earlier quoted context omitted.

I did learn much about classes and interfaces in university, independent of language. But not much on traits and ADTs(?). Can you recommend some general learning resources on that?

I do not have any non-Rust resources off the top of my head, but I can give you some quickly looked up resources and enough phrases to search for that should help you in this endeavor. ADTs are Abstract Data Types[1][2][3]: > ADT is implementation independent. For example, it only describes what a data type List consists (data) and what are the operations it can perform, but it has no information about how the List i…

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.

Re: Assorted Thoughts on Zig and Rust

#214

Post by AndyKelley »

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

> security and correctness, most of which Andrew has said he doesn't care about as much

You will find me to be quite open minded about criticism but you're not going to get very far by misquoting me.

I have an entire kanban board[1] dedicated to improving safety, and "security and correctness" are both properties of the word "robust" which is the very first adjective ziglang.org uses to describe the language.

I could spend 20 more minutes on HN debunking the claims in this thread, but instead of rewarding your behavior I'm going to give that time instead to the people who have opened pull requests on Zig and help them get their code merged.

[1]: https://github.com/ziglang/zig/projects/3

Re: Assorted Thoughts on Zig and Rust

#215

Post by Rusky »

pron wrote: post #209
Rusky wrote: post #206

Earlier quoted context omitted.

Four of the five pieces of accidental complexity I listed were present in C++98, so I'm not sure what the relative ages have to do with this. (You've also not mentioned any accidental complexity in Rust...) Instead, I attribute it to hindsight and differences in priorities- C++ today is still introducing new features with the same level of unforced complexity (e.g. compare C++ lambda capture clauses and coroutines, t…

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-specifying low-level details in both languages. My usage of the term applies instead to the languages themselves, and the level of extra pain they inflict on programmers who have already accepted the C++/Rust/etc aesthetic.

Re: Assorted Thoughts on Zig and Rust

#218

Post by estebank »

k__ wrote: post #213
estebank wrote: post #198

Earlier quoted context omitted.

I do not have any non-Rust resources off the top of my head, but I can give you some quickly looked up resources and enough phrases to search for that should help you in this endeavor. ADTs are Abstract Data Types[1][2][3]: > ADT is implementation independent. For example, it only describes what a data type List consists (data) and what are the operations it can perform, but it has no information about how the List i…

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 operations performed on them (traits). On the other hand, in OOP there's a higher reliance on encapsulation, making behavior an integral part of what the class is and using inheritance for expansion. When all you have is ADTs, you _can't_ have inheritance, so you end up using composition (which is generally considered better design) and you are more likely to rely on the creation of "new-type" container types for everything. You think of them as a way to describe what the data is, not how you interact with it.

Apologies if this is a bit hand-wavy, I'll try to write a more thoughtful answer at a later time.

[1]: https://medium.com/javascript-scene/the-forgotten-history-of...

Re: Assorted Thoughts on Zig and Rust

#219

Post by dnautics »

penguin_booze wrote: post #204
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."

As Raymond Hettinger once remarked, Python is a language for consenting adults.

I bet it wouldn't be hard to write something in zig that enforces this. I think the compiler is going to start getting pluggable and when a package manager comes out I'm sure something like an opt-in check against this will become a thing.

Re: Assorted Thoughts on Zig and Rust

#220

Post by mumblemumble »

murkt wrote: post #194
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…

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 respect `_field` than my Java-using colleagues are to respect `private field`.

Post reply on HN