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

Maintain It with Zig

kristoff.it

Post reply on HN
Print view View original

121–130 of 286 posts

Re: Maintain It with Zig

#121

Post by pjmlp »

mumblemumble wrote: post #68
heavyset_go wrote: post #60

Earlier quoted context omitted.

> It seems, from looking at others' code, that there is a very strong temptation to lean on `unsafe` instead of figuring out how to solve a problem within the constraints it normally applies. Are you sure those examples of unsafe Rust code were written using unsafe in order to work around safety constraints due to difficulty? I ask because there are some very real and valid use cases for unsafe code in Rust that have…

Not sure at all - I have effectively zero working knowledge of Rust - and certainly not looking to second-guess people's motivations for using the feature. The big bias I'm working from here is that, as an outsider, I have a hard time reconciling all the big talk about how Rust makes it impossible to experience certain classes of bugs, with the existence of a known set of things that its type checker can't check, and…

All systems programming languages need the ability to do unsafe stuff, the big difference between C , C++, Objective-C and all the remaining system programming languages since JOVIAL and NEWP, is the explicit unsafe code blocks that make that visible.

It is a big difference to have it on your face that something might need to be properly double checked and having each line of code as possible security exploit.

Re: Maintain It with Zig

#122

Post by pjmlp »

pharke wrote: post #90

I prefer D, it can be fully compatible with C, the syntax is easy to learn if you've used any of the C family you already know 80%, the package system is simple, modules mean no more headers or include statements just import things where and when you need them, supports every style of programming, QOL improvements like ranges and foreach, proper strings, optional garbage collector, has a long history of continuous im…

Me too, I really wished some nice corporation would give it the adoption boost it needs.

Re: Maintain It with Zig

#124

Post by Arnavion »

mumblemumble wrote: post #50
JoshTriplett wrote: post #34

Earlier quoted context omitted.

> Would it be fair to say that Zig is to C, what Rust is to C++? I don't think that's the parallel I would draw. Rather, I think both Zig and Rust aim to serve the use cases C and C++ do, but Zig and Rust pick different points on the tradeoffs involving safety. Zig feels like a "better C", in the sense of bringing modern language features to C, but it chooses safer rather than safe . Rust supplies modern language fea…

disclaimer: I haven't actually used either, just done a lot of interested reading and a little toying around. One thing that impressed me about Zig is how simple the language is. I get the impression that it would take very little time to properly learn the language and become effective at it. Rust, on the other hand, has a whole lot of complexity even without the ownership semantics. So much to learn and understand.…

Is

    char* c_foo(char* bar) { ... }
