5 ms·

I really feel for new languages that have to compete with Rust. It’s probably easier than it’s ever been to create a high quality new language but to get as go

I really feel for new languages that have to compete with Rust. It’s probably easier than it’s ever been to create a high quality new language but to get as good as Rust has become just takes so much time and collective effort that it can be out of reach for most ecosystems/groups of builders. Getting the language features just right (and including novel stuff) is just the beginning. Remember when Rust and Go were comparable? Feels like forever ago when they both just looked like “new systems programming languages” a we know how that turned out. For example Zig is probably the most impressive new language, and it’s got a ton of awesome stuff but the chance that I’m going to adopt it over a language with often comparable performance that is ALSO much safer? Rounds to zero. Maybe some day I’ll have the brain cells and skill to write code in zig and be confident I’m Not introducing a whole class of gnarly bugs, but it seems like I should just focus my limited brain power on writing high quality Rust code.

GoblinSlayer 1y ago
>but it seems like I should just focus my limited brain power on writing high quality Rust code. You're running out of brain for rust?
pjmlp 1y ago
Only thing impressive about Zig is the comptime abilities, all the rest is basically Modula-2 (1978) safety in C syntax. Pity that it has taken all these years for folks to finally embrace Modula-2/Object Pascal safety as the bare minimum in systems languages.
- ngrilly 1y ago
  I so much agree with this. When I started using Zig, memories from writing Pascal started coming back, and I realized I was fine writing Pascal with manual memory management, unlike C and C++ where segfaults were a more frequent problem.
  - pjmlp 1y ago
    I was lucky to have gone through a few BASICs (including compiled ones), Z80 and 68000 Assembly, and Turbo Pascal (3.0 - 6.0), before getting to learn C with Turbo C 2.0, although I had already a few books on C, which made be aware that C wasn't the be all end all, that a few decades later many that learned C after C89 kind of propagated as urban myth. Not only I was aware that there were other ways to do systems programming, I was educated that there were safer ways to achieve the same goals. My trasition to C++ came thanks to Borland having the TP/C++ symbiosis, which later became Delphi/C++.
    - ngrilly 1y ago
      If I remember well, the biggest difference between Pascal and C was that Pascal, unlike C, offered spatial memory safety (thanks to strings and arrays being represented as "fat" pointers including the length), but none of them offered temporal memory safety (heap-use-after-free and stack-use-after-return)?
      - pjmlp 1y ago
        Much more than that, first lets take into account no one really used plain ISO Pascal on PC, it was always dialects from UCSD Pascal, or eventually Object Pascal, created by Apple and adopted by Borland, TMT and others. Strings were indeed fat pointers, and for the usual critic of being limited to 255 characters, you could eventually use fat pointers to unbounded arrays, with functions to get the lower and upper bounds. Since Pascal supports pass by reference (var parameters), there was no need to mess up with pointers for in/out, or out parameters, thus one less scenario where pointers could go wrong. Memory allocation has special functions New() and Dispose() that are type aware, thus no need to do sizeof() that might go wrong. And there was Mark()/Release() for arena style programming as well. Numeric ranges, with bounds checking, was another one. Enumerations without implicit conversations. Bounds checking, checked arithemetic (this one depended on the build mode), IO checking, and a few other checked modes, naturally they could be disabled if needed. Mapped arrays, so you could get the memory address directly, while having bounds checking. Unbounded arrays provided a way to do slices, even if a bit verbose. Pointers were typed, no decays from arrays, although you could do exactly the same clever tricks as C, by callign specific functions like Adr, Succ, Pred,... Record variants required a specific tag, so while they weren't tracked, it was easier to spot if "unions" were being used properly. Units provided a much better encapsulation as header files + implementation, with selected type visibility. Yes, use after free, doing the wrong thing in mapped memory, or inline Assembly were the main ways how something could go wrong, but much less than with plain C. Which is why I tend to do my remarks with Zig, you will notice quite a few similarities with 1980's safety from the likes of Pascal and Modula-2, the later even better than those Pascal dialects, although Turbo Pascal eventually grew most of the Modula-2 features, plus plenty of C++ inspired ones as well. Hence why with the prices Ada compilers were being sold, and the "cheaper" Pascal dialects and Modula-2, it was yet another reason why it did not took off back then. Ironically GNU Pascal is no longer relevant, while GCC now supports Ada and Modula-2 as official frontends.
