Zig, the Small Language • Hacker News Board

Re: Zig, the Small Language

#411

Post by davidatbu » Fri, Sep 09, 2022, 3:12 PM UTC

dundarious wrote: post #410

davidatbu wrote: post #409

Earlier quoted context omitted.

> You have to judge Rust’s success against the unsafe code it occasionally forces you to write (you don’t get to hand wave it away). Agreed. > I really don’t like Rust’s allocation story though. I presume this is because of the lack of ergonomic handling of OOM? Only time I've run into OOM was when training deep learning models (in Python backed by C++) on a GPU, but if I were to do that in Rust, I'm pretty sure I'd…

It's not at all about OOM, actually. It's about performance, and to a lesser degree, simplifying code or architecture. Zig's FixedBufferAllocator and ArenaAllocator are very simple and very useful, and they conform to the Allocator interface that's used for every bit of allocation in std and non-std. Anyone who has written a lot of C or a certain kind of C++ will be very familiar with the concepts, and will have used…

Gotcha. Again, thanks!!

Re: Zig, the Small Language

#412

Post by ok123456 » Fri, Sep 09, 2022, 3:49 PM UTC

littlestymaar wrote: post #294

ptato wrote: post #287

Earlier quoted context omitted.

It's been ~a year. I can't remember. It usually had to do with the dreaded self referential structures, or interfacing with c libs.

