6 ms·

<rust evangelism strike force> It sounds like the complaints here are operator overloading, global allocator by default, and metaprogramming. I think the value

<rust evangelism strike force> It sounds like the complaints here are operator overloading, global allocator by default, and metaprogramming. I think the value of these features are certainly not objective, but it's not a very compelling argument to avoid a language because of them. As for optional standard library support, this is actually really common in Rust and is a breeze to support. Just annotating [no_std] basically gets you there libc wise. There's even additional restrictions like [no_core] to remove even more. I believe this should be noted. I think the author missed an opportunity to really drill into actual pain points like the steep learning curves to c++ and rust, and where/if Zig excels in specific examples. </rust evangelism strike force>

mhh__ 6y ago
I guess I would be in the D evangelism strike force, but I concur. D also has a really rather nice composable allocator system in the standard library.
nynx 6y ago
Rust is also getting configurable allocators soon. Most standard collections will take an additional, optional allocator. There are also a few people who want to rethink the design of allocators to allow for inline storage. It definitely sounds interesting, but may end up being too complicated.
- mmastrac 6y ago
  Do you have a link to the RFC for this? This sounds awesome. EDIT: thanks to the links below I found this [1] and this [2] [1] https://github.com/rust-lang/rust/issues/32838 https://github.com/rust-lang/rust/issues/32838 [2] https://github.com/rust-lang/rfcs/pull/1398 https://github.com/rust-lang/rfcs/pull/1398
  - swsieber 6y ago
    While I don't have an RFC your you (I'm not the same person), here's an interesting thread on maybe tweaking the interface: https://internals.rust-lang.org/t/is-custom-allocators-the-right-abstraction/13460 https://internals.rust-lang.org/t/is-custom-allocators-the-r...
    - troutwine 6y ago
      And here's the working group's repo: https://github.com/rust-lang/wg-allocators https://github.com/rust-lang/wg-allocators
  - nynx 6y ago
    I'm not sure there's an up-to-date RFC, but here's what it looks like: https://doc.rust-lang.org/nightly/std/boxed/struct.Box.html#method.new_in https://doc.rust-lang.org/nightly/std/boxed/struct.Box.html#...
    - secondcoming 6y ago
      Will they avoid the Transparent Comparator fudge that C++ has because the allocator is part of the type? https://stackoverflow.com/questions/20317413/what-are-transparent-comparators https://stackoverflow.com/questions/20317413/what-are-transp...
      - nynx 6y ago
        Could you elaborate on what this is, exactly?
        secondcoming 6y ago
        In short, it allows a std::map<K, V> to be queried with a type that isn't K. For example, std::map<std::string, int> m; std::string_view sv = "mykey"; auto&& iter = m.find(sv);
        nynx 6y ago
        Oh, rust already has that.
deleted 6y ago
[deleted]
pron 6y ago
> but it's not a very compelling argument to avoid a language because of them. You're looking at it from the wrong direction. Both Zig and Rust target low-level programming, i.e. domains where C and C++ are very established. You don't need a reason to avoid a language -- you need a reason to invest a great amount of effort to switch away from an established incumbent. Now, my biggest issues with C++ are, in this order: 1. language complexity, which makes understanding and changing codebases harder, 2. long compilation times which lengthen cycles and reduce software quality, 3. lack of memory safety. Rust improves on 1 a tiny bit, and solves 3. Zig solves 1, 2, and almost completely 3. This means that I have little reason to even consider switching to Rust; I will only if it ever becomes dominant. I wouldn't switch to Zig right now -- it still needs to prove itself, but at least it's a contender, because it offers something quite radical. Rather than an improved C++, it is a whole new way to think of low-level programming, it seems to address precisely the things that bother me about C++, plus it focuses on other aspects that are very important to low-level programming, like cross-compilation.
- NOGDP 6y ago
  > 2. long compilation times which lengthen cycles and reduce software quality Seems like something that will be improved over time in Rust. Do you see any advantages of Rust over Zig, which wouldn't fall under point 3?
  - pron 6y ago
    No, although language preference is subjective. Rust is a language in the C++ tradition and, like C++, is one of the most complicated programming languages in the history of software, while Zig is probably among the simplest. Some people like elaborate languages and find the design, which mixes C++ and ML appealing. Zig is unlike anything else. I would say that the biggest philosophical difference is this. While Zig and C++/Rust are all low-level languages and so suffer from low abstraction (it comes with the territory) -- i.e. implementation details are hard to hide, and changing them requires changing in the APIs clients -- C++/Rust invest a lot of complexity in trying to make the code, once written, look as if the language has good abstraction. The code is still as hard to change, but it looks like a high-level language on the page. Some people may like that, but Zig completely rejects that.
