5 ms·

I have no issue with the author's points but I just don't see these two as solving the same problem. Zig, to me, is a better C (as the author notes). It seems

by cletus 2y ago

I have no issue with the author's points but I just don't see these two as solving the same problem. Zig, to me, is a better C (as the author notes). It seems like it's designed so you can combine easily with a C code base and incrementally migrate it. That's a great application. I'm not expert enough to speak on the merits of comptime (which the author talks about). But isn't comptime somewhat equivalent to constexpr and similar compile-time constructs? Rust, to me, fills a niche as a better C++. Macros are better templates. Compile-time ownership checking is better than a C++ runtime smart pointer. There is legacy in C++ that you can never escape eg someone just calling .get() on your smart pointer and doing God knows what with it. Rust treats memory safety as being of paramount importance and aims to do that with zero runtime cost. That's a great goal but it's also fundamentally different to Zig's goals.

notfed 2y ago
Well said. Though it'd be sorta neat IMO if we could use just one language here, and the memory unsafe aspect could somehow be toggled off or on, gaining all the pros or cons of Zig vs Rust as needed.
- lolinder 2y ago
  Are you thinking of something different than Rust's `unsafe`?
- cletus 2y ago
  What you're talking about here is disabling runtime assertions, which is a common practice in C/C++ (using #define macros). Runtime assertions are strictly inferior to Rust's compile-time assertions because Rust allows you to do a subset of what you can do in C/C++ but it verifies that the memory ownership is correct without a runtime cost, unsafe code notwithstanding). There simply is no way you could do that in C/C++ (and, by extension, Zig) because of the legacy support. I'm fine with having multiple languages. One language to rule them all just tends to mean something is mediocre at everything.
knighthack 2y ago
How is it a "better C" as compared to Go? Genuinely asking.
- Bilal_io 2y ago
  Go is a garbage collected language
- kstrauser 2y ago
  Go is garbage collected. That's a non-starter for a lot of C use cases.
- adrusi 2y ago
  Go has a heavy runtime, including both a garbage collector and a userland scheduler. Those features both make it inappropriate for some applications where you would use c, and also make calling (and especially being called from) foreign code problematic. You effectively cant implement a library in go and then call it from another language, not without considerable ffi overhead at the very least.
- ilrwbwrkhv 2y ago
  Go would be amazing if it didn't allow dumb mistakes such as: type Human struct { Name string MaybeHasCat *Cat } type Cat struct { Name string } func main() { h := Human{} h.MaybeHasCat.Name = "Taffy" } And boom. Null pointer exception because MaybeHasCat is null. The fact that go doesn't let you define an optional type is such a pain. A lot of newcomers while getting trained up fall for this bug. edit: updating to add the pointer i missed. also adding a playground link: https://go.dev/play/p/izcod8xF7ZQ https://go.dev/play/p/izcod8xF7ZQ
  - koeng 2y ago
    That’s not true. Here is a go playground of pretty much that exact code running just fine https://go.dev/play/p/v7OM9s_pRqY https://go.dev/play/p/v7OM9s_pRqY
    - 2y ago
overgard 2y ago
I'm not sure Rust is in the same space as C++, so I'm not sure I'd call it a better C++. I use C++ because I want performance without all the accounting operations that have to happen in C. I try to write my code in a safe way, but language safety just isn't a priority for me. I guess that's why I'm not using Rust. Fighting the borrow checker doesn't seem worth it to me to gain something that's just not that much of a priority. But I'm not writing an OS or a server. I'd think of Rust more like a better Ada or some language where safety is first priority
- cletus 2y ago
  Story time: Chrome is a Frankenstein of C and C++ code (both directly and through called libraries, static or dynamic). Now C++ has `std::string` obviously. C of course has `const char *`. To facilitate interoperability C++ has various methods to implicitly or explicitly convert between the two. At one point it was found these every keypress on the OmniBar resulted in 25,000 string copies. So my point is that you can write C++ as carefully as you can but on any sufficiently complex code base you'll going to need a pointer to something and then you've really lost all control and safety so the safety in C++ is a bit of an illusion.
  - senkora 2y ago
    Well, that's horrifying. Presumably the value is being copied whenever it is converted from a const char * to a std::string? The right thing (TM) would probably be to refactor some of the std::string's into std::string_view's, for instance by adding overloads where it makes sense. I doubt you could avoid all the copies, but I think you could cut it down substantially if you collected metrics and focused on the most egregious cases. Of course, I do not envy the person who is tasked with doing that, and I could be wrong for any number of arcane technical reasons.
    - dralley 2y ago
      I can only imagine that using std::string_view in a massive, complex application would be horrifying. The borrow checker is one of the benefits of Rust in that case, simply because you can avoid copies while actually being able to trust that you're not opening the door to security & maintenance hell in the process.
