Live data from Hacker News

Zig 0.11

ziglang.org

101–110 of 193 posts

Re: Zig 0.11

#101
post #80
post #24

Earlier quoted context omitted.

“Linked lists are hard” is not “none of the common knowledge around traditional data-structures and algorithms work”.

I retort that almost all of the concurrent data structures are obnoxious to represent in Rust. A lock-free ConcurrentHashMap, for example, is by no means a straightforward data structure in a non-GC language. Even if you somehow dodge Rust's pedantry, you still have to figure out who owns what, who pays for what and when they pay for it--and there are multiple valid choices! Non-GC allocation/deallocation in concurre…

You should always know who owns some data, even if you aren't using Rust!

Re: Zig 0.11

#102
post #93

Earlier quoted context omitted.

[flagged]

Where did he/she even mention Rust?

Well, you do not see people mentioning Ada/SPARK whenever memory safety is the topic of discussion, do you? They mention Rust! Well, I do mention Ada/SPARK as much as I can because it is still a much safer language in general than Rust.

Re: Zig 0.11

#103

Zig is not memory safe and therefore at risk, just like C/C++, of future government legislation that outlaws the use of memory unsafe languages for some or all projects. The risk of such legislation is not insignificant: https://www.itpro.com/development/programming-languages/3694... Personally I do not see the point of building an entirely new language and ecosystem that does not fully address this issue.

seriously? "The National Security Agency (NSA) has recommended only using 'memory safe' languages, like C#, Go, Java, Ruby, Rust, and Swift, in order to avoid exploitable memory-based vulnerabilities."

log4shell enters the chat.

https://en.wikipedia.org/wiki/Log4Shell

Re: Zig 0.11

#105
post #51

Earlier quoted context omitted.

> Rust's const-eval is very constrained and has been WIP for ages Having strong backwards compatibility does that to the language, alternative is arguably worse (see Python 2 vs 3).

Yes, and I don't want a backward-incompatible Rust 2.0 either, but the slowness of stabilizing ! (named for when it's going to be stabilized), specialization, TAIT, const-eval, Vec::drain_filter, *Map::raw_entry, ... is annoying. Also the lack of TAIT currently causes actual inefficiency when it comes to async traits, because currently async trait methods have to return allocated virtualized futures instead of concre…

If you think, that's bad, look at C/C++ standardization bodies, where stuff is eternally blocked because ABI compatibility.

---

Problem is lots of implementation things are vying for inclusion. And many thing people want aren't safe or block/are blocked by possible future changes.

For example default/named arguments were blocked by ambiguity in parsing when it comes to type ascription iirc. And not having default arguments makes adding allocator quite more cumbersome.

Plus Rust maintainers are seeing some common patterns and are trying to abstract over them - like keyword generics/ effect system. If they don't hit right abstraction now, things will be much more harder later. If they over abstract, its extremly hard to remove it.

---

Slowness of stabilizing never type (!) and specializations has to do with the issues they cause mainly unsoundness and orphan rules issues, iirc I haven't checked them in a while.

But otherwise yeah, Unstable book keeps growing and growing: https://doc.rust-lang.org/unstable-book/index.html

Re: Zig 0.11

#106

Earlier quoted context omitted.

Memory safety is one aspect of quality yes, but is there any evidence Zig is a good fit for other quality aspects, e.g. static analysis tooling and correctness proofs? ATS is a low-level language that allows embedded proofs of correctness in the type system.

That article does not even mention Ada/SPARK... So much for safety. :P Yup, there is static analysis with Ada/SPARK and it is great. It is much more general-purpose than ATS, and there are other things in Ada/SPARK that increases safety in general, not only memory safety. For what it is worth, Ada/SPARK has a strong presence in safety-critical domains like aerospace and medical devices, while Rust is gaining populari…

Yes Ada/SPARK is a great example.

Re: Zig 0.11

#107
post #95

Earlier quoted context omitted.

1. It's typically at least as fast as C, unlike C++/Rust 2. You can do type introspection (and switching) during compile-time, and it's not just some stupid TokenStream transformer, you really have type information available, you can do if/else on the presence of methods, etc. 3. There are no generics, but your functions can accept anytype, which is still type-safe. See https://github.com/ziglang/zig/blob/9c05810be60…

> 1. It's typically at least as fast as C, unlike C++/Rust The typical urban myth that never comes with profiler proofs.

I don't need to prove you anything. Go and give it a try yourself.

Re: Zig 0.11

#108

Earlier quoted context omitted.

>My understanding is that Zig has all of the power and modernity of Rust, without the strictness and borrow checker. This is an oxymoron :) The strictness and borrow checker are part of the power and modernity of Rust. But even apart from that, Rust has automatic value-based destructors (destructor follows the value as it's moved across scopes and is only called in the final scope), whereas Zig only has scope-based d…

> Rust has properly composable Option/Result monads, whereas Zig has special-cased ! and ? which don't compose (no Option of Option or Result of Result) ?!!??u32 is a perfectly cromulent type in Zig.

How do you express the difference between None and Some(None) in Zig?

Re: Zig 0.11

#109
> If the Operating System is proprietary then the target is not marked deprecated by the vendor. The icon means the OS is officially deprecated, such as macos/x86.

Not supporting proprietary OSes is a bummer. Especially if it is marked as deprecated since it is unlikely to change. People choosing Zig to anything choose their users to throw away their devices.

.. the number of hardware and software just keeps growing and growing endlessly, and the number of their combinations grows even faster. We probably need some more virtual machines as targets to cover them all.

Re: Zig 0.11

#110
post #95

Earlier quoted context omitted.

> 1. It's typically at least as fast as C, unlike C++/Rust The typical urban myth that never comes with profiler proofs.

I don't need to prove you anything. Go and give it a try yourself.

https://programming-language-benchmarks.vercel.app/c-vs-cpp

https://programming-language-benchmarks.vercel.app/c-vs-rust

I understand that anytime someone brings benchmarks out, the next response points out that benchmarks are not real world use cases. Nonetheless, they are data points, and your claims are against the commonly accepted view of C being roughly as fast as C++ and Rust. If you have absolutely no data to back it up, you shouldn't expect anyone to believe you.

Post reply on HN