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

161–170 of 307 posts

Re: Zig is hard but worth it

#161

Post by kps »

parasense wrote: post #145

The main take away is: > Something that makes Zig harder to learn up front, but easier in the long run is lack of undefined behavior. Reminds me of the old discussions of Fortran Vs C, and specifically in the early times before C had a standard library. What we call "undefined behaviour" was just an idiom of the language where the "behaviour" was sometimes on purpose, but recognised might not be portable. And so the…

C89's ‘undefined behavior’ was a failed attempt to say “you get what the hardware gives you”.

Re: Zig is hard but worth it

#162

Post by erichocean »

markisus wrote: post #139
pron wrote: post #38

Earlier quoted context omitted.

As someone who works on another language that is relatively reluctant to add language features (Java) we regularly face such dilemmas. A user shows up with a problem that could be helped by the language. The problem is real and a language feature would work, but there are many such problems, and adding features to solve all of them will make the language much bigger, overall causing greater harm (even those who don't…

In robotics, numerical linear algebra expressions comprise a large part of the code base. If not by line count, then definitely by the amount of time spent writing, reading, and debugging such code. This makes Zig unusable for these applications, at least not without additional tooling. You can get a feel for how unergonomic this is by avoiding the use of all arithmetic operators in your code and instead forcing your…

> You can get a feel for how unergonomic this is by avoiding the use of all arithmetic operators in your code and instead forcing yourself to use user defined plus(a,b), minus(a,b), assign(a,b), etc, or programming directly with the C blas api.

You've dramatically overstated your case, since that's true of every Lisp-like language.

Lisp is a perfectly suitable language for developing mathematics in, see SICM [0] for details.

If you want to see SICM in action, the Emmy Computer Algebra System [1] [2] [3] [4] is a Clojure project that ported SICM to both Clojure and Clerk notebooks (like Jupyter notebooks, but better for programmers).

[0] https://mitpress.mit.edu/9780262028967/structure-and-interpr...

[1] Emmy project: https://emmy.mentat.org/

[2] Emmy source code: https://github.com/mentat-collective/emmy

[3] Emmy implementation talk (2017): "Physics in Clojure" https://www.youtube.com/watch?v=7PoajCqNKpg

[4] Emmy notebooks talk (2023): "Emmy: Moldable Physics and Lispy Microworlds": https://www.youtube.com/watch?v=B9kqD8vBuwU

Re: Zig is hard but worth it

#163

Post by pron »

whateveracct wrote: post #140
pron wrote: post #137

Earlier quoted context omitted.

> Can you give me an example of a Haskell expression which isn't reverentially transparent (without unsafePerformIO)? Yes: https://github.com/ncaq/debug-trace-var The trick, however, is not unsafePerformIO (destructive mutability has nothing to do with referential transparency in general, although it breaks it in Haskell specifically) but with TemplateHaskell, as quoting has everything to do with referential transpar…

hm okay so basically anything that doesn't use TH or unsafePerformIO is gonna be referentially transparent. And TH is even deferentially transparent at TH-time. It only "breaks it" when evaluating the whole program. But each "stage" maintains the property. I'm assuming any pure language with macros is also r.t. at each stage and only pedantically breaks r.t. when combined. But I don't think that especially hurts the…

> You don't have to go into such niches in Java to lose that property.

It's not so easy. You'd have to examine debugging information in stack traces and use reflection. You can't write such a "trace" operator in Java or in Zig. Of course, without macros, C is almost perfectly referentially transparent and Haskell is, too (except for unsafePerformIO).

Re: Zig is hard but worth it

#164

Post by MH15 »

thechao wrote: post #134
TwentyPosts wrote: post #15

Earlier quoted context omitted.

I am not much of a Zig-head, but the best compromise I can think of is having a few operators which purely and solely exist for this purpose. In other words, there is no operator overloading, but you can define, say, "#+" for any two structs, or something like that. So if you want to encode matrix multiplication, then you'll always have to write `mat1 #* mat2`. This feels like a hack, and isn't all that elegant, but…

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.

Re: Zig is hard but worth it

#165

Post by mr_00ff00 »

vilunov wrote: post #61
distcs wrote: post #44

Earlier quoted context omitted.

> If any kind of automatic memory isn't possible/allowed, I would be reaching out for Rust I have come to the same conclusion but then I also fear that Rust will continue to expand in scope and become a monster language like C++. Do you or anyone fear that? Is that a possibility?

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.

Re: Zig is hard but worth it

#166

Post by JohnFen »

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…

I agree entirely. Relying on a package manager in order for a language to be useful indicates to me that there's a deficiency in the language.

Re: Zig is hard but worth it

#167

Post by mr_00ff00 »

truckerbill wrote: post #95
59nadir wrote: post #79

Earlier quoted context omitted.

I've settled on Odin as well and I think it's currently way ahead for game development than Zig is. Even for other things I'm currently more likely to write it in Odin, despite writing Zig from 2019 to 2022. The reasons really come down to error handling being better in Odin overall with payloads being attachable to errors as well as the context system and zero values making it relatively painless to really only talk…

I want to invest in Odin but I see the velocity and growing mindshare that Zig has and I wonder if it's not better to settle for that. Also how do you find the compile times?

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.

Re: Zig is hard but worth it

#168

Post by auggierose »

pron wrote: post #104
auggierose wrote: post #80

Earlier quoted context omitted.

Referentially transparent means that you can replace an expression with its value without changing the meaning of the program. If everything you can do must be referentially transparent, then that's purely functional programming, because applying functions without side-effects is pretty much the only thing you can do then. Of course, there are some other techniques like rewriting, which strictly speaking are differen…

> Referentially transparent means that you can replace an expression with its value without changing the meaning of the program. Not quite. A referentially transparent expression (E) is one where you can replace any of its subexpressions (A) with another (B) that has the same meaning (not value!!!!) as (A) without changing the meaning (not value!!!) of E. However, in purely functional languages, the meaning of any ex…

Do you have a pointer to a paper where "referentially transparent" is defined in your sense? I grant you that values of a programming language should be distinguished from the meaning of an expression, which will be a value of some sort in the logic. In that sense, any language with a denotational semantics will be referentially transparent. So maybe what you are really saying is: macros usually don't have a denotational semantics. Not sure that it is helpful to call this referential transparency, because it differs from the meaning most people associate with it.

Re: Zig is hard but worth it

#169

Post by hellcow »

pacaro wrote: post #92
ok123456 wrote: post #87

One annoying thing I ran into when trying zig is they don't distribute debs any more for Debian distributions. They just tell you to use a snap. I don't have snap, and don't want it. Compiling it requires the latest llvm toolchian (16), which is only realistically going to be available as a package if you're on a bleeding edge distribution.

I understand this, but haven't found this to be an issue personally. I just download the pre built tarball, expand it, make sure that /opt/zig-latest symlinks to the right folder, and setup path That's more work than apt-get install for sure, but not so much more

You can also use something like zigup to make fetching the latest master/managing multiple versions easier.

Re: Zig is hard but worth it

#170

Post by kubanczyk »

distcs wrote: post #36
helen___keller wrote: post #9

My main issue with Zig is that I’m scared to invest time in writing something nontrivial to see the community/adoption flounder then regret not using Rust or C++ later The language itself is fun. The explicit-ness of choosing how allocation is done feels novel, and comptime is a clean solution for problems that are ugly in most languages. Aside from lack of community I’d say the biggest nuisance is error handling in…

> If I use the general purpose allocator then my edge case is PC out of memory What does PC mean in this context?

player character
Post reply on HN