akkad33 1y ago
> Maybe some day I’ll have the brain cells and skill to write code in zig and be confident I’m Not introducing a whole class of gnarly bugs, but it seems like I should just focus my limited brain power on writing high Llms solve this problem
- Tiberium 1y ago
  I use LLMs almost daily, and they certainly don't "solve" the problem of finding bugs, not even in popular languages like TypeScript. They do help a lot, yes, but they haven't solved it completely.
  - akkad33 1y ago
    They can help automate the process. Eg from flask creator: https://youtu.be/tg61cevJthc?si=Kd8azCPwXYeb-gac https://youtu.be/tg61cevJthc?si=Kd8azCPwXYeb-gac
- MeetingsBrowser 1y ago
  > be confident I’m Not introducing a whole class of gnarly bugs I think LLMs are doing the exact opposite
- lionkor 1y ago
  If you think LLMs solve this problem, you should reevaluate your experience level and seniority.
  - akkad33 1y ago
    I've said nothing about my experience or seniority in this discussion, so I don't know how they are relevant
- hk__2 1y ago
  Using LLMs on a language you don’t already master is a sure way to introduce a lot of bugs.
  - 1y ago
baq 1y ago
> Remember when Rust and Go were comparable? They were never intended for the same niches. Go is a Java/Python replacement. Rust is more of a C/subset of C++ replacement. They were compared mostly because they had usable versions released at approximately the same time, but you (correctly) don’t see those comparisons anymore.
- pjmlp 1y ago
  Go is hardly a replacement with its weaker type system.
  - kitd 1y ago
    A weaker type system than Python?
    - pjmlp 1y ago
      Yes, as you can see for what is possible to express with Pyright. Just because Python is dynamic, doesn't mean it lacks the notion of a type system, or the whole set of concepts that Go has no way to express, like meta-classes, multiple inheritance, comprehensions (eager or lazy),.... Many folks going from Python to Go, would never done it if Python had a modern JIT on CPython, or the package management wasn't the way it is, hardly anything to do with the language itself.
      - GoblinSlayer 1y ago
        I don't quite understand what's the point of a type system when it's going to be defenestrated by dynamic typing. In javascript the typeof operator can be used to check the type.
        brokencode 1y ago
        The type system still allows organizing and abstracting code in standardized ways. Static type checking is nice and is certainly my preference, but dynamic type checking doesn’t mean no types. It means the types are checked at runtime.
logicchains 1y ago
>a language with often comparable performance that is ALSO much safer There are domains where performance is critical and safety isn't so important (e.g. video games). Zig has an advantage in such domains because of the pervasive support for passing around allocators in the standard library (avoiding hidden allocations, and allowing efficient memory reuse via block allocators), while in the Rust stdlib custom allocators are relatively cumbersome to use (and not easy to prove safe to the compiler).
- hardwaresofton 1y ago
  Agreed, I really like Zig's explicit allocation (and to be fair, lots of people from Rust like it too[0], it's just such an insane lift that who knows when it will stabilize) The new "managed" async strategy (I was previously mistaken thinking it was the same as sans-io) is also really intriguing IMO, and feels like a fantastic balance (people in Rust are doing this too, but for the unrelated reason of trying to support various async runtimes). [0]: https://github.com/rust-lang/rust/issues/32838 https://github.com/rust-lang/rust/issues/32838
