Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How (memory) safe is Zig? (2021)

scattered-thoughts.net

Post reply on HN
Print view View original

31–40 of 88 posts

Re: How (memory) safe is Zig? (2021)

#31

Post by pizlonator »

jandrewrogers wrote: post #26
pizlonator wrote: post #23

Earlier quoted context omitted.

> Yeah. By adding a runtime. So? That doesn't make it any less safe or useful. In almost all uses of C and C++, the language already has a runtime. In the Gnu universe, it's the combination of libgcc, the loader, the various crt entrypoints, and libc. In the Apple version, it's libcompiler_rt and libSystem. Fil-C certainly adds more to the runtime, but it's not like there was no runtime before.

It makes it a lot less performant and there is no avoiding or mitigating that downside. C++ is often selected as a language instead of safer options for its unusual performance characteristics even among systems languages in practice. Fil-C is not a replacement for C++ generally, that oversells it. It might be a replacement for some C++ software without stringent performance requirements or a rigorously performance-e…

> It makes it a lot less performant and there is no avoiding or mitigating that downside.

You can’t possibly know that.

> C++ is often selected as a language instead of safer options for its unusual performance characteristics even among systems languages in practice.

Is that why sudo, bash, coreutils, and ssh are written in C?

Of course not.

C and C++ are often chosen because they make systems programming possible at all due to their direct access to syscall ABI.

> Fil-C is not a replacement for C++ generally, that oversells it.

I have made no such claim.

Fil-C means you cannot claim - as TFA claims - that it’s impossible to make C and C++ safe. You have to now hedge that claim with additional caveats about performance. And even then you’re on thin ice since the top perf problems in Fil-C are due to immaturity of its implementation (like the fact that linking is hella cheesy and the ABI is even cheesier).

> It might be a replacement for some C++ software without stringent performance requirements or a rigorously performance-engineered architecture. There is a lot of this software, often legacy.

It’s the opposite in my experience. For example, xzutils and simdutf have super lower overhead in Fil-C. In the case of SIMD code it’s because using SIMD amortizes Fil-C’s overheads.

Re: How (memory) safe is Zig? (2021)

#32

Post by pizlonator »

dustbunny wrote: post #29
jandrewrogers wrote: post #26

Earlier quoted context omitted.

It makes it a lot less performant and there is no avoiding or mitigating that downside. C++ is often selected as a language instead of safer options for its unusual performance characteristics even among systems languages in practice. Fil-C is not a replacement for C++ generally, that oversells it. It might be a replacement for some C++ software without stringent performance requirements or a rigorously performance-e…

> a lot less performant Is this just you speculating? How much is "a lot"? Where's the data? Let's get some benchmarks!

I mean bro isn’t totally wrong.

Fil-C’s perf sucks on some workloads. And it doesn’t suck on others.

Extreme examples to give you an idea:

- xzutils had about 1.2x overhead. So slower but totally usable.

- no noticeable overhead in shells, systems utilities, ssh, curl, etc. But that’s because they’re IO bound.

- 4x or sometimes maybe even higher overheads for things like JS engines, CPython, Lua, Tcl, etc. Also OpenSSL perf tests are around 4x I think.

But you’re on thin ice if you say that this is a reason why Fil-C will fail. So much of Fil-C’s overhead is due to known issues that I will fix eventually, like the function call ABI (which is hella cheesy right now because I just wanted to have something that works and haven’t actually made it good yet).

Re: How (memory) safe is Zig? (2021)

#33

Post by josephg »

rk06 wrote: post #25
agarren wrote: post #20

Earlier quoted context omitted.

That sounds a bit unfair. All that code that we neither wrote nor understood, I think in the case of Rust, it’s either the borrow checker or the compiler itself doing something it does best - i.e., “defining memory safety away”. If that’s the case, then labeling such tooling and language-enforced memory safety mechanisms as “a bunch of additional code…you didn’t write and…don’t understand” appears somewhat inaccurate…

It is quite fair as far as rust is concerned. For simple data structures, like doubly linked list,are hard problems for rust

So? That wasn't the claim. The GP poster said this:

> This can potentially lead to performance and/or control flow issues that get incredibly difficult to debug.

Writing a linked list in rust isn't difficult because of control flow issues, or because rust makes code harder to debug. (If you've spent any time in rust, you quickly learn that the opposite is true.) Linked lists are simply a bad match up for the constraints rust's borrow checker puts on your code.

In the same way, writing an OS kernel or a high performance b-tree is a hard problem for javascript. So what? Every language has things its bad at. Design your program differently or use a different language.

Re: How (memory) safe is Zig? (2021)

#34

Post by josephg »

codr7 wrote: post #19
90s_dev wrote: post #17

Earlier quoted context omitted.

What if -- stay with me now -- what if we solved it by just writing vastly less code , and having actually reusable code, instead of reinventing every type of wheel in every project? Maybe that's the real secret to sound code. Actual code reuse. I know it's a pipedream, but a man can dream, can't he?

The way we've done code reuse up to this point rarely lives up to its promises. I don't know what the solution is, but these days I'm a lot more likely to simply copy code over to a new project rather than try to build general purpose libraries. I feel like that's part of the mess Rust/Swift are getting themselves tangled up in, everything depends on everything which turns evolution into more and more of an uphill st…

