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

231–240 of 307 posts

Re: Zig is hard but worth it

#231

Post by pdntspa »

pornel wrote: post #203
JohnFen wrote: post #166

Earlier quoted context omitted.

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.

Is every language supposed to come with HTTP and TLS stack, clients for every database, de/serializers for every format, every image and video codec, every de/compressor, GUI toolkits, 3D rendering, Bluetooth… where do you stop? And then how do you maintain all of this bloat to a competitive level, so that users don't need to reach for faster/newer alternative packages anyway? And how do you maintain portability and…

You could manage it like .net did before chocolatey/winget -- pretty much a free-for-all, just add yourself to the COM list through whatever means you want and have at it

But that was a mess. I still have nightmares from dealing with windows assembly cache issues.

Honestly it reminds me of some of the shit I've had to deal with with pip (what do you mean you can't resolve this dependency???)

Re: Zig is hard but worth it

#232

Post by lost_tourist »

TUSF wrote: post #230
lost_tourist wrote: post #228

Earlier quoted context omitted.

Why would I use zig c compiler in place of gcc or clang? Mainly for zig interactivity or does it have some advantage other than that over the aforementioned compilers?

Zig's C/C++ compiler is just clang, but with header files for most major platforms included, and sane defaults, so there's no hassle getting it it to cross-compile. Some companies have been using Zig solely for an easier to use clang.

Ah I see, thanks for your answer!

Re: Zig is hard but worth it

#233

Post by tialaramex »

kps wrote: post #161
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”.

This makes no sense because C89 is defined for execution on a abstract machine, something which doesn't exist and thus has no hardware.

Such beliefs are however compatible with the inveterate C programmer excuse that their nonsense programs should be correct if only the standards committee, compiler vendors, OS designers, and everybody else in the known universe were not conspiring to defeat their clear intent.

Re: Zig is hard but worth it

#234

Post by bakkoting »

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.

There's a not-very-active proposal to add operator overloading to JS which takes a similar scoped approach:

https://github.com/tc39/proposal-operator-overloading

Re: Zig is hard but worth it

#235

Post by kps »

tialaramex wrote: post #233
kps wrote: post #161

Earlier quoted context omitted.

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

This makes no sense because C89 is defined for execution on a abstract machine, something which doesn't exist and thus has no hardware. Such beliefs are however compatible with the inveterate C programmer excuse that their nonsense programs should be correct if only the standards committee, compiler vendors, OS designers, and everybody else in the known universe were not conspiring to defeat their clear intent.

From the C89 Rationale, “The potential for efficient code generation is one of the most important strengths of C. To help ensure that no code explosion occurs for what appears to be a very simple operation, many operations are defined to be how the target machine’s hardware does it rather than by a general abstract rule. An example of this willingness to live with what the machine does can be seen in the rules that govern the widening of char objects for use in expressions: whether the values of char objects widen to signed or unsigned quantities typically depends on which byte operation is more efficient on the target machine.”

Re: Zig is hard but worth it

#236

Post by KerrAvon »

erichocean wrote: post #162
markisus wrote: post #139

Earlier quoted context omitted.

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…

Why do you think this is true of Lisps? Emmy would not seem to be a good example because it actually does overload arithmetic operators to support extended data structures. Look at, for example:

https://cljdoc.org/d/org.mentat/emmy/0.30.0/doc/data-types/m...

Re: Zig is hard but worth it

#237

Post by KerrAvon »

hellcow wrote: post #155
markisus wrote: post #139

Earlier quoted context omitted.

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…

Using plus(a,b) for complex types sounds fine to me… I have to imagine if I were working with a huge file of these for a while it would start to feel normal, just like every language has a different syntax but you eventually feel comfortable using.

Are you sure you would find this more ergonomically pleasing:

assign(x, plus(a, plus(b, plus(c, b))))

When you could have:

x = a + b + c + d;

Or:

(let x (+ a b c d))

?

Re: Zig is hard but worth it

#238

Post by erichocean »

KerrAvon wrote: post #236
erichocean wrote: post #162

Earlier quoted context omitted.

> 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…

Why do you think this is true of Lisps? Emmy would not seem to be a good example because it actually does overload arithmetic operators to support extended data structures. Look at, for example: https://cljdoc.org/d/org.mentat/emmy/0.30.0/doc/data-types/m...

> forcing yourself to use user defined plus(a,b), minus(a,b), assign(a,b)

This is the complaint I was responding to. Here is that code in Clojure (a Lisp):

    // What the GP claims is bad for doing math:
    plus(a,b)
    minus(a,b)
    assign(a,b) //
Lisp doesn't have "operators", so it doesn't have "operator overloading." What it does have is multi-dispatch, so yeah, the implementation of `+` can depend on the (dynamic) types of both `a` and `b`. That's a good thing, it means that the `+` and `-` tokens aren't hard-coded to whatever the language designer decided they should be in year 0, with whatever precedence and evaluation rules they picked at the time.

The point I'm making is that you absolutely DO NOT need to have special-cased, infix math operators to "do math" in a reasonable, readable way. SICP is proof, and Emmy is a breeze to work with. And it turns out, there are a lot of advantages in NOT hard-coding your infix operators and precedence rules into the syntax of the language.

Re: Zig is hard but worth it

#239

Post by WhereIsTheTruth »

jadodev wrote: post #227
WhereIsTheTruth wrote: post #226

The issues I have with Zig are similar to the ones I have with Rust, the syntax.. I will never get used to it, I find it tasteless and non-ergonomic But, I manage to set it aside because it provides enough benefits, I mainly use Zig as a toolchain to crosscompile my libraries.. and write some helper externs Hopefully they manage to improve and ease out the syntax by 1.0, I have hopes

Have any examples of syntax you find tasteless? Things in Zig that feel ergonomic to me: comptime params > separate generic args; ptr.* > *ptr; optional pointers > possibly null normal pointers; separate syntax for slices, arrays, & pointers > 1 syntax for ptr & arrays.

  var t: ?i32 = null;

  if (t) {

      t +=1;

  }
This for example doesn't work, you have to capture, many little things like that that stacks up and ends up creating a non-ergonomic syntax

No for loop, so you have to do multilines things like, and now you meet a new : construct, this pseudo for loop now looks confusing to look at

  var i: i32 = 0;

  while (i
Then constant casting between integers, and also floats.. also no operator overload for the math types etc..

Also not a fan of the pointer difference between [] * [:0], too much different nitpicking that makes iterating slow and painful, I understand the benefits, but the way it's done is not enjoyable, at least to me

That's just whats on the top of my head, it's been a while I haven't wrote Zig code so I may be remembering wrong

Re: Zig is hard but worth it

#240

Post by tialaramex »

kps wrote: post #235
tialaramex wrote: post #233

Earlier quoted context omitted.

This makes no sense because C89 is defined for execution on a abstract machine, something which doesn't exist and thus has no hardware. Such beliefs are however compatible with the inveterate C programmer excuse that their nonsense programs should be correct if only the standards committee, compiler vendors, OS designers, and everybody else in the known universe were not conspiring to defeat their clear intent.

From the C89 Rationale, “The potential for efficient code generation is one of the most important strengths of C. To help ensure that no code explosion occurs for what appears to be a very simple operation, many operations are defined to be how the target machine’s hardware does it rather than by a general abstract rule. An example of this willingness to live with what the machine does can be seen in the rules that g…

> many operations are defined

My emphasis. Undefined Behaviour is not an example of operations being defined.

Post reply on HN