4 ms·

While some of the features the author references are really interesting, personally I don't see how any of that would justify creating a new memory unsafe langu

by jsiepkes 11mo ago

While some of the features the author references are really interesting, personally I don't see how any of that would justify creating a new memory unsafe language in 2016. I thought it was pretty obvious by now [1][2][3] memory safety is best left to tooling / compilers and not to programmers. [1] https://research.google/pubs/secure-by-design-googles-perspective-on-memory-safety/ https://research.google/pubs/secure-by-design-googles-perspe... [2] https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-safer-systems-programming-language https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-... [3] https://www.cisa.gov/case-memory-safe-roadmaps https://www.cisa.gov/case-memory-safe-roadmaps

1718627440 11mo ago
This sound a bit like Tanenbaum's rejection of Torvals' project, because monolithic kernels are obsolete.
- xiffle 11mo ago
  Tanenbaum was right, the future of the Linux kernel is dire, and it's been a huge setback to operating systems research in practical terms. Fortunately, vendors are gradually moving away from Linux, having been hamstrung by its failures. Google is planning to move to a capability-based microkernel in the coming years for Android and ChromeOS, and Huawei has already done so with HarmonyOS. In a hundred years, Linux will be a footnote in computing history.
  - 1718627440 11mo ago
    Irregardless of whether this is true, it has not prevented adoption of Linux.
    - xiffle 11mo ago
      And McDonalds is one of the most popular restaurants worldwide despite the questionable food quality.
- pjmlp 11mo ago
  Most OSes use either hybrid kernels, or type 1 hypervisors, which are microkernels by another name.
  - Dylan16807 11mo ago
    If 10% of your OS code is in a small piece that might be called a microkernel, and 90% is in one huge blob that implements everything else, then you don't really have a microkernel OS. Or to phrase that more directly at the point: for monolithic kernels to be obsolete you have to break up the monolithic part, not just shim a microkernel hypervisor on top of it.
    - pjmlp 11mo ago
      Depends on which OS, there are more than three out there. Additionally there is a certain irony to use a monolithic Linux kernel, only to drown it on layers and layers of containers with Kubernetes.
vkazanov 11mo ago
Unlike C/C++, Zig is not inherently memory-unsafe. Where Rust insists on having either partial safety through the checker or lack of control in unsafe code, Zig provides a toolkit for contructing safe frameworks. Zig also doesn't have main sources of unsafety coming from certain C design mistakes. Besides, if you are after true memory safety then garbage collection is the way to go.
wffurr 11mo ago
I think even in the year of our lord 2016 there's room for a language with safe defaults but seamless interoperability with existing unsafe code. It's certainly an improvement on the status quo and provides an alternative to rewriting the world in Rust or a GC language.
- pjmlp 11mo ago
  Except Zig defaults could be found on the year of our Lord in 1976, 1978, 1983 and 1986. Exercise from other posts of mine which languages those might be.
  - wffurr 11mo ago
    Sure, but Zig is bringing those to users and making headlines on HN. I think that’s generally a good thing. Bringing the best of prior languages together in a new package
    - pjmlp 11mo ago
      Except in 2025 we know better regarding safer systems programming languages, use after free is no longer something that we should tolerate.
      - justinhj 11mo ago
        It's way to early to declare Rust and borrow checking as a panacea for systems level languages. Zig has a solid story for memory safety but makes a different set of trade offs than Rust. IMHO there is room for a few different approaches to systems programming.
  - smj-edison 11mo ago
    I've been programming in rust for three years, until I picked up zig recently. I was also worried about memory safety when I started using it, but I've been pleasantly surprised how many safety features it has (it's certainly been easier to debug than the C code I've had to work with). Slices are often mentioned for safety, which they are great, but even better has been all of the casting functions. In Debug and ReleaseSafe mode, @intCast will panic if you try to narrow on integer that's too big. @alignCast checks that the alignment is correct. @bitCast ensures that both types have the same bit width. Non-packed unions will panic if you access the wrong field. Integer under and overflow has revealed some of my bad code like four times now. defer/errdefer is much easier to reason about that "goto cleanup" (it also lets me write custom cleanup code, instead of being beholden to the author's drop implementation). So no, it's not as safe as rust in terms of memory, but it's quite close, and in the process lets you do some really cool stuff.