jandrewrogers 2y ago
I see Rust as neither a C nor C++ replacement, it feels more like a much less limited version of Java. Zig, on the other hand, feels more like a highly evolved C. As a pretty hardcore systems programmer, there are three things that modern C++ has first-class support for that are difficult to live without: metaprogramming, handling cases where ownership is unknowable at compile-time, handling cases where lifetimes are unknowable at compile-time. Rust is still significantly more limited than C++ in what it can express effectively. There are very few features in C++ that are not critical and routinely used in some application domain. A low-key strength of C++ is that it is not overfitted to any particular assumptions about application domain. This adds complexity (aside from complexity introduced by legacy and age) but with the benefit that there is a subset of C++ that is highly specialized for the requirements of almost any application domain.

by cletus 2y ago

notfed 2y ago

Well said. Though it'd be sorta neat IMO if we could use just one language here, and the memory unsafe aspect could somehow be toggled off or on, gaining all the pros or cons of Zig vs Rust as needed.

lolinder 2y ago
Are you thinking of something different than Rust's `unsafe`?
cletus 2y ago
What you're talking about here is disabling runtime assertions, which is a common practice in C/C++ (using #define macros). Runtime assertions are strictly inferior to Rust's compile-time assertions because Rust allows you to do a subset of what you can do in C/C++ but it verifies that the memory ownership is correct without a runtime cost, unsafe code notwithstanding). There simply is no way you could do that in C/C++ (and, by extension, Zig) because of the legacy support. I'm fine with having multiple languages. One language to rule them all just tends to mean something is mediocre at everything.

knighthack 2y ago

How is it a "better C" as compared to Go? Genuinely asking.

Bilal_io 2y ago
Go is a garbage collected language
kstrauser 2y ago
Go is garbage collected. That's a non-starter for a lot of C use cases.
adrusi 2y ago
Go has a heavy runtime, including both a garbage collector and a userland scheduler. Those features both make it inappropriate for some applications where you would use c, and also make calling (and especially being called from) foreign code problematic. You effectively cant implement a library in go and then call it from another language, not without considerable ffi overhead at the very least.
ilrwbwrkhv 2y ago
Go would be amazing if it didn't allow dumb mistakes such as: type Human struct { Name string MaybeHasCat *Cat } type Cat struct { Name string } func main() { h := Human{} h.MaybeHasCat.Name = "Taffy" } And boom. Null pointer exception because MaybeHasCat is null. The fact that go doesn't let you define an optional type is such a pain. A lot of newcomers while getting trained up fall for this bug. edit: updating to add the pointer i missed. also adding a playground link: https://go.dev/play/p/izcod8xF7ZQ https://go.dev/play/p/izcod8xF7ZQ
- koeng 2y ago
  That’s not true. Here is a go playground of pretty much that exact code running just fine https://go.dev/play/p/v7OM9s_pRqY https://go.dev/play/p/v7OM9s_pRqY
  - 2y ago

overgard 2y ago

I'm not sure Rust is in the same space as C++, so I'm not sure I'd call it a better C++. I use C++ because I want performance without all the accounting operations that have to happen in C. I try to write my code in a safe way, but language safety just isn't a priority for me. I guess that's why I'm not using Rust. Fighting the borrow checker doesn't seem worth it to me to gain something that's just not that much of a priority. But I'm not writing an OS or a server. I'd think of Rust more like a better Ada or some language where safety is first priority

cletus 2y ago
Story time: Chrome is a Frankenstein of C and C++ code (both directly and through called libraries, static or dynamic). Now C++ has `std::string` obviously. C of course has `const char *`. To facilitate interoperability C++ has various methods to implicitly or explicitly convert between the two. At one point it was found these every keypress on the OmniBar resulted in 25,000 string copies. So my point is that you can write C++ as carefully as you can but on any sufficiently complex code base you'll going to need a pointer to something and then you've really lost all control and safety so the safety in C++ is a bit of an illusion.
- senkora 2y ago
  Well, that's horrifying. Presumably the value is being copied whenever it is converted from a const char * to a std::string? The right thing (TM) would probably be to refactor some of the std::string's into std::string_view's, for instance by adding overloads where it makes sense. I doubt you could avoid all the copies, but I think you could cut it down substantially if you collected metrics and focused on the most egregious cases. Of course, I do not envy the person who is tasked with doing that, and I could be wrong for any number of arcane technical reasons.
  - dralley 2y ago
    I can only imagine that using std::string_view in a massive, complex application would be horrifying. The borrow checker is one of the benefits of Rust in that case, simply because you can avoid copies while actually being able to trust that you're not opening the door to security & maintenance hell in the process.

jandrewrogers 2y ago

I see Rust as neither a C nor C++ replacement, it feels more like a much less limited version of Java. Zig, on the other hand, feels more like a highly evolved C. As a pretty hardcore systems programmer, there are three things that modern C++ has first-class support for that are difficult to live without: metaprogramming, handling cases where ownership is unknowable at compile-time, handling cases where lifetimes are unknowable at compile-time. Rust is still significantly more limited than C++ in what it can express effectively. There are very few features in C++ that are not critical and routinely used in some application domain. A low-key strength of C++ is that it is not overfitted to any particular assumptions about application domain. This adds complexity (aside from complexity introduced by legacy and age) but with the benefit that there is a subset of C++ that is highly specialized for the requirements of almost any application domain.