Why? In C I'd understand. But cargo and the swift package manager work great.

By all means, rewrite little libraries instead of pulling in big ones. But if you're literally copy+pasting code between projects, it doesn't take much work to pull that code out into a shared library.

Re: How (memory) safe is Zig? (2021)

#35

Post by NIckGeek »

pizlonator wrote: post #5

> it seems impossible to secure c or c++ False. Fil-C secures C and C++. It’s more comprehensively safe than Rust (Fil-C has no escape hatches). And it’s compatible enough with C/C++ that you can think of it as an alternate clang target.

Fil-C is impressive and neat, but it does add a runtime to enforce memory safety which has a (in most cases acceptable) cost. That's a reasonable strategy, Java and many other langs took this approach. In research, languages like Dala are applying this approach to safe concurrency.

Rust attempts to enforce its guarantees statically which has the advantage of no runtime overhead but the disadvantage of no runtime knowledge.

Re: How (memory) safe is Zig? (2021)

#36

Post by pizlonator »

NIckGeek wrote: post #35
pizlonator wrote: post #5

> it seems impossible to secure c or c++ False. Fil-C secures C and C++. It’s more comprehensively safe than Rust (Fil-C has no escape hatches). And it’s compatible enough with C/C++ that you can think of it as an alternate clang target.

Fil-C is impressive and neat, but it does add a runtime to enforce memory safety which has a (in most cases acceptable) cost. That's a reasonable strategy, Java and many other langs took this approach. In research, languages like Dala are applying this approach to safe concurrency. Rust attempts to enforce its guarantees statically which has the advantage of no runtime overhead but the disadvantage of no runtime know…

Rust attempts to enforce guarantees statically, but in practice fails, because of pervasive use of `unsafe`.

Fil-C doesn't "add a runtime". C already has a runtime (loader, crt, compiler runtime, libc, etc)

Re: How (memory) safe is Zig? (2021)

#37

Post by NIckGeek »

pizlonator wrote: post #36
NIckGeek wrote: post #35

Earlier quoted context omitted.

Fil-C is impressive and neat, but it does add a runtime to enforce memory safety which has a (in most cases acceptable) cost. That's a reasonable strategy, Java and many other langs took this approach. In research, languages like Dala are applying this approach to safe concurrency. Rust attempts to enforce its guarantees statically which has the advantage of no runtime overhead but the disadvantage of no runtime know…

Rust attempts to enforce guarantees statically, but in practice fails, because of pervasive use of `unsafe`. Fil-C doesn't "add a runtime". C already has a runtime (loader, crt, compiler runtime, libc, etc)

> but in practice fails, because of pervasive use of `unsafe`.

Yes, in `unsafe` code typically dynamic checks or careful manual review is needed. However, most code is not `unsafe` and `unsafe` code is wrapped in safe APIs.

I'm aware C already has a runtime, this adds to it.

Re: How (memory) safe is Zig? (2021)

#38

Post by [deleted] »

pizlonator wrote: post #36
NIckGeek wrote: post #35

Earlier quoted context omitted.

Fil-C is impressive and neat, but it does add a runtime to enforce memory safety which has a (in most cases acceptable) cost. That's a reasonable strategy, Java and many other langs took this approach. In research, languages like Dala are applying this approach to safe concurrency. Rust attempts to enforce its guarantees statically which has the advantage of no runtime overhead but the disadvantage of no runtime know…

Rust attempts to enforce guarantees statically, but in practice fails, because of pervasive use of `unsafe`. Fil-C doesn't "add a runtime". C already has a runtime (loader, crt, compiler runtime, libc, etc)

[deleted]

Re: How (memory) safe is Zig? (2021)

#39

Post by Rusky »

pizlonator wrote: post #36
NIckGeek wrote: post #35

Earlier quoted context omitted.

Fil-C is impressive and neat, but it does add a runtime to enforce memory safety which has a (in most cases acceptable) cost. That's a reasonable strategy, Java and many other langs took this approach. In research, languages like Dala are applying this approach to safe concurrency. Rust attempts to enforce its guarantees statically which has the advantage of no runtime overhead but the disadvantage of no runtime know…

Rust attempts to enforce guarantees statically, but in practice fails, because of pervasive use of `unsafe`. Fil-C doesn't "add a runtime". C already has a runtime (loader, crt, compiler runtime, libc, etc)

The stuff Fil-C adds is on the same footing as `unsafe` code in Rust- its implementation isn't checked, but its surface area is designed so that (if the implementation is correct) the rest of the program can't break it.

Whether the amount and quality of this kind of code is comparable between the two approaches depends on the specific programs you're writing. Static checking, which can also be applied in more fine-grained ways to parts of the runtime (or its moral equivalent) is an interesting approach, depending on your goals.

Re: How (memory) safe is Zig? (2021)

#40

Post by BrouteMinou »

I don't know why we are still having this topic going on. Zig is not safe, period.

Zig gives you the control you need if that is what you want, safety isn't something Zig is chasing.

Safer than C, yeah, but not safe.

Rust = safe Zig = control

Pick your weapon for the foe in front of you.

Post reply on HN