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

251–260 of 286 posts

Re: Maintain It with Zig

#251

Post by kaba0 »

dman wrote: post #63
steveklabnik wrote: post #55

Earlier quoted context omitted.

"simple" is, unfortunately, not a simple concept, nor does everyone agree on its effects on programs written in a language that is or is not simple. Some people do believe that, let's say "conceptually parsimonious" languages (using complicated words to describe simplicity is amusing to me, sorry) do exactly what you say. Others believe that complexity inherently exists, and you can put it in the language, where a co…

There is also the notion of languages you love writing code in vs languages you like reading code in. Languages with more powerful abstraction abilities bring joy to the writer but make things tedious for the reader.

Without powerful abstraction (of course used sparingly) you will just copy-paste the same logic in multiple places. Which is error prone and unmaintainable. And I would argue that even though a small part of it may be easier to read, you will have a harder time getting the big picture with low abstraction.

Re: Maintain It with Zig

#252

Post by matu3ba »

roca wrote: post #219
matu3ba wrote: post #189

Earlier quoted context omitted.

1. Rust doesnt let you safety-check bit-compressed stuff and instead relies on well-formed types during runtime (basically everything that union allows). 2. Graph memory patterns in Rust are completely unsafe. 3. Code might leak and you dont have tooling to check your dependencies. Trusting the test coverage does not help you there with Rust, because Rust tooling is infeasible for testing leaks. 4. CTFE is not easy t…

1. Unclear what you mean. You can manipulate bits of scalars without writing unsafe code. You can't do bit manipulation of pointers without writing unsafe code. You can write a small library that packs pointers with unsafe code, and then use it safely everywhere you need it. See https://github.com/rpjohnst/dejavu/blob/master/gml/src/vm/va... for example. 2. Wrap up the unsafety in a library like petgraph and use it.…

1. Union is used to dynamically interpret data of an underlying buffer or memory segment. You will find union as being inherently unsafe in Rust: https://doc.rust-lang.org/reference/items/unions.html

2. petgraph looks like they only allow allocating and freeing in the same order and no deallocating of segments (think of a graph pointing to another graph) dynamically. So even if you wrap it, you cant arbitrarily deallocate and allocate things upon semantic conditions.

3. It would be more helpful to use static analysis or making functionality with potential leaks similar to have this information on code review instead of trying to test all code paths.

4. True. I think that works then. Looks like between Rust and Zig "const equals comptime".

5. "Dynamic checks of all unsafe-code UB is infeasible." It is only infeasible, if you dont have an idea on the memory model during comptime. The RFC also writes "In particular, this would mean we need to decide on an aliasing model before permitting raw pointers in CTFE.", because Rust is not settled on that yet. On the upside, this speeds up compilation, lol.

Re: Maintain It with Zig

#253

Post by amedvednikov »

vlang1dot0 wrote: post #212
amedvednikov wrote: post #187

Earlier quoted context omitted.

Can you list any claims that fell apart? For example, one of the biggest claims has always been fast compilation. Here's V compiling itself in 0.3 seconds: https://www.youtube.com/watch?v=pvP6wmcl_Sc V was also self hosted (written in V) from the start, which says a lot about the maturity of the language. > Combined with all the delays There were no delays. The project was announced to be released in June, and it was…

> V was also self hosted (written in V) from the start, which says a lot about the maturity of the language. How could that possibly be true? You need a V compiler to compile V but none would have existed "from the start". You've also said multiple times on Discord that the original V compiler was written in Go.

By "from the start", I meant "from the first public release", sorry for the confusion.

Of course initial version was written in Go, but it was never released.

Re: Maintain It with Zig

#254

Post by amedvednikov »

super_flanker wrote: post #245
amedvednikov wrote: post #187

Earlier quoted context omitted.

Can you list any claims that fell apart? For example, one of the biggest claims has always been fast compilation. Here's V compiling itself in 0.3 seconds: https://www.youtube.com/watch?v=pvP6wmcl_Sc V was also self hosted (written in V) from the start, which says a lot about the maturity of the language. > Combined with all the delays There were no delays. The project was announced to be released in June, and it was…

> Can you list any claims that fell apart? On home page, the very first claim: > No null However V has `nil` or any reference can be initialized to `0`. How is then claiming `no null` not false?

There's no `nil` in the language, but indeed there's a hack that allows to assign 0 to references.

It's on the 0.3 roadmap, high priority.

Re: Maintain It with Zig

#255

Post by kaba0 »

gavinray wrote: post #146
10000truths wrote: post #106

Earlier quoted context omitted.

I would say that Zig has the same advantages for a lot of these points. Its interoperability with C at the source and object level is first-class, the syntax was very easy for me to pick up as someone familiar with C/C++, the features it adds on top of C (e.g. slices, compile time execution) are few but huge QoL improvements, its translate-c utility works amazingly well at transpiling C code to Zig, and its test bloc…

Out of curiosity, have you written apps in both languages? I have written small applications in both. To be transparent: my total dev hours in D are probably somewhere around ~100, and in Zig about ~30. So I am more familiar with D than Zig, though competent enough with both to have written a few small real-world programs. > Its interoperability with C at the source and object level is first-class D has direct intero…

Is syntactical similarity or even compatibility to C a positive thing? Not taking away anything, D is a really cool language that definitely doesn’t get the fame it would rightfully deserve, I just think that breaking with some old habits (eg. postfix types with : are simply superior from a parsing perspective, and the pointer magic of C is just as terrible and the change in Zig is very welcome) when they are superseded is a good thing.

