Earlier quoted context omitted.
It's hard to make a definitive argument one way or the other because the guarantees Rust makes come at a cost of compilation speed and language complexity that can have a negative effect on correctness. This question is impossible to answer without an empirical study. Unlike C, Zig is (or will be) memory safe, although its safety can be turned off, and often is -- after testing. Unlike C, it provides powerful abstrac…
> It's hard to make a definitive argument one way or the other because the guarantees Rust makes come at a cost of compilation speed I don't think this is actually true. The compiler is slow but not due to memory safety; the 'cargo check' command is rather quick and the compiler itself doesn't seem to spend a lot of time in the frontend, most of the time in spent in the backend, past the borrow checking phrase.
Interview with Zig language creator Andrew Kelley [video]
181–190 of 210 posts
Re: Interview with Zig language creator Andrew Kelley [video]
#182Earlier quoted context omitted.
RAII is not a question. Zig prefers explicitness, i.e. by looking at a subroutine you know exactly which code is called, its approach to releasing resource uses defer.
The question is how to do automatic resource management. There are no checks of any sort, runtime or not, to help you here (correct me if I'm wrong). RAII is not precluded by explicitness, you could require all values that require cleanup to be syntactically marked in some way and it would still be RAII. defer also cannot handle resources whose lifetimes do not correspond to nested scopes (eg. the elements of an Arra…
> RAII is not precluded by explicitness, you could require all values that require cleanup to be syntactically marked in some way and it would still be RAII.
I think this one is TBD.
> defer also cannot handle resources whose lifetimes do not correspond to nested scopes (eg. the elements of an ArrayList) like RAII or a GC can.
Yep, defer won't work if there is no known lifetime scope, but I think this one is actually a good tradeoff to make in a low-level language. Don't get me wrong -- I love tracing GCs and think that they're the right choice for the vast majority of application software, plus there have been great strides made in GC capabilities in the past few years, but in the domains where low-level languages are appropriate there is a different set of constraints. Low-level programming is not like high-level programming, and IMO it's wrong to even try to make them look alike.
Re: Interview with Zig language creator Andrew Kelley [video]
#183Earlier quoted context omitted.
> But after using nim i'm convinced that macros make even more sense for systems programming. Macros are controversial. I love them in Scheme and Clojure, but I wouldn't want them in any language aimed at a larger, more mainstream crowd. At the very least, macros introduce another meta-language to know (and if they're in a language with a complex type-level language like Rust or Haskell then they're a third language…
Look at any sufficiently complex and/or low level C like Linux or FreeRTOS, and C text macros are used significantly. Some of the functionality would be horrible to implement otherwise. Being text based they're a pain, but like @gw, I'd have a hard time seeing a language like Zig without macros making a good low level system language. Maybe a good systems application like Kubernetes, similar to Go's niche, but not sy…
The goal isn't to have macros but to be able to do what macros are used for. Zig has found a different and simpler way to do what macros do. comptime gives you generic types, typeclasses/concepts, typesafe printf, conditional compilation and much more, all without macros and with a simpler construct than macros.
Re: Interview with Zig language creator Andrew Kelley [video]
#184Earlier quoted context omitted.
With C++ I can get zero cost abstractions without Rust like compilation times, in spite C++ fame of slow compile times. How? By making heavy use of binary third party dependencies, every module gets its own binary library, no crazy use of metaprogramming, incremental compilation and linking. My WinUI/UWP professional work compile in a fraction of my Gtk-rs toy applications. I keep measuring improvements in this area,…
> By making heavy use of binary third party dependencies I use Rust because I need performance, then I compile my Rust code for the exact CPU instructions available on my target machine and with PGO, binary dependencies can't do that. Also, binary third party come with a lot of hassle (compiler version & options used can break your build) so I'm really glad Rust took the source-code dependency route instead (at least…
Except that doesn't work for the business of selling binary libraries for mobile and mainstream desktop OSes.
The only hassle is not wanting to learn how to use compiled languages properly, that is how we end up with the brain dead idea of header only libraries.
Regarding performance, Rust still needs to catch up with C++ in many domains.
There are plenty of reasons why C++ is my to go language outside my managed language options, despite my appreciation for Rust, and C++'s caveats of copy-paste compatibility with C.
Re: Interview with Zig language creator Andrew Kelley [video]
#185Earlier quoted context omitted.
std::span is a modern C++ class designed to act like an array or vector, by viewing the memory of an existing array/vector without allocating anything. In my experience writing audio code, C++'s implicit copy constructors are what makes it too easy to accidentally allocate memory.
I'm not saying C++ is the best language out there but that smells like inexperience writing real-time safe code. The problem isn't implicit copy constructors but implicit copies in your code.
> The problem isn't implicit copy constructors but implicit copies in your code.
I don't understand what's the difference.
I'm not an expert in writing real-time safe code, but I've spent close to a year working on allocation-free programming. Implicit copies of structs (value types) are as fast as implicit copies of integers, but implicit copies of types with owned heap memory invoke the copy constructor, which calls into the allocator. Or did I misunderstand your comment or get anything wrong?
Re: Interview with Zig language creator Andrew Kelley [video]
#186Earlier quoted context omitted.
> This is simply not true. Perhaps you mean that you don't have a guarantee that your code is memory-safe, but that's not the same thing. “But people can write correct C code”. Correct Zig != memory safety. It's the opposite: MEMORY SAFETY IS THE GUARANTEE that your code won't have memory error no matter how broken it is! > Another is to write it in a language that guarantees no such error can happen in development,…
> Correct Zig != memory safety. It's the opposite: MEMORY SAFETY IS THE GUARANTEE that your code won't have memory error no matter how broken it is! I think you have a missing piece of factual information here. Safe Zig (which is not "correct Zig") guarantees (or will guarantee) memory safety everywhere, no matter how broken the code is, as long as you don't use unsafe operations -- just as in Rust. Instead of elimin…
Actually what I don't understand is how you can at the same time:
- estimate that memory safety isn't paramount (you're not alone in this case, and it's usually the kind of discussion that happens over and over on Rust threads).
- and use the “Zig is memory-safe” as a marketing argument.
“Zig isn't memory safe but we think it's not what matters” is something I'm willing to hear even though I usually make a different trade-off, I know a ton of C programmers who are fine with those languages not being memory-safe. But redefining the definition of memory safety[1] so that Zig can fit in, while at the same time arguing that memory safety is just a detail in the grand scheme of things, is just incomprehensible to me.
Also, your writing in this whole thread is full of resentment towards Rust and I don't think your animosity is helpful in any way: among the really tiny group of people who are currently experimenting with Zig there are people who actually love Rust and use it every day, I'm one of them and I know I'm not the only one. Bashing other language in a thread about a language you contribute to isn't the best way to be a welcoming community.
Good day.
[1] “Zig is (will be) memory safe”*
*as soon as you disable some compiler optimizations and use an allocator which is actually a memory-management runtime but not totally a GC because you need to free things yourself and if you make a mistake it will abort your program. Terms and conditions apply.
Re: Interview with Zig language creator Andrew Kelley [video]
#187Earlier quoted context omitted.
I'm not saying C++ is the best language out there but that smells like inexperience writing real-time safe code. The problem isn't implicit copy constructors but implicit copies in your code.
> The problem isn't implicit copy constructors but implicit copies in your code. I don't understand what's the difference. I'm not an expert in writing real-time safe code, but I've spent close to a year working on allocation-free programming. Implicit copies of structs (value types) are as fast as implicit copies of integers, but implicit copies of types with owned heap memory invoke the copy constructor, which call…
Sorry I worded that poorly, what I meant is that you shouldn't be writing code where the fact an implicit copy constructor allocates is a concern at all, because C++ has very clear copy semantics.
With a handful of exceptions you essentially will never need to worry about this if you restrict assignment and argument passing of non-POD types to references within the critical code blocks. And in the case that you do need to worry about it, the copy constructor should be explicitly deleted anyway.
It's a footgun to be sure, but it's not a serious one with a bit of discipline. If you're used to doing real-time safe programming, you'll get paranoid about code that could invoke an allocator (or write your own).
Re: Interview with Zig language creator Andrew Kelley [video]
#188Earlier quoted context omitted.
> The problem isn't implicit copy constructors but implicit copies in your code. I don't understand what's the difference. I'm not an expert in writing real-time safe code, but I've spent close to a year working on allocation-free programming. Implicit copies of structs (value types) are as fast as implicit copies of integers, but implicit copies of types with owned heap memory invoke the copy constructor, which call…
Sorry I worded that poorly, what I meant is that you shouldn't be writing code where the fact an implicit copy constructor allocates is a concern at all, because C++ has very clear copy semantics. With a handful of exceptions you essentially will never need to worry about this if you restrict assignment and argument passing of non-POD types to references within the critical code blocks. And in the case that you do ne…
> if you restrict assignment and argument passing of non-POD types to references within the critical code blocks.
It's a working strategy, but if you forget the `&` in `auto & x = document.foo; auto & y = x.field;` a single time, it might silently invoke the allocator. What actually happened to me was that it crashed because I returned a reference to a stack variable copied by mistake, when I meant to type a `&`. Pointers are probably less prone to accidental copying, but they have uglier dereference syntax and are nullable (excluding custom types).
Ever since that incident, I've been paranoid that I accidentally forgot the reference in another spot in the code. A few days ago, I debugged the code and set a breakpoint on malloc in the audio thread (LLDB crashes when listing threads, Visual Studio works) and found out my current codebase doesn't allocate on the audio thread. I hope I don't introduce any allocations.
To avoid this footgun, objects could be only copyable through an explicit `clone()` method like in Rust (which breaks std::vector), or by marking copy constructors as explicit (which you can't do to a std::vector).
Re: Interview with Zig language creator Andrew Kelley [video]
#189Earlier quoted context omitted.
Sorry I worded that poorly, what I meant is that you shouldn't be writing code where the fact an implicit copy constructor allocates is a concern at all, because C++ has very clear copy semantics. With a handful of exceptions you essentially will never need to worry about this if you restrict assignment and argument passing of non-POD types to references within the critical code blocks. And in the case that you do ne…
> if you restrict assignment and argument passing of non-POD types to references within the critical code blocks. It's a working strategy, but if you forget the `&` in `auto & x = document.foo; auto & y = x.field;` a single time, it might silently invoke the allocator. What actually happened to me was that it crashed because I returned a reference to a stack variable copied by mistake, when I meant to type a `&`. Poi…
Most of this is solved by code review, unit testing, custom allocators, and if you really want rust-like guarantees, type traits. In this case std::is_trivially_copyable and std::is_trivially_destructible. Like you don't need an explicit .clone() method, you static_assert that all real-time-safe code only touches structs that are trivially copyable/destructible and write a custom allocator with optional checks to see if it's invoked in a real time context, and write a unit test to stress it. There are some places where this doesn't work, but they're obvious and pretty straightforward to handle. Ideally you'd have a slab allocator with constant time alloc/free while locked in the real time context that cleans itself up for real on resetting the system.
Really though, you shouldn't have an owned STL instance like std::vector near your real time code to begin with. You're seeing one of the reasons people writing performant code don't use the STL at all, even if it has gotten up to par with handrolled solutions in certain benchmarks.
Re: Interview with Zig language creator Andrew Kelley [video]
#190Earlier quoted context omitted.
> Correct Zig != memory safety. It's the opposite: MEMORY SAFETY IS THE GUARANTEE that your code won't have memory error no matter how broken it is! I think you have a missing piece of factual information here. Safe Zig (which is not "correct Zig") guarantees (or will guarantee) memory safety everywhere, no matter how broken the code is, as long as you don't use unsafe operations -- just as in Rust. Instead of elimin…
Actually what I don't understand is how you can at the same time: - estimate that memory safety isn't paramount (you're not alone in this case, and it's usually the kind of discussion that happens over and over on Rust threads). - and use the “Zig is memory-safe” as a marketing argument. “Zig isn't memory safe but we think it's not what matters” is something I'm willing to hear even though I usually make a different…
1. Safe Zig is(/will be) memory safe. It is not what you deploy, but it is one interesting aspect of Zig's design which makes it very different from "C with ASAN."
2. Nobody's goal is to use a memory-safe language. The goal is a safe and correct program. A memory-safe language is one way towards memory-safe programs, but the belief that this is the most effective way to achieve safe and correct programs is an interesting hypothesis, but it is just that. It is certainly possible that trading off those guarantees for something else -- like increased confidence across the board -- could result in safer, more correct programs, or at least not any worse.
> Also, your writing in this whole thread is full of resentment towards Rust and I don't think your animosity is helpful in any way
If you go over this thread again you will see that this is simply not true. I certainly did not bash Rust once. It is a very cool language with a bright future that many people love, but it just doesn't suit my personal tastes, that's all. And because both Rust and Zig are trying to provide safe low-level programming and they do it radically different ways comparing their approaches to safety is interesting. If my points are incomprehensible to you that might be because it is you who are acting with animosity and resentment that cloud your judgement.