For Self referential struct, the typical answer is twofold: - try to design your code not to need them. - if you really need one, you can either use smart pointers ( Rc & RefCell ) or use unsafe and use the Pin API to be sure that you won't accidentally move your struct. That being said, it's not easier in C (or at least, it's easier to write, but also very easy to misuse), since a memcopy will silently break your se…

In most situations those are horrible non-solutions.

Ref counted cells can't be used in self-referential structures because you'll introduce cycles. So, you'll go through all this trouble just to make memory leaks in the end.

"Designing your code not to need them" usually means implementing a worse version of a data structure from first principles.

The only real answer is to write "unsafe" Rust here and there. Which is fine. But, to the prevailing Rust community that is absolutely heretical.

Re: Zig, the Small Language

#413

Post by pcwalton » Fri, Sep 09, 2022, 5:48 PM UTC

dundarious wrote: post #312

davidatbu wrote: post #181

Earlier quoted context omitted.

Out of the 10 top ones in that list about Rust (there's one about C code in GCC), 1. 6 are because of unsafe code. 2. 3 are because of ouf-of-memory (OOM) errors. 3. 1 is due to unsafe code in `tokio`, but I think it's fair to consider unsoundness in tokio's safe abstractions (over unsafe code) as unsoundness in "safe Rust" because the crate is so foundational, even if its third party. Regardless, I don't think any o…

The original claim was: > The borrow checker doesn't stop most memory errors, just the easy ones at the cost of making it painful to write basic data structures I'm not the OP but I think the point here is that the borrow checker is only applicable for the "easy" code (which does make up an awful lot of code), but even "basic data structures" very often require abandoning the borrow checker. In such a case, it's perf…

> Lacking an unsafe keyword does make it more unsafe, but in my experience, not very much.

The problem is not "lacking an unsafe keyword", it's that Zig is not memory safe. Not being memory safe, in my experience, makes a massive difference.

Re: Zig, the Small Language

#414

Post by littlestymaar » Fri, Sep 09, 2022, 8:18 PM UTC

ok123456 wrote: post #412

littlestymaar wrote: post #294

Earlier quoted context omitted.

For Self referential struct, the typical answer is twofold: - try to design your code not to need them. - if you really need one, you can either use smart pointers ( Rc & RefCell ) or use unsafe and use the Pin API to be sure that you won't accidentally move your struct. That being said, it's not easier in C (or at least, it's easier to write, but also very easy to misuse), since a memcopy will silently break your se…

In most situations those are horrible non-solutions. Ref counted cells can't be used in self-referential structures because you'll introduce cycles. So, you'll go through all this trouble just to make memory leaks in the end. "Designing your code not to need them" usually means implementing a worse version of a data structure from first principles. The only real answer is to write "unsafe" Rust here and there. Which…

> Ref counted cells can't be used in self-referential structures because you'll introduce cycles. So, you'll go through all this trouble just to make memory leaks in the end.

You know about Weak references right?

> "Designing your code not to need them" usually means implementing a worse version of a data structure from first principles.

> The only real answer is to write "unsafe" Rust here and there. Which is fine.

If it's a specific “data structure” (1% of the time) and not just the way you've decided to structure your current code (99% of the time), then using unsafe is fine.

> But, to the prevailing Rust community that is absolutely heretical.

No, the rust community is totally fine with reasonable unsafe code (you don't see burntsushi being harassed for using unsafe in his crates for instance), rustaceans hate (to a point which leads to excessive behaviors) unsound code, like the Actix drama, where the author used unsafe in unsound ways (not checking invariants in any way, and declaring “safe” functions that could cause segfault is used incorrectly). But unsafe code used properly is fine.

Re: Zig, the Small Language

#415

Post by ok123456 » Fri, Sep 09, 2022, 11:30 PM UTC

littlestymaar wrote: post #414

ok123456 wrote: post #412

Earlier quoted context omitted.

In most situations those are horrible non-solutions. Ref counted cells can't be used in self-referential structures because you'll introduce cycles. So, you'll go through all this trouble just to make memory leaks in the end. "Designing your code not to need them" usually means implementing a worse version of a data structure from first principles. The only real answer is to write "unsafe" Rust here and there. Which…

> Ref counted cells can't be used in self-referential structures because you'll introduce cycles. So, you'll go through all this trouble just to make memory leaks in the end. You know about Weak references right? > "Designing your code not to need them" usually means implementing a worse version of a data structure from first principles. > The only real answer is to write "unsafe" Rust here and there. Which is fine.…

Yes, I'm aware of weak references and I'm aware that they're not a universal solution to this problem. You risk having something removed as unused while it's actually still being used if you don't have some strong reference to it somewhere.

As to your assertion that this is only '1%' of code, it really depends on what you're doing. If you're just gluing together modules that's where linear types for memory are an applicable model. But, if you are actually designing some structure yourself, it's not an applicable model.

The Actix 'drama' is reason alone to avoid the rust 'community'. I'll wait for these features to make it in a language with better ergonomics, a large commercial backer, and professionals at the helm who are less religious about how mere mortals use their language and are willing to err on being more pragmatic about it.

Re: Zig, the Small Language

#416

Post by bb88 » Fri, Sep 09, 2022, 11:35 PM UTC

cassepipe wrote: post #402

bb88 wrote: post #338

Earlier quoted context omitted.

> we're not teaching electronics students here (or are we? Zig as first language for electronics students makes some sense) From an educational viewpoint, I don't like that EE and SWE programs have very little overlap. A lot of EE tools could be improved if EE's learned more software (particularly parsing and compilers). A lot of SWE don't get into the dirty details of a CPU and what makes it tick and see it some sor…

As I understand you advocate a bottom - up approach rather than a top-down one. I personally prefer the former over the latter as it makes more sense to me to learn how to make basic programs work before I learn what incredible things I can do with them. I have over one year of C experience in my school doing things like rewriting functions of the C stdlib and reimplementin getline() before I learn about radix sort,…

I have no argument there. But let's look at some actual data.

https://www.registrar.iastate.edu/resources/enrollment-stati...

In around 1995ish ISU moved to Scheme for their first level course, because they wanted to follow the MIT example.

At about 2000/2001 they had a healthy number of students in both the computer-science and pre-computer science programs. The problem you can see in the data is converting the pre-computer science majors to computer science. You can see that most just dropped.

Again you could say that maybe SICP should be a weed-out course, but the reality is, you can be a professional programmer without SICP. Yes SICP might be a nice to have for certain problem domains, but most people aren't functional programmers, and don't need to be.

Today, at ISU functional programming is a 300 level course, and the computer science program has 866 registered students for Fall of 2022.

Re: Zig, the Small Language

#417

Post by littlestymaar » Sat, Sep 10, 2022, 1:16 PM UTC

ok123456 wrote: post #415

littlestymaar wrote: post #414

Earlier quoted context omitted.

> Ref counted cells can't be used in self-referential structures because you'll introduce cycles. So, you'll go through all this trouble just to make memory leaks in the end. You know about Weak references right? > "Designing your code not to need them" usually means implementing a worse version of a data structure from first principles. > The only real answer is to write "unsafe" Rust here and there. Which is fine.…

Yes, I'm aware of weak references and I'm aware that they're not a universal solution to this problem. You risk having something removed as unused while it's actually still being used if you don't have some strong reference to it somewhere. As to your assertion that this is only '1%' of code, it really depends on what you're doing. If you're just gluing together modules that's where linear types for memory are an app…

> Yes, I'm aware of weak references and I'm aware that they're not a universal solution to this problem. You risk having something removed as unused while it's actually still being used if you don't have some strong reference to it somewhere.

In graphs yes, but we're talking about self-referential structure here, and there you don't face this risk: the self-reference should always be a weak reference (the struct should be dropped when and only when the external references are gone, the internal ones don't count).

> As to your assertion that this is only '1%' of code, it really depends on what you're doing. If you're just gluing together modules that's where linear types for memory are an applicable model. But, if you are actually designing some structure yourself, it's not an applicable model.

Either you're implementing a data structure from a research paper (and you're in the 1% case and unsafe is fine) or you are actually using such a data structure and you don't have to perform this gymnastic by yourself. In C, people tend to reimplement data structures in their project because the dependency management story is quite dated, but it's not something anyone else does in other languages: most of the time you just import the standard library's data structure (or someone else's) and call it a day.

> The Actix 'drama' is reason alone to avoid the rust 'community'.

You'll find internet mobs in any group of people, unfortunately…

> I'll wait for these features to make it in a language with better ergonomics, a large commercial backer

If you expect larger backers than Amazon, Microsoft, Facebook and Google combined[1], I think you'll need to hold your breath much too long for your own good…

> and professionals at the helm who are less religious about how mere mortals use their language and are willing to err on being more pragmatic about it.

You're confusing redditors (the actix stuff took place on /r/rust) and the language management…

[1]https://foundation.rust-lang.org/members/

Re: Zig, the Small Language

#418

Post by ok123456 » Sat, Sep 10, 2022, 5:18 PM UTC

littlestymaar wrote: post #417

ok123456 wrote: post #415

Earlier quoted context omitted.

Yes, I'm aware of weak references and I'm aware that they're not a universal solution to this problem. You risk having something removed as unused while it's actually still being used if you don't have some strong reference to it somewhere. As to your assertion that this is only '1%' of code, it really depends on what you're doing. If you're just gluing together modules that's where linear types for memory are an app…

> Yes, I'm aware of weak references and I'm aware that they're not a universal solution to this problem. You risk having something removed as unused while it's actually still being used if you don't have some strong reference to it somewhere. In graphs yes, but we're talking about self-referential structure here, and there you don't face this risk: the self-reference should always be a weak reference (the struct shou…

> In graphs yes, but we're talking about self-referential structure here, and there you don't face this risk: the self-reference should always be a weak reference (the struct should be dropped when and only when the external references are gone, the internal ones don't count).

Graphs are a common example of a self-referential structure.

> Either you're implementing a data structure from a research paper (and you're in the 1% case and unsafe is fine) or you are actually using such a data structure and you don't have to perform this gymnastic by yourself. In C, people tend to reimplement data structures in their project because the dependency management story is quite dated, but it's not something anyone else does in other languages: most of the time you just import the standard library's data structure (or someone else's) and call it a day.

On the several occasions I've look for crates that do what I need. They either don't exist, or I read through the code and they're poorly written and make lots of gratuitous copies of data and are very inefficient. You also have people using crates.io for their blog, literally.

> If you expect larger backers than Amazon, Microsoft, Facebook and Google combined[1], I think you'll need to hold your breath much too long for your own good…

A few people at large companies doing resume driven development isn't a real investment. It's not from the top down. At best, you could say they have some R&D investment to hedge their bets.

> You're confusing redditors (the actix stuff took place on /r/rust) and the language management…

Then why doesn't this sort of thing happen with other communities which are also highly online? It doesn't matter if you try to do gate keeping to say "oh those redditors" or "oh those guys on hackernews" aren't the REAL Rust community, the end result was a real package being really deleted from the real Rust community.

Re: Zig, the Small Language

#419

Post by ok123456 » Sat, Sep 10, 2022, 7:26 PM UTC

Tozen wrote: post #397

ok123456 wrote: post #92

Earlier quoted context omitted.

Not fighting the borrow checker or making gratuitous copies of data to satisfy the borrow checker. Zig's scope is just to be a better C that's free to add modern features like optional types, compile time expressions instead of string-macros, source level modules, packages, a more expressive syntax for writing bit-packed structures, a standard testing framework, deferred function calls, and so on. You can also direct…

> Zig's scope is just to be a better C that's free to add modern features... The thing about that though, is there are a number of better C languages (both old and new) that have various levels of C interop. Languages like: D, Odin, Nim, Vlang, etc...

Eventually someone will make one that's ergonomic enough, provides enough features and can used to gradually refactor existing C with minimal changes code bases that it becomes a commercially viable alternative to just continuing to do maintenance programming on the C code.

Re: Zig, the Small Language

#420

Post by dureuill » Sat, Sep 10, 2022, 8:19 PM UTC

mayormcheeseman wrote: post #336

masklinn wrote: post #217

Earlier quoted context omitted.

> So you don't publish it. Why do they care? > I guess they could have levels and allow them in debug mode or with special flag or something? Well yes, that's how normal compilers do things.

I’d assume they care because Go was designed to keep the codebase as “neat” and clean as possible when being worked on by many developers. Given enough time and developers, things like unused variables will start to seep in and make the codebase dirtier. Of course if you’re the only developer working on your own codebase, you’d wonder why they care but you’re also not the main group they were targeting.

i could understand this in 1995, but in 2015? We have peer reviews, and CI. Let's deny warnings there, and allow them during development.