Re: Maintain It with Zig

#256

Post by roca »

matu3ba wrote: post #252
roca wrote: post #219

Earlier quoted context omitted.

1. Unclear what you mean. You can manipulate bits of scalars without writing unsafe code. You can't do bit manipulation of pointers without writing unsafe code. You can write a small library that packs pointers with unsafe code, and then use it safely everywhere you need it. See https://github.com/rpjohnst/dejavu/blob/master/gml/src/vm/va... for example. 2. Wrap up the unsafety in a library like petgraph and use it.…

1. Union is used to dynamically interpret data of an underlying buffer or memory segment. You will find union as being inherently unsafe in Rust: https://doc.rust-lang.org/reference/items/unions.html 2. petgraph looks like they only allow allocating and freeing in the same order and no deallocating of segments (think of a graph pointing to another graph) dynamically. So even if you wrap it, you cant arbitrarily deall…

1. f32::from_bits/to_bits etc allow safe bit-casting between primitive types. Libraries like safe-transmute wrap up unsafe array pointer casts into safe APIs. Rust has great tools to address the use-cases where C would use unions.

2. The big picture here is that for graphs and other data structures, you figure out a safe API for the data structure and write a library that hides the unsafety behind that API (or just use a library that someone else already wrote). You get a clean separation between a small amount of unsafe code and a large amount of safe code. This is the Zen of Rust and it's why "Rust can't express safely" is almost never an important issue in practice.

3. Rust's ownership and determinstic destructors mean you really have to go out of your way to create a memory leak; "just forgot to free it" doesn't happen. A memory leak has to be something nontrivial like a global data structure that is added to but not removed from, or a reference-count cycle that isn't broken. There aren't really good automatic static techniques for detecting these AFAIK (and I have a background in static program analysis) --- you would need something that models heap states over time, like shape analysis, which doesn't scale. As far as I can tell Rust at least as strong as any other real-world non-GC language at preventing memory leaks, certainly stronger than Zig which lacks ownership and destructors.

5. This is an issue I don't know much about so I'll leave it.

FWIW the endgame for unsafe code in Rust is formal semantics for unsafe code, proof obligations that guarantee the unsafe code preserves Rust safety invariants, and proof-assistant tools that let you formally prove the safety of your "unsafe" code. There's a lot of work to get there but that work is well underway.

Re: Maintain It with Zig

#257

Post by vips7L »

sa1 wrote: post #216
vips7L wrote: post #192

Earlier quoted context omitted.

Automatic Reference Counting? I’m not sure. Swift spends a lot of its execution time doing reference counting.

Nim does it compile-time to insert destructors in the correct places. (except for cycle collection, which needs a runtime GC)

Are there benchmarks?

Re: Maintain It with Zig

#258

Post by dnautics »

pjmlp wrote: post #237
dnautics wrote: post #231

Earlier quoted context omitted.

Sanity. Seriously. You get these tests for free with zig, no extra tooling, if you use testing allocator in your tests. This also is a carrot to get you to write tests. Hell, I even mocked libc's malloc/calloc/free to make sure that my code doesn't leak memory: https://github.com/ityonemo/Primes/blob/ee81d05e80d68854ab11...

What sanity when the developer is still responsible for tracking memory manually by themselves? > It is the Zig programmer's responsibility to ensure that a pointer is not accessed when the memory pointed to is no longer available. https://ziglang.org/documentation/0.8.1/#Memory Mocking malloc you say? https://docs.microsoft.com/en-us/visualstudio/debugger/crt-d... It exists at very least since Visual C++ 5.0, and Bo…

Rust does not free you from having to track memory, for large classes of important data structures. And, if you want to implement smart pointers for your app in zig, it is easy.

Yes, your examples are two proprietary, nonstandard techniques. Or alternatively using a third-class toolset (jemalloc toolkit e.g ).

Sanity is having a single, anointed way to do it in the stdlib.

Re: Maintain It with Zig

#259

Post by dnautics »

skywal_l wrote: post #232
dnautics wrote: post #229

Earlier quoted context omitted.

I believe the creator is on record on some youtube video or something stating that the intent is to replace C.

The guy you are responding to IS the creator of the language.

yes, I'm aware, and he's aware of who I am too =D

Re: Maintain It with Zig

#260

Post by steveklabnik »

flohofwoe wrote: post #248
steveklabnik wrote: post #12

Agreed for sure that working with C and C++ is the only way forward for systems languages. Rust's expression of this is the zero-cost C FFI, using native platform tooling, and stuff like that. Rust was never about re-writing the world, after all, its reason for existing was to eventually improve Firefox. The very first presentation about Rust ( http://venge.net/graydon/talks/intro-talk-2.pdf ) says "We are not “rewri…

Since Rust is built on top of LLVM, what's preventing it from "just" adding the Clang C/C++/ObjC frontends into the Rust compiler, and create cargo packages with cross-platform C/C++/ObjC headers and runtimes? This would make cross-compilation and C/C++/ObjC integration just as easy as with Zig (and without requiring any external C toolchain, which is the most important point). I guess the other (simpler) alternative…

Technically? Nothing that I'm aware of. Practically? The desire to do it, and the engineering work required to make it happen.

I have been talking about how much I would love this to happen, but I can't do the work myself. Frankly, I don't contribute to the compiler, so even getting up to speed would be a ton of work I just don't have the time for.

Post reply on HN