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

Zig is hard but worth it

ratfactor.com

Post reply on HN
Print view View original

191–200 of 307 posts

Re: Zig is hard but worth it

#191

Post by nequo »

mr_00ff00 wrote: post #165
vilunov wrote: post #61

Earlier quoted context omitted.

Rust hasn't grown in scope very much since its release, but in places where it has grown, particularly async and unpin, I find that there features interact very badly with lifetimes and borrowing. I am often forced to ditch borrowing across async method calls and to put everything in Arcs, even when the lifetime is well-defined and it could be easily used if it had been scoped threads instead of futures. I fear that…

Technically though, isn’t memory safety not necessary in some cases? For example, single player video games. You can exploit your own machine if you want, but that’s not an issue. I like rust, but if I ran into async issues and annoying stuff, I could see a world where I grab a non-memory safe language to make games easily.

Crashing the program during runtime and having to debug it then is still a worse experience than knowing before running it that it cannot crash (due to memory errors).

This certainty comes at a cost, either by negotiating with the Rust compiler or by putting up with a GC. But depending on your calculus, that cost might be worth paying.

Re: Zig is hard but worth it

#192

Post by cyber_kinetist »

flohofwoe wrote: post #116
Taywee wrote: post #60

Earlier quoted context omitted.

You'd rather use explicit function calls for all linear algebra and geometry operations? I don't think adding two vectors using an overloaded + is that spooky or distant.

FWIW Zig can do that without operator overloading: https://www.godbolt.org/z/7zbxnncv6

First of all that only works with vectors, but I want operator overloading to also work on things like matrices or custom types (for example quaterions, or a symmat3 struct that represents a symmetric 3x3 matrix using only 6 floats).

Additionally, for efficient math code you often want vector / matrix types in AOSOA fasion: for example Vec3 to store an AVX lane for each X/Y/Z component. I want vector/matrix operations to work on SIMD lanes, not just for scalar types, and Zig currently can't support math operators on these kinds of types.

Re: Zig is hard but worth it

#193

Post by estebank »

MH15 wrote: post #164
thechao wrote: post #134

Earlier quoted context omitted.

Maybe an operator-overloading region ? #{ m3 = m1 * m2 + m3; m3 += m4; } Basically, pure syntactic sugar to help the author express intent without having to add a bunch of line-chatter. Speaking of operator-overloading, I really wish C++ (anyone!) had a `.` prefix for operator-overloading which basically says "this is more arguments for the highest-precedence operator in the current expression: a := b * c .+ d; Which…

Huh I've never seen this approach. Very interesting solution, could be adapted to the JavaScript matrix libraries I bet.

In Rust you could use a proc macro that parsed the block and translates the token to a new token stream that uses method calls with the appropriate operator precedence, for arbitrary operations you could want to define. You're effectively writing a compiler plugin and language extension at that point. For targeted niche domains, this might be worthwhile.

Re: Zig is hard but worth it

#194

Post by mike_hearn »

frankjr wrote: post #23

I've been playing with it and so far but I'm more impressed with their build system rather than the language itself (it seems to be way more flexible and simpler than alternatives which is pretty rare). They did however get the module system right. You can just organize the file structure in any way you like. I hate Rust's "everything is a single module" system with passion.

How do you find it simpler? From taking a quick look it appears to just be an API for invoking build steps, and the build script is itself a Zig program.

I ask if it's really simple, because the JVM space went in the same direction with Gradle (build script = program) and by the time it gets more sophisticated that can turn out to be pretty painful. In particular, IDEs struggle to get the information they need, scripts can become highly complex, and there are various other problems.

Re: Zig is hard but worth it

#195

Post by krupan »

rayiner wrote: post #37

Alternative languages are cool, but I struggle to see the point of a systems programming language that doesn't offer static memory safety in 2023. Rust isn't necessarily the best and final answer--it seems like there is a broad design space to explore for memory-safe systems programming languages. But Zig seems to occupy the same local maximum as C--a relatively simple, non-safe systems language--and doesn't have a k…