1718627440 11mo ago

This sound a bit like Tanenbaum's rejection of Torvals' project, because monolithic kernels are obsolete.

xiffle 11mo ago
Tanenbaum was right, the future of the Linux kernel is dire, and it's been a huge setback to operating systems research in practical terms. Fortunately, vendors are gradually moving away from Linux, having been hamstrung by its failures. Google is planning to move to a capability-based microkernel in the coming years for Android and ChromeOS, and Huawei has already done so with HarmonyOS. In a hundred years, Linux will be a footnote in computing history.
- 1718627440 11mo ago
  Irregardless of whether this is true, it has not prevented adoption of Linux.
  - xiffle 11mo ago
    And McDonalds is one of the most popular restaurants worldwide despite the questionable food quality.
pjmlp 11mo ago
Most OSes use either hybrid kernels, or type 1 hypervisors, which are microkernels by another name.
- Dylan16807 11mo ago
  If 10% of your OS code is in a small piece that might be called a microkernel, and 90% is in one huge blob that implements everything else, then you don't really have a microkernel OS. Or to phrase that more directly at the point: for monolithic kernels to be obsolete you have to break up the monolithic part, not just shim a microkernel hypervisor on top of it.
  - pjmlp 11mo ago
    Depends on which OS, there are more than three out there. Additionally there is a certain irony to use a monolithic Linux kernel, only to drown it on layers and layers of containers with Kubernetes.

vkazanov 11mo ago

Unlike C/C++, Zig is not inherently memory-unsafe. Where Rust insists on having either partial safety through the checker or lack of control in unsafe code, Zig provides a toolkit for contructing safe frameworks. Zig also doesn't have main sources of unsafety coming from certain C design mistakes. Besides, if you are after true memory safety then garbage collection is the way to go.

wffurr 11mo ago

I think even in the year of our lord 2016 there's room for a language with safe defaults but seamless interoperability with existing unsafe code. It's certainly an improvement on the status quo and provides an alternative to rewriting the world in Rust or a GC language.

pjmlp 11mo ago
Except Zig defaults could be found on the year of our Lord in 1976, 1978, 1983 and 1986. Exercise from other posts of mine which languages those might be.
- wffurr 11mo ago
  Sure, but Zig is bringing those to users and making headlines on HN. I think that’s generally a good thing. Bringing the best of prior languages together in a new package
  - pjmlp 11mo ago
    Except in 2025 we know better regarding safer systems programming languages, use after free is no longer something that we should tolerate.
    - justinhj 11mo ago
      It's way to early to declare Rust and borrow checking as a panacea for systems level languages. Zig has a solid story for memory safety but makes a different set of trade offs than Rust. IMHO there is room for a few different approaches to systems programming.
- smj-edison 11mo ago
  I've been programming in rust for three years, until I picked up zig recently. I was also worried about memory safety when I started using it, but I've been pleasantly surprised how many safety features it has (it's certainly been easier to debug than the C code I've had to work with). Slices are often mentioned for safety, which they are great, but even better has been all of the casting functions. In Debug and ReleaseSafe mode, @intCast will panic if you try to narrow on integer that's too big. @alignCast checks that the alignment is correct. @bitCast ensures that both types have the same bit width. Non-packed unions will panic if you access the wrong field. Integer under and overflow has revealed some of my bad code like four times now. defer/errdefer is much easier to reason about that "goto cleanup" (it also lets me write custom cleanup code, instead of being beholden to the author's drop implementation). So no, it's not as safe as rust in terms of memory, but it's quite close, and in the process lets you do some really cool stuff.