iFreilicht 6y ago
The “no metaprogramming” is a bit of a misnomer. The thing is that Zig uses the exact same syntax for metaprogramming as for regular programming, you just add the comptime keyword and use types like variables. This is a much more ergonomic approach than having a completely separate syntax, which is really common and imho annoying in other languages.

mhh__ 6y ago

I guess I would be in the D evangelism strike force, but I concur. D also has a really rather nice composable allocator system in the standard library.

nynx 6y ago

Rust is also getting configurable allocators soon. Most standard collections will take an additional, optional allocator. There are also a few people who want to rethink the design of allocators to allow for inline storage. It definitely sounds interesting, but may end up being too complicated.

mmastrac 6y ago
Do you have a link to the RFC for this? This sounds awesome. EDIT: thanks to the links below I found this [1] and this [2] [1] https://github.com/rust-lang/rust/issues/32838 https://github.com/rust-lang/rust/issues/32838 [2] https://github.com/rust-lang/rfcs/pull/1398 https://github.com/rust-lang/rfcs/pull/1398
- swsieber 6y ago
  While I don't have an RFC your you (I'm not the same person), here's an interesting thread on maybe tweaking the interface: https://internals.rust-lang.org/t/is-custom-allocators-the-right-abstraction/13460 https://internals.rust-lang.org/t/is-custom-allocators-the-r...
  - troutwine 6y ago
    And here's the working group's repo: https://github.com/rust-lang/wg-allocators https://github.com/rust-lang/wg-allocators
- nynx 6y ago
  I'm not sure there's an up-to-date RFC, but here's what it looks like: https://doc.rust-lang.org/nightly/std/boxed/struct.Box.html#method.new_in https://doc.rust-lang.org/nightly/std/boxed/struct.Box.html#...
  - secondcoming 6y ago
    Will they avoid the Transparent Comparator fudge that C++ has because the allocator is part of the type? https://stackoverflow.com/questions/20317413/what-are-transparent-comparators https://stackoverflow.com/questions/20317413/what-are-transp...
    - nynx 6y ago
      Could you elaborate on what this is, exactly?
      - secondcoming 6y ago
        In short, it allows a std::map<K, V> to be queried with a type that isn't K. For example, std::map<std::string, int> m; std::string_view sv = "mykey"; auto&& iter = m.find(sv);
        nynx 6y ago
        Oh, rust already has that.

deleted 6y ago

[deleted]

pron 6y ago

> but it's not a very compelling argument to avoid a language because of them. You're looking at it from the wrong direction. Both Zig and Rust target low-level programming, i.e. domains where C and C++ are very established. You don't need a reason to avoid a language -- you need a reason to invest a great amount of effort to switch away from an established incumbent. Now, my biggest issues with C++ are, in this order: 1. language complexity, which makes understanding and changing codebases harder, 2. long compilation times which lengthen cycles and reduce software quality, 3. lack of memory safety. Rust improves on 1 a tiny bit, and solves 3. Zig solves 1, 2, and almost completely 3. This means that I have little reason to even consider switching to Rust; I will only if it ever becomes dominant. I wouldn't switch to Zig right now -- it still needs to prove itself, but at least it's a contender, because it offers something quite radical. Rather than an improved C++, it is a whole new way to think of low-level programming, it seems to address precisely the things that bother me about C++, plus it focuses on other aspects that are very important to low-level programming, like cross-compilation.

NOGDP 6y ago
> 2. long compilation times which lengthen cycles and reduce software quality Seems like something that will be improved over time in Rust. Do you see any advantages of Rust over Zig, which wouldn't fall under point 3?
- pron 6y ago
  No, although language preference is subjective. Rust is a language in the C++ tradition and, like C++, is one of the most complicated programming languages in the history of software, while Zig is probably among the simplest. Some people like elaborate languages and find the design, which mixes C++ and ML appealing. Zig is unlike anything else. I would say that the biggest philosophical difference is this. While Zig and C++/Rust are all low-level languages and so suffer from low abstraction (it comes with the territory) -- i.e. implementation details are hard to hide, and changing them requires changing in the APIs clients -- C++/Rust invest a lot of complexity in trying to make the code, once written, look as if the language has good abstraction. The code is still as hard to change, but it looks like a high-level language on the page. Some people may like that, but Zig completely rejects that.

iFreilicht 6y ago

The “no metaprogramming” is a bit of a misnomer. The thing is that Zig uses the exact same syntax for metaprogramming as for regular programming, you just add the comptime keyword and use types like variables. This is a much more ergonomic approach than having a completely separate syntax, which is really common and imho annoying in other languages.