I lost interest when I tried it and it wouldn't compile code with tabs. (Don't know if it is still the case though)
Yes, but eventually, no https://github.com/ziglang/zig/wiki/FAQ#why-does-zig-force-m...
Assorted Thoughts on Zig and Rust
161–170 of 307 posts
Re: Assorted Thoughts on Zig and Rust
#162> As long as all unsafe code obeys the aliasing and lifetime rules, rust protects completely against UAF. Zig has little protection.
This is the most relevant part to me. As someone who will probably never write a line of either myself, the way I will work with languages like this is thorough libraries or extensions of higher-level languages like python or ruby. To that end, safety is the most important factor to me, with performance very much second. While rust has unsafe operations, these are relatively easy to audit if the code is open source. Ok, so to the programmer, Zig may be more ergonomic than C or Rust. But until Zig can offer the safety assurances of Rust, I'm still rooting for Rust to take over the world as the dominant and de-facto low-level language.
Re: Assorted Thoughts on Zig and Rust
#163Very interesting set of observations. As a C and C++ programmer, I am feeling more and more excited about Zig.
One thing that feels missing from Zig though is encapsulation. I don't believe that you can declare struct fields private, such that they can only be accessed by methods. This seems really important to me, not only as a technical means of enforcing invariants, or hiding internal-only implementation details that may change, but even just as a communication of intent. There is a big difference between "you are invited to read/write this directly" and "please don't read/write this."
C doesn't have this, true, but at least in C you can put internal-only structs in a .c file instead of .h, making the members effectively invisible to clients. Does Zig have anything comparable?
Re: Assorted Thoughts on Zig and Rust
#164Earlier quoted context omitted.
I actually think NPM is an amazing tool. When comparing to many other dependency management solutions, NPM: 1. has a nicer user experience 2. gives a lot of confidence that a project will be reproducible across environments, with only a package.json file Cargo is pretty close, but NPM is the gold standard for dependency management as far as I'm concerned.
I have some frontend developers in my team who think java is slow, but wait minutes waiting for NPM to finish its job. Our backend code builds 3x faster than our frontend code these days.
But is that because of npm, or is it because of their massive array of dependencies, plus webpack, bable, pollyfills and whatever 5 transpilers they have integraated into their project?
Re: Assorted Thoughts on Zig and Rust
#165Earlier quoted context omitted.
Very interesting, I don't know many mathematicians working in Coq. What is your field?
My work is related to homotopy type theory. There are mathematicians working in Agda and Lean (2, but also 3) as well, but it certainly is a niche field.
Ah, makes sense. By being able to express "abstract and correct thought" I mean being able to express myself in a system much like a mathematician would. Coq for example is too constructively oriented for my taste to make that possible (I know, you can "just add an axiom" ...), and its automation is also (therefore?) not good enough.
Re: Assorted Thoughts on Zig and Rust
#166Earlier quoted context omitted.
I actually think NPM is an amazing tool. When comparing to many other dependency management solutions, NPM: 1. has a nicer user experience 2. gives a lot of confidence that a project will be reproducible across environments, with only a package.json file Cargo is pretty close, but NPM is the gold standard for dependency management as far as I'm concerned.
Last time I used NPM, it tended to download megabytes of dependencies for each project . If you used a package in, say, 10 different projects, you had 10 copies of it. Did they solve that issue?
It's good for isolation: i.e. in general if you copy a directory containing an NPM project to another location, in general it will just work, and deleting something elsewhere on the file system should never affect the project. In general I would argue this is a more important property for dependency managers to have rather than using the least amount of space possible.
If you really want to avoid it you can install everything as a global dependency, but it's not best practice.
Re: Assorted Thoughts on Zig and Rust
#167I think Zig's biggest advantage is that it's just C without the warts, or footguns as is said in the Zig world. The comptime feature is probably the most exciting thing I've seen in a while. I've looked at Rust and feel it's more of a competitor to C++, Java and C#. Whereas Zig is C done right.
I've been enjoying D as "C done right". I find it a pleasure to use.
D competes more with GC languages like Go and Modula 3, rather than the C / C++ / Rust GCless niche.
Re: Assorted Thoughts on Zig and Rust
#168> Zig is dramatically simpler than rust... Most of this difference is not related to lifetimes.
I've been thinking about this recently: the borrow checker gets a lot of attention, but I think the majority of the learning curve of rust is actually due to "unforced errors" in the language UX which have nothing to do with the language's core USP's.
For instance, the module system just seems needlessly complex. Like you need a mod.rs file in each subdirectory, and the main.rs/lib.rs serves as the module file for the src directory, it took me like a day to figure out what exactly the rules are, and I can't understand why there can't be sensible defaults to define modules based on the file system structure alone.
Re: Assorted Thoughts on Zig and Rust
#169> Zig is dramatically simpler than rust... Most of this difference is not related to lifetimes. I've been thinking about this recently: the borrow checker gets a lot of attention, but I think the majority of the learning curve of rust is actually due to "unforced errors" in the language UX which have nothing to do with the language's core USP's. For instance, the module system just seems needlessly complex. Like you…
mod.rs isn't needed anymore; back in 2018 we fixed that: https://doc.rust-lang.org/edition-guide/rust-2018/module-sys...
> why there can't be sensible defaults to define modules based on the file system structure alone.
There could be, and in fact, I personally advocated for them. But there was significant community pushback; it turns out many people like to "comment out" entire modules when doing big refactorings. There are also some interesting edge cases, for example, you can use a #[path] attribute on a module to change what the path to the file is; without a mod statement, it's not clear where that would go.
Re: Assorted Thoughts on Zig and Rust
#170Earlier quoted context omitted.
Every language has overzealous fans, when a language is new this is likely a largely percentage of the community. If you use that as a reason to avoid a language you will likely just end up avoiding new languages.
See my other comment. It's more the fact Andrew stepped into the conversation himself and just said "be nice" instead of addressing security concerns, just fueling the flame war even more. A response to a security concern should never be "fuck off".
> A response to a security concern should never be "fuck off".
It can be when it is out of context and/or out of proportion.
But it could be more likely that temperamentally you are disposed towards different programing language where security concerns must override any and every issue at hand.