bsder 1y ago
>For example Zig is probably the most impressive new language, and it’s got a ton of awesome stuff but the chance that I’m going to adopt it over a language with often comparable performance that is ALSO much safer? Rounds to zero. 1) Rust, in practice, is "safer" than Zig but doesn't seem to be "much safer". See: https://mitchellh.com/writing/ghostty-gtk-rewrite https://mitchellh.com/writing/ghostty-gtk-rewrite > Our Zig codebase had one leak and one undefined memory access. That was really surprising to me (in a good way). Our Zig codebase is large, complex, and uses tons of memory tricks for performance that could easily lead to unsafe behaviors. I thought we'd have a lot more issues, honestly. Also, the one leak found was during calling a 3rd party C API (so Zig couldn't detect it). So this is a huge success. Take that as you will. And what Ghostty does probably requires a decent chunk of "unsafe" that would likely hide a bug anyway. To me, the tradeoff of a demonstrably small number of bugs in a system software language in return for the demonstrably faster developer velocity (Zig compiles WAY faster than Rust, Zig wraps C/C++ libraries way easier than Rust, Zig cross compiles way more easily, etc.) is a decent tradeoff for my use cases. For me, programming is about corralling motivation more than anything else. Rust saps my motivation is ways that Zig does not. I love what the Oxide folks are doing. Having someone pwn your big server because of a memory bug? Yeah, I'd reach for Rust in their use cases. Or, if I'm handling credit cards, I'll have a very different set of tradeoffs that swing against Zig. (Although, in that case, I'll probably reach for a GC language in that case so that I don't have to think about memory management at all.) 2) Rust is to C++ like Zig is to C. Zig is simply a much smaller language than Rust. I use Zig because my brain isn't big enough for either C++ or Rust. I'm not a 10x programmer, but I still want to get stuff done. Zig and C enable me to do that without bending my brain.
- bilkow 1y ago
  (not your parent commenter) > For me, programming is about corralling motivation more than anything else. Rust saps my motivation is ways that Zig does not. Yes, agree with you a lot! Maybe our brains are just wired differently, for me, no other language (until now) gives me as much motivation as Rust, as it's type system and docs make me feel really good. > Zig is simply a much smaller language than Rust. I use Zig because my brain isn't big enough for either C++ or Rust. Disclaimer: haven't really tried Zig yet. IMO you don't need to keep the whole of Rust in your brain to use it, I usually can just focus on the business logic as if I make a stupid mistake, the compiler will catch it. That (and the type system) is what makes me more efficient with it than other langs. I also stay clear of lifetimes unless I really need them (which is almost never for application code). An extreme example of the opposite is C, where I need to take care about anything I do as it will just accept anything (e.g. auto casting types) so I need to be vigilant about everything. All of that said, there are patterns that will just be harder to reason about in Rust, mostly with self-referential things, and if you area already used to using them a lot, this can be a hassle. If you're used to smaller data structures and data-oriented programming, it will be a lot easier. This is not trying to convince you or anyone else, just showing a different perspective. If you feel better with Zig, use it! Everyone has their own experience.

GoblinSlayer 1y ago

>but it seems like I should just focus my limited brain power on writing high quality Rust code. You're running out of brain for rust?

pjmlp 1y ago

Only thing impressive about Zig is the comptime abilities, all the rest is basically Modula-2 (1978) safety in C syntax. Pity that it has taken all these years for folks to finally embrace Modula-2/Object Pascal safety as the bare minimum in systems languages.