simpler than

    fn rust_foo(bar: &'a str) -> &'a str { ... }
?

On the one hand, c_foo is shorter and doesn't use strange symbols. On the other hand, rust_foo doesn't leave you guessing on whether the returned value needs to be free()d or not, and whether the heap allocation backing `bar` can be free()d after the call or not.

Re: Maintain It with Zig

#125

Post by pjmlp »

habibur wrote: post #7
sandwichbop wrote: post #2

Interesting read and I agree that growth in technical debt is something to worry about. I want to get more involved and been trying my best to learn the skills needed but there’s so much to consider that it’s a bit overwhelming. I’m not familiar with Zig, it’s neat that it has a toolchain that can compile C/C++ but it reminds me a lot of Nim. Could someone explain to me some differences between the two and why you wo…

Nim is garbage collected, thus is a higher level language but doesn't fit the high performance low overhead of "systems programming" requirement. While Zig is manual memory managed like C and nearer to the core, but harder to program.

https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...

https://tinygo.org/

https://www.ptc.com/en/products/developer-tools/perc

Re: Maintain It with Zig

#126

Post by adamdusty »

kllrnohj wrote: post #101
wyldfire wrote: post #85

Earlier quoted context omitted.

But Zig makes this tradeoff intentionally. By design.

"It's intentionally less safe! That's why you should use it!" Zig may strike a better balance than Rust does here, but it seems more like Rust stole its lunch. I don't know why I'd migrate from C/C++ to Zig instead of going all the way to Rust?

You wouldn't because you already know Rust. The mental overhead of Zig is essentially zero if you already know C. Also, generics and other syntax is cleaner in my opinion, but that doesn't matter that much.

Re: Maintain It with Zig

#127

Post by gavinray »

pharke wrote: post #90

I prefer D, it can be fully compatible with C, the syntax is easy to learn if you've used any of the C family you already know 80%, the package system is simple, modules mean no more headers or include statements just import things where and when you need them, supports every style of programming, QOL improvements like ranges and foreach, proper strings, optional garbage collector, has a long history of continuous im…

Me too.

> To me it's the clear choice if I'm going to rewrite an old C project since I can mostly just copy paste the old code and it runs

With the new ImportC feature you can literally copy-paste the code and reference your C types from D directly with a mixed compilation.

https://news.ycombinator.com/item?id=27872596

https://dlang.org/spec/importc.html

Quoting Walter from the thread linked above on it's purpose/reasons (which I think ought to go somewhere official tbh, since that brief discussion in the above thread is the best + most succinct overview of it currently AFAIK)

  The reasons for ImportC are:

  1. It's no longer necessary to translate .h files to D to interface with C. While doing the translations isn't hard, it is tedious, and if there are a lot of .h files it becomes a barrier.

  2. .h files get updated over time, and correspondingly updating the D files is error prone. It's much more effective to just compile the new .h files.

  3. It is not necessary to even create a .h file - just compile the .c file with ImportC and D will access it just like any other module. D will even inline the C functions in it.

  4. Use it as a standalone, small and fast, C compiler.

Re: Maintain It with Zig

#128

Post by heavyset_go »

mumblemumble wrote: post #68
heavyset_go wrote: post #60

Earlier quoted context omitted.

> It seems, from looking at others' code, that there is a very strong temptation to lean on `unsafe` instead of figuring out how to solve a problem within the constraints it normally applies. Are you sure those examples of unsafe Rust code were written using unsafe in order to work around safety constraints due to difficulty? I ask because there are some very real and valid use cases for unsafe code in Rust that have…

Not sure at all - I have effectively zero working knowledge of Rust - and certainly not looking to second-guess people's motivations for using the feature. The big bias I'm working from here is that, as an outsider, I have a hard time reconciling all the big talk about how Rust makes it impossible to experience certain classes of bugs, with the existence of a known set of things that its type checker can't check, and…

It might help to better understand the motivations behind unsafe Rust by reading some of The Rustonomicon[1].

[1] https://doc.rust-lang.org/nomicon/

Re: Maintain It with Zig

#129

Post by steveklabnik »

dleslie wrote: post #116
kristoff_it wrote: post #110

Earlier quoted context omitted.

> The author seems to be under the impression that Rust cannot live harmoniously within the C ABI ecosystem, which is false. The author is not under any such impression. The key point is that Zig can cross-compile C/C++ code, while Rust can't. If you have a Rust project that depends on C code, you will have to put in some work if you want to compile it for a different target. That's a pretty big difference in practic…

Zig itself doesn't cross compile C/C++ code, LLVM does the work for Zig. > If you have a Rust project that depends on C code, you will have to put in some work if you want to compile it for a different target. Rust is built on LLVM, and so its toolchain can also cross-compile C/C++ code. There are crates for that[0], and projects inspired by that idea[1]. > Give it some time, it will. Given enough time mountains beco…

You're splitting hairs in a weird way. rustc cannot compile C code. zig can. That they delegate to LLVM is immaterial.

"This crate calls out to the most relevant compiler for a platform, for example using cl on MSVC."

Re: Maintain It with Zig

#130

Post by dimitrios1 »

paavohtl wrote: post #58
mumblemumble wrote: post #50

Earlier quoted context omitted.

disclaimer: I haven't actually used either, just done a lot of interested reading and a little toying around. One thing that impressed me about Zig is how simple the language is. I get the impression that it would take very little time to properly learn the language and become effective at it. Rust, on the other hand, has a whole lot of complexity even without the ownership semantics. So much to learn and understand.…

In my experience unsafe tends to be used really sparingly by most users, if at all. And besides, unsafe doesn't really turn off static checks - it allows you to do a few extra things that can't be proven to be safe statically, in tightly scoped specially annotated regions. It's mostly about bending the rules temporarily, for 1-5 lines of code at a time.

Side note: Nothing is provable in rust because it does not have a formal, verifiable specification. We have a reference implementation that we believe does the things it says it does on one particular architecture. But trust, not proofs, is indeed required. >:) (don't downvote murder me, I love rust)
Post reply on HN