Live data from Hacker News

Zig, the Small Language

zserge.com

201–210 of 429 posts

Re: Zig, the Small Language

#201

I tried Zig recently but I found the unsilenceable lints to be a huge productivity killer. I actually posted a link to the GitHub issue this morning. https://news.ycombinator.com/item?id=32751317 This makes a normal workflow with `watchexec zig test` basically impossible, since before I can even run the tests I have to spend time hunting down which variables are used/unused at the moment and (un)commenting them. And…

There's a push-and-pull on this in D, too. For example, sometimes I want a backtrace at a certain point, so I'll add an `assert(0);` there. The compiler complains that the rest of the code is unreachable. I then have to block out the code with a `static if (0) { ... }`, or comment it out, which is annoying. But most everyone else likes this, so it stays in. There are no real right answers here. Adding a switch for it…

Doesn't D have a debugger? Hitting F9 then F5 sounds a lot faster than fiddling around with the code, hoping that you forget to remove the assert before you go home and that you won't spend time pleasing the compiler.

Re: Zig, the Small Language

#202

Earlier quoted context omitted.

I think there's three reasons one might use Zig instead of Rust. These are just opinions, and I would love yall's thoughts. First: there's only a certain amount of effort that one is willing to put into accomplishing one's goals, effort that will be spent on learning tools and building a project. It's not unlimited. If I just want to make a game where a character walks around the world, and I only have 20 or so hours…

One should keep in mind that Rust also has an unsafe subset. While it does not get rid of the borrow checker (quite intentionally) and it also introduces some pitfalls wrt. interacting with safe Rust, compared to C, Zig, Hare, Jai etc. it is in principle quite possible that future versions of unsafe Rust might become just as ergonomic as these competing languages.

(Tiny note, unsafe is a superset, not a subset.)

Re: Zig, the Small Language

#203
post #191

Earlier quoted context omitted.

I must confess I had to suppress my knee jerk urge to downvote. It almost feels like you're asking "what's the appeal of elegance?" "What's the appeal of Chess, if you want complex gameplay just have complex rules." It almost feels alien that someone couldn't get it. Here's a simple but perhaps disappointing theory. Painting with a broad brush for a moment, there are primarily two sorts of thinkers: memorizers and lo…

> Small coding languages let you know everything while learning as little as possible. Very well put

But its just more library code to learn instead, isn't it?

Re: Zig, the Small Language

#204

I tried Zig recently but I found the unsilenceable lints to be a huge productivity killer. I actually posted a link to the GitHub issue this morning. https://news.ycombinator.com/item?id=32751317 This makes a normal workflow with `watchexec zig test` basically impossible, since before I can even run the tests I have to spend time hunting down which variables are used/unused at the moment and (un)commenting them. And…

had the same problem, if you're just prototyping, it's easy to silence that with _ = someVar

you get used to it after some time - much better than for example rust, where you have to figure out all the lifetimes, muts and generic traits before.

Re: Zig, the Small Language

#205

Earlier quoted context omitted.

> And you know what's the reasoning behind this? "Zig doesn't have warnings." As if it's a massive undertaking to add warnings to a compiler. What a sorry excuse. Setting aside the unused variables issue for a moment, you might want to take a moment to ponder the fact that not having warning messages is an explicit design choice, not a missing feature.

A dogmatic one, by the sounds of it.

Maybe this becomes the equivalent of `go fmt` in 10 years. “How I learned to stop worrying and love errors-only”

Re: Zig, the Small Language

#206
post #144

Earlier quoted context omitted.

It does seem confusing to me why someone would choose Zig. If you’re looking for a low-level language, Rust is safer with a better ecosystem. If you want a high-level language, Nim binaries are smaller and the Go ecosystem is better. When is Zig the best choice?