ngrilly 1y ago
I so much agree with this. When I started using Zig, memories from writing Pascal started coming back, and I realized I was fine writing Pascal with manual memory management, unlike C and C++ where segfaults were a more frequent problem.
- pjmlp 1y ago
  I was lucky to have gone through a few BASICs (including compiled ones), Z80 and 68000 Assembly, and Turbo Pascal (3.0 - 6.0), before getting to learn C with Turbo C 2.0, although I had already a few books on C, which made be aware that C wasn't the be all end all, that a few decades later many that learned C after C89 kind of propagated as urban myth. Not only I was aware that there were other ways to do systems programming, I was educated that there were safer ways to achieve the same goals. My trasition to C++ came thanks to Borland having the TP/C++ symbiosis, which later became Delphi/C++.
  - ngrilly 1y ago
    If I remember well, the biggest difference between Pascal and C was that Pascal, unlike C, offered spatial memory safety (thanks to strings and arrays being represented as "fat" pointers including the length), but none of them offered temporal memory safety (heap-use-after-free and stack-use-after-return)?
    - pjmlp 1y ago
      Much more than that, first lets take into account no one really used plain ISO Pascal on PC, it was always dialects from UCSD Pascal, or eventually Object Pascal, created by Apple and adopted by Borland, TMT and others. Strings were indeed fat pointers, and for the usual critic of being limited to 255 characters, you could eventually use fat pointers to unbounded arrays, with functions to get the lower and upper bounds. Since Pascal supports pass by reference (var parameters), there was no need to mess up with pointers for in/out, or out parameters, thus one less scenario where pointers could go wrong. Memory allocation has special functions New() and Dispose() that are type aware, thus no need to do sizeof() that might go wrong. And there was Mark()/Release() for arena style programming as well. Numeric ranges, with bounds checking, was another one. Enumerations without implicit conversations. Bounds checking, checked arithemetic (this one depended on the build mode), IO checking, and a few other checked modes, naturally they could be disabled if needed. Mapped arrays, so you could get the memory address directly, while having bounds checking. Unbounded arrays provided a way to do slices, even if a bit verbose. Pointers were typed, no decays from arrays, although you could do exactly the same clever tricks as C, by callign specific functions like Adr, Succ, Pred,... Record variants required a specific tag, so while they weren't tracked, it was easier to spot if "unions" were being used properly. Units provided a much better encapsulation as header files + implementation, with selected type visibility. Yes, use after free, doing the wrong thing in mapped memory, or inline Assembly were the main ways how something could go wrong, but much less than with plain C. Which is why I tend to do my remarks with Zig, you will notice quite a few similarities with 1980's safety from the likes of Pascal and Modula-2, the later even better than those Pascal dialects, although Turbo Pascal eventually grew most of the Modula-2 features, plus plenty of C++ inspired ones as well. Hence why with the prices Ada compilers were being sold, and the "cheaper" Pascal dialects and Modula-2, it was yet another reason why it did not took off back then. Ironically GNU Pascal is no longer relevant, while GCC now supports Ada and Modula-2 as official frontends.

akkad33 1y ago

> Maybe some day I’ll have the brain cells and skill to write code in zig and be confident I’m Not introducing a whole class of gnarly bugs, but it seems like I should just focus my limited brain power on writing high Llms solve this problem

Tiberium 1y ago
I use LLMs almost daily, and they certainly don't "solve" the problem of finding bugs, not even in popular languages like TypeScript. They do help a lot, yes, but they haven't solved it completely.
- akkad33 1y ago
  They can help automate the process. Eg from flask creator: https://youtu.be/tg61cevJthc?si=Kd8azCPwXYeb-gac https://youtu.be/tg61cevJthc?si=Kd8azCPwXYeb-gac
MeetingsBrowser 1y ago
> be confident I’m Not introducing a whole class of gnarly bugs I think LLMs are doing the exact opposite
lionkor 1y ago
If you think LLMs solve this problem, you should reevaluate your experience level and seniority.
- akkad33 1y ago
  I've said nothing about my experience or seniority in this discussion, so I don't know how they are relevant
hk__2 1y ago
Using LLMs on a language you don’t already master is a sure way to introduce a lot of bugs.
- 1y ago

baq 1y ago

> Remember when Rust and Go were comparable? They were never intended for the same niches. Go is a Java/Python replacement. Rust is more of a C/subset of C++ replacement. They were compared mostly because they had usable versions released at approximately the same time, but you (correctly) don’t see those comparisons anymore.

pjmlp 1y ago
Go is hardly a replacement with its weaker type system.
- kitd 1y ago
  A weaker type system than Python?
  - pjmlp 1y ago
    Yes, as you can see for what is possible to express with Pyright. Just because Python is dynamic, doesn't mean it lacks the notion of a type system, or the whole set of concepts that Go has no way to express, like meta-classes, multiple inheritance, comprehensions (eager or lazy),.... Many folks going from Python to Go, would never done it if Python had a modern JIT on CPython, or the package management wasn't the way it is, hardly anything to do with the language itself.
    - GoblinSlayer 1y ago
      I don't quite understand what's the point of a type system when it's going to be defenestrated by dynamic typing. In javascript the typeof operator can be used to check the type.
      - brokencode 1y ago
        The type system still allows organizing and abstracting code in standardized ways. Static type checking is nice and is certainly my preference, but dynamic type checking doesn’t mean no types. It means the types are checked at runtime.