Honest question here (that I have every time I see someone talk about memory safety in 2023), are you aware of Ada/Spark?

Re: Zig is hard but worth it

#196

Post by mr_00ff00 »

sarchertech wrote: post #190
mr_00ff00 wrote: post #167

Earlier quoted context omitted.

Just looked at Odin and I really like the syntax, but I feel the same way. I feel like the community and ecosystem is the key elements and zig seems to be headed in the direction to grab that.

They’re very different languages despite having some similar capabilities. I also found the game dev libraries in Odin far easier to use then the ones in zig.

Yeah I did briefly look for zig game libraries and couldn’t find much.

I see the basic differences, but I’ll have to dig deeper.

Re: Zig is hard but worth it

#197

Post by jeroenhd »

johnnyjeans wrote: post #115
zoogeny wrote: post #55

Earlier quoted context omitted.

I've lately thought that a package manager is as essential to a new language as a standard library. I would also add a LSP and standard code formatter to that list. It is a bit unfortunate because all of the above is a pretty tall order. We're getting to the point that new languages are expected to boil the ocean by the time they reach 1.0

I disagree. I actively avoid languages that rely on package managers simply because they only give the illusion of being beneficial. It ends up being more boilerplate I have to learn to use an ecosystem, because they don't actually solve dependency hell and now there's a whole additional complicated tool with its own DSL I have to contend with in order to fix what's broken (or even diagnose issues.) The more peripher…

The problem with source tarballs is that you need to then manually watch out for updates and bugfixes for every dependency you pull in. You also need to deal with the bespoke build system of your packages of choice or manually build something compatible with your project. You can also choose not to and skip vulnerable, buggy code for a few years like some companies do, but that's hardly an advantage. You also need to ship (and possibly license) all of your dependencies.

Alternatively, you can let the system package manager do all the hard work for you. That works great, as long as you only target one OS or put in the work to maintain compatibility with multiple OS releases.

My experience with languages without package managers is that large, maintained projects all invent their own package manager (remote git repos? shell scripts downloading files? a two-stage build process written in the language itself?) in combination with some sort of Makefile generating hell script that breaks for a while when a new OS release comes out.

This approach works if you're the entire system. SerenityOS can do this, because it's basically an entire operating system and userland all inside one repository. ChromeOS can probably do it as well, since the app portion isn't running OS-native code anyway. For everyone else, it's just making someone else do the work of the package manager manually.

Re: Zig is hard but worth it

#199

Post by latchkey »

zoogeny wrote: post #55
latch wrote: post #22

I've now written a lot of zig code (http.zig, websocket.zig, log.zig, zuckdb.zig, etc.) I think Zig falls into an "easy to learn, average/hard to master" category. Some insiders underestimate the effort required for newcomers to build non-trivial things. I think this is because some of that complexity has to do with things like poor documentation, inconsistent stdlib, incompatible releases, slow release cycle, lack o…

I've lately thought that a package manager is as essential to a new language as a standard library. I would also add a LSP and standard code formatter to that list. It is a bit unfortunate because all of the above is a pretty tall order. We're getting to the point that new languages are expected to boil the ocean by the time they reach 1.0

> I've lately thought that a package manager is as essential to a new language as a standard library.

This was the approach Ceylon took. Sadly, despite a lot of effort, the language never took off.

Re: Zig is hard but worth it

#200

Post by rowls66 »

eatonphil wrote: post #49
rowls66 wrote: post #45

Earlier quoted context omitted.

I am truly puzzled by this. I understood Zig to be a very low level language like 'C'. Why would you write scripts in it?

It's significantly nicer to write than C (my opinion obviously). I see it as a general purpose language. But mostly the team decided to do this because we wanted to unify on one language and double down on the investment in Zig. I'm not a fanboy (nothing wrong if anyone is, just clarifying about myself); I think this choice was right.

I guess I don't see C as programming language for writing scripts in either. In my view any language that requires a separate complication step is not a scripting language, and therefore not a language in which one writes scripts. In C or Zig you write programs.

Maybe I am just being too pedantic.

Post reply on HN