The fanaticism of Rust devs makes me think it's probably massively overrated (see Node yesterday and Ruby/Rails the day before) and Go is associated with Google which gets a perhaps unfair but still unignorable knee-jerk reaction from me to avoid it. I don't know enough about Nim to pass judgment. Two reasons I decided to give Zig a try: The official chat channel is on IRC, instead of Discord or Slack (so the people…

I'm not at all trying to change your mind (I've never used Zig so I can't comment there), but just FYI:

1. Rust uses Zulip (ie, not Discord or Slack),

2. Rust doesn't lack for promising-looking, declarative/reactive UI frameworks: https://iced.rs/, https://crates.io/crates/egui, for example.

Re: Zig, the Small Language

#207

Earlier quoted context omitted.

https://play.rust-lang.org/?version=stable&mode=debug&editio... You can put it at the top of your file with a #! too, if you want it to apply to the whole file.

Oops I didn't explain clearly. Take this code: pub fn abc() -> usize { #[allow(deprecated)] "abc".len() } I want it to complain about the "allow", because there was never any deprecated warning emitted in the first place. Maybe it would be called #[expect(deprecated)] I refactor code all the time and find these stray "allow"s that aren't doing anything anymore

> Maybe it would be called #[expect(deprecated)]

Both this and the reply saying you should open an RFC worry me that it was tongue-in-cheek.

Or maybe it's the obvious name choice, heh, because it literally exists with that very syntax: https://play.rust-lang.org/?version=nightly&mode=debug&editi...

Not stable yet, as you can see, but all the RFC and implementation work has been done, and a stabilization report was even put forward back in July: https://github.com/rust-lang/rust/issues/54503#issuecomment-...

Re: Zig, the Small Language

#208

Earlier quoted context omitted.

> if we can do 1 + 1, we should be able to do vec2 + vec2, same with mat4 * mat4 why? operator overloading doesn't help you solve any problems. you can have the readability with methods which are named appropriately. operator overloading seems so powerful and useful until you realize one day that it only changes the appearance of things, and makes no difference whatsoever to anything you are actually doing.

i'm not asking for operator _overloading_, i am asking for having operators for my math types

Good point, you could have + * / restricted to basic types, but have #* #+ #mod_add as (overloadable) operators.

Re: Zig, the Small Language

#209

Why would anyone use a new systems programming language that is not safe? Zig might be better than C in some aspects, but is it worth it to switch to Zig when you realize that it's not much safer than C? [0] [0]: https://www.scattered-thoughts.net/writing/how-safe-is-zig/

I clicked the link and I see within the table mentions of "heap" and "free", but I regularly target systems with no runtime. Does Rust offer many advantages over Zig in this space? I mostly program in C, but I've been eyeballing both for some time now.

I think Zig would be much easier to write code for compared to Rust in this use case. Rust is not some magical tool that stops all bugs as some people like to think it is. The lower you go, the more you will have to contort yourself, and the more likely it is for less experienced programmers to make mistake. I think Zig is much more approachable and fixes a lot of C foot guns and guides you into writing safer, faster code.

If you are writing web apps then Rust is probably "safer". If you are writing low level code that requires obtuse memory management then I don't think you can make a blanket claim that Rust is just "safer". A lot of this nuance is not often discussed.

Re: Zig, the Small Language

#210
post #99

Earlier quoted context omitted.

> Python/Go I wouldn't put those two languages in the same class. Go has about the performance of Java/C# with about the memory usage of C++. It's much closer in performance and resource efficiency to those languages than it is from a scripting language like Python.

They both emphasize productivity over other factors like performance and correctness, so I think they're very much in the same boat in terms of use cases.

Go was created for correctness. It is strongly, statically typed, it won't compile if there are unused imports or variables, and it won't compile either if you don't free up resources after usage. C/C++ don't do that and have UBs.

Go is in the same ballpark than C#: a modernized C with GC, good productivity although not as good as a scripting language, and good performance although not as good as ANSI C. They're popular because they stand in that sweet spot.

Python is easier than Go or C# to pick up, but it's also 20x slower than C rather than 2-3x.

Post reply on HN