logicchains 1y ago

>a language with often comparable performance that is ALSO much safer There are domains where performance is critical and safety isn't so important (e.g. video games). Zig has an advantage in such domains because of the pervasive support for passing around allocators in the standard library (avoiding hidden allocations, and allowing efficient memory reuse via block allocators), while in the Rust stdlib custom allocators are relatively cumbersome to use (and not easy to prove safe to the compiler).

hardwaresofton 1y ago
Agreed, I really like Zig's explicit allocation (and to be fair, lots of people from Rust like it too[0], it's just such an insane lift that who knows when it will stabilize) The new "managed" async strategy (I was previously mistaken thinking it was the same as sans-io) is also really intriguing IMO, and feels like a fantastic balance (people in Rust are doing this too, but for the unrelated reason of trying to support various async runtimes). [0]: https://github.com/rust-lang/rust/issues/32838 https://github.com/rust-lang/rust/issues/32838

bsder 1y ago

>For example Zig is probably the most impressive new language, and it’s got a ton of awesome stuff but the chance that I’m going to adopt it over a language with often comparable performance that is ALSO much safer? Rounds to zero. 1) Rust, in practice, is "safer" than Zig but doesn't seem to be "much safer". See: https://mitchellh.com/writing/ghostty-gtk-rewrite https://mitchellh.com/writing/ghostty-gtk-rewrite > Our Zig codebase had one leak and one undefined memory access. That was really surprising to me (in a good way). Our Zig codebase is large, complex, and uses tons of memory tricks for performance that could easily lead to unsafe behaviors. I thought we'd have a lot more issues, honestly. Also, the one leak found was during calling a 3rd party C API (so Zig couldn't detect it). So this is a huge success. Take that as you will. And what Ghostty does probably requires a decent chunk of "unsafe" that would likely hide a bug anyway. To me, the tradeoff of a demonstrably small number of bugs in a system software language in return for the demonstrably faster developer velocity (Zig compiles WAY faster than Rust, Zig wraps C/C++ libraries way easier than Rust, Zig cross compiles way more easily, etc.) is a decent tradeoff for my use cases. For me, programming is about corralling motivation more than anything else. Rust saps my motivation is ways that Zig does not. I love what the Oxide folks are doing. Having someone pwn your big server because of a memory bug? Yeah, I'd reach for Rust in their use cases. Or, if I'm handling credit cards, I'll have a very different set of tradeoffs that swing against Zig. (Although, in that case, I'll probably reach for a GC language in that case so that I don't have to think about memory management at all.) 2) Rust is to C++ like Zig is to C. Zig is simply a much smaller language than Rust. I use Zig because my brain isn't big enough for either C++ or Rust. I'm not a 10x programmer, but I still want to get stuff done. Zig and C enable me to do that without bending my brain.

bilkow 1y ago
(not your parent commenter) > For me, programming is about corralling motivation more than anything else. Rust saps my motivation is ways that Zig does not. Yes, agree with you a lot! Maybe our brains are just wired differently, for me, no other language (until now) gives me as much motivation as Rust, as it's type system and docs make me feel really good. > Zig is simply a much smaller language than Rust. I use Zig because my brain isn't big enough for either C++ or Rust. Disclaimer: haven't really tried Zig yet. IMO you don't need to keep the whole of Rust in your brain to use it, I usually can just focus on the business logic as if I make a stupid mistake, the compiler will catch it. That (and the type system) is what makes me more efficient with it than other langs. I also stay clear of lifetimes unless I really need them (which is almost never for application code). An extreme example of the opposite is C, where I need to take care about anything I do as it will just accept anything (e.g. auto casting types) so I need to be vigilant about everything. All of that said, there are patterns that will just be harder to reason about in Rust, mostly with self-referential things, and if you area already used to using them a lot, this can be a hassle. If you're used to smaller data structures and data-oriented programming, it will be a lot easier. This is not trying to convince you or anyone else, just showing a different perspective. If you feel better with Zig, use it! Everyone has their own experience.