Zig programming language

Zecc

@Gąska said in A picture book written in C code:

@dfdub while modern C++ is lightyears ahead of C++03, it's still incredibly kludgy, needlessly verbose and filled to the brim with deadly pitfalls compared to almost every other popular language. And as Rust has shown, being close to the metal has nothing to do with it.

I'm curious whether you have seen the Zig programming language, and what your thoughts on it might be.

I have no thoughts of my own.

Rhywden

@Zecc said in Zig programming language:

I have no thoughts of my own. 

You bastard!

Gąska

@Zecc said in Zig programming language:

@Gąska said in A picture book written in C code:

@dfdub while modern C++ is lightyears ahead of C++03, it's still incredibly kludgy, needlessly verbose and filled to the brim with deadly pitfalls compared to almost every other popular language. And as Rust has shown, being close to the metal has nothing to do with it.

I'm curious whether you have seen the Zig programming language, and what your thoughts on it might be.

No, but I will check it out and tell you.

Another interesting language I found once upon time was Nim, but it was highly experimental and AFAIK never went anywhere.

dkf

@Zecc said in Zig programming language:

what your thoughts on it might be

Initial thoughts are that the documentation could do with breaking up into more pages, omits a lot of things, and that the authors haven't got good experience with writing language specifications as they leave critical features (such as the evaluation order of expressions) undescribed. Their take on strings is not terrible, as they've clearly stated the encoding up front (and it's a sane one) but not great either and their standard library for them is very weak; they clearly haven't spent much time talking to language/library people who take strings seriously. Their multiline string literals suck (but not as badly as those of C and C++).

In fact, the more I read it, the more horrible their docs are. Their standard library docs are even more ghastly, and appear to lack even basic QA as I was finding things like sentences cut off half-

dfdub

@Gąska said in Zig programming language:

Another interesting language I found once upon time was Nim, but it was highly experimental and AFAIK never went anywhere.

At the very least, it seems to be alive:

Blog

The Nim programming language is a concise, fast programming language that compiles to C, C++ and JavaScript.

error

topspin

no hidden control flow
C++, D, and Rust have operator overloading, so the + operator might call a function.

I've never understood this complaint, but I'm willing to learn something new today. What's a better alternative to add two matrices together in a language without operator overloading?

PleegWat

@topspin said in Zig programming language:

no hidden control flow
C++, D, and Rust have operator overloading, so the + operator might call a function.

I've never understood this complaint

The problem is when + does not mean adding. Or << does not mean shift left.

I know a slight bit of haskell. There, you can't just overload operators, you can also make up your own.

topspin

@PleegWat said in Zig programming language:

@topspin said in Zig programming language:

no hidden control flow
C++, D, and Rust have operator overloading, so the + operator might call a function.

I've never understood this complaint

The problem is when + does not mean adding. Or << does not mean shift left.

Yeah, don't do that.
That doesn't answer my question though. How do you deal with the case where you want to do addition?

Rhywden

@topspin By weeping bitterly and making a function out of it?

topspin

@Rhywden said in Zig programming language:

@topspin By weeping bitterly and making a function out of it?

That's about as readable as lisp.

dkf

@PleegWat said in Zig programming language:

@topspin said in Zig programming language:

no hidden control flow
C++, D, and Rust have operator overloading, so the + operator might call a function.

I've never understood this complaint

The problem is when + does not mean adding. Or << does not mean shift left.

A much bigger complaint is that when it comes to vectors (for example), there are several entirely different multiplication operators, specifically the dot product and the cross product. Which one does * mean? It's not clear at all. And there's no requirement or really even guidance for people implementing their operators to encourage them to get sets of operations that actually work together sanely (such as enforcing mathematical concepts like rings and fields).

OTOH, the general complaint with operator overloading the other way is that it makes it hard to tell what a piece of code does by simple examination. The C++ “invisible” type-casting operators are particularly bad here.

hungrier

@Zecc

(didn't read)

Does it let you set up the bomb or take off for great justice?

e:

hungrier

@topspin said in Zig programming language:

That doesn't answer my question though. How do you deal with the case where you want to do addition?

What's wrong with var m3 = m1.add(m2) or MatrixMath.addTwoOfEmTogether(m1, m2)?

PleegWat

@dkf said in Zig programming language:

@PleegWat said in Zig programming language:

@topspin said in Zig programming language:

no hidden control flow
C++, D, and Rust have operator overloading, so the + operator might call a function.

I've never understood this complaint

The problem is when + does not mean adding. Or << does not mean shift left.

A much bigger complaint is that when it comes to vectors (for example), there are several entirely different multiplication operators, specifically the dot product and the cross product. Which one does * mean? It's not clear at all. And there's no requirement or really even guidance for people implementing their operators to encourage them to get sets of operations that actually work together sanely (such as enforcing mathematical concepts like rings and fields).

OTOH, the general complaint with operator overloading the other way is that it makes it hard to tell what a piece of code does by simple examination. The C++ “invisible” type-casting operators are particularly bad here.

I'll answer both of those with haskell developers happily using . for dot product and >< for cross product.

Rhywden

@hungrier It gets unwieldy if you have more than two?

Rhywden

@PleegWat Or switch to UTF8 and use ⋅ and ✕?

error

I'm fine with operators except assigment/equivalence only applying to primitive/value types. Even equivalence is somewhat ambiguous.

PleegWat

@Rhywden said in Zig programming language:

@PleegWat Or switch to UTF8 and use ⋅ and ✕?

I don't remember and don't care to find out if that's legal and treated as an operator (a plain x is a letter and won't work as infix operator, I remember that much).

topspin

@error said in Zig programming language:

I'm fine with operators except assigment/equivalence only applying to primitive/value types. Even equivalence is somewhat ambiguous.

How is "I don't know what equals does" better than "I don't know what == does"?

Rhywden

@PleegWat Oh, that's not an x. It's &#x2715.

error

@topspin said in Zig programming language:

@error said in Zig programming language:

I'm fine with operators except assigment/equivalence only applying to primitive/value types. Even equivalence is somewhat ambiguous.

How is "I don't know what equals does" better than "I don't know what == does"?

So try Object.ReferenceEquals or "Foo".Equals( "foo", StringComparison.IgnoreCase )...

error

I felt like Gradle was trolling me when I found out you could subtract a fileList from a fileList with -. That looks so weird to me.

magnusmaster

I don't like how memory management in Zig is done with defer. RAII in C++ works much better since the language guarantees that the destructors are called when the current scope ends without having to do any defer.

cvi

@error said in Zig programming language:

So try Object.ReferenceEquals

&foo == &bar? I find the fact that there's a tangible difference between the value and it's "reference value" quite neat. They are rather distinct (with their own distinct operations), so having no way of making that distinction seems like an unnecessary mess.

error

@cvi said in Zig programming language:

@error said in Zig programming language:

So try Object.ReferenceEquals

&foo == &bar? I find the fact that there's a tangible difference between the value and it's "reference value" quite neat. They are rather distinct (with their own distinct operations), so having no way of making that distinction seems like an unnecessary mess.

I was pointing out that == vs equals is a false dichotomy. There are, in fact, many forms of equality (string coalitions, deep comparison, shallow comparison, reference, value, etc). In this respect, I agree with you, but on the other hand, I feel the better solution is to be more explicit about what type of comparison you intend.

Also, most languages I use don't have pointers ( without unsafe code), so addressof isn't particularly applicable there.

Gąska

@Rhywden said in Zig programming language:

@PleegWat Or switch to UTF8 and use ⋅ and ✕?

I'm fairly sure this is actually possible in Scala.

topspin

@Gąska said in Zig programming language:

@Rhywden said in Zig programming language:

@PleegWat Or switch to UTF8 and use ⋅ and ✕?

I'm fairly sure this is actually possible in Scala.

Or APL. But my keyboard has only so many letters.

dkf

@Rhywden said in Zig programming language:

@PleegWat Or switch to UTF8 and use ⋅ and ✕?

No to the latter, because × is a thing.

Parody

@hungrier said in Zig programming language:

@Zecc

(didn't read)

Does it let you set up the bomb or take off for great justice?

e:

I would have said "Compile .zig, for great program."

cvi

@error said in Zig programming language:

There are, in fact, many forms of equality

A fun fact C++ discovered while trying to figure out the spaceship operator (operator <=>).

Gąska

@topspin said in Zig programming language:

@Gąska said in Zig programming language:

@Rhywden said in Zig programming language:

@PleegWat Or switch to UTF8 and use ⋅ and ✕?

I'm fairly sure this is actually possible in Scala.

Or APL. But my keyboard has only so many letters.

ąśżźęćńół

topspin

@Gąska said in Zig programming language:

@topspin said in Zig programming language:

@Gąska said in Zig programming language:

@Rhywden said in Zig programming language:

@PleegWat Or switch to UTF8 and use ⋅ and ✕?

I'm fairly sure this is actually possible in Scala.

Or APL. But my keyboard has only so many letters.

ąśżźęćńół

Who are you calling an ass?

Zecc

@Gąska said in Zig programming language:

ąśżźęćńół

I wouldn't be able to tell whether that's a real Polish word or not.

sockpuppet7

@error said in Zig programming language:

I was pointing out that == vs equals is a false dichotomy. There are, in fact, many forms of equality (string coalitions, deep comparison, shallow comparison, reference, value, etc). In this respect, I agree with you, but on the other hand, I feel the better solution is to be more explicit about what type of comparison you intend.

I think java would be saner if it didn't have a == operator at all than this shit they did

Gąska

@dfdub said in Zig programming language:

@Gąska said in Zig programming language:

Another interesting language I found once upon time was Nim, but it was highly experimental and AFAIK never went anywhere.

At the very least, it seems to be alive:

Blog

The Nim programming language is a concise, fast programming language that compiles to C, C++ and JavaScript.

Wow, a lot has changed since I last looked at it! It seemed very dead at one point.

error

@Gąska said in Zig programming language:

@Rhywden said in Zig programming language:

@PleegWat Or switch to UTF8 and use ⋅ and ✕?

I'm fairly sure this is actually possible in Scala.

Gąska

@Zecc said in Zig programming language:

@Gąska said in A picture book written in C code:

@dfdub while modern C++ is lightyears ahead of C++03, it's still incredibly kludgy, needlessly verbose and filled to the brim with deadly pitfalls compared to almost every other popular language. And as Rust has shown, being close to the metal has nothing to do with it.

I'm curious whether you have seen the Zig programming language, and what your thoughts on it might be.

Finally getting the writeup. Because apparently 18 out of 33 people hate the dissect-at-sub-statement-level kinds of posts, I'll just make a bullet list of my thoughts as I go along the doc linked in OP.

I don't like the focus on being "small, simple language" and listing "specified with a 500-line PEG grammar file" as a plus. It's a positive, but it's so insignificant in the grand scheme of things that it makes me wonder whether the devs sacrificed anything important to achieve that.
It says "no hidden control flow". I read it as "no destructors, no transparent smart pointers, no RAII, and likely no lambdas". I don't like where this is going.
Mixing different sets of optimization flags within one build sounds interesting, but not very useful.
Built-in testing is nice, although I'm not sure how I feel about integrating it at language grammar level. Sounds like a potential roadblock for when you'd like low-level unit tests and high-level system tests with very different setup code. Also, due to this special treatment of tests, other, non-test-related conditional compilation scenarios might be neglected.
Built-in SIMD types sound great!
I'm not sure how I feel about arbitrary bit-width integers. Feels very weird, but then it guarantees type-safety of bit fields.

7. Leaving the choice of value vs. reference to the compiler sounds like interoperability hell. ABI changes at the whims of optimizer - imagine the fun debugging that! Also, a big performance surprise just waiting to happen.

I like the @ syntax for built-ins. Stands out in the crowd of symbols.
defer considered harmful.
I hate the tagged union syntax, the explicit tag type, and that tagged unions aren't the default.
I confirmed that all my worries in point 2 are indeed true and now I'm a sad panda.
I like the very explicit memory allocation (for those who haven't read the article - all allocating functions take allocator as argument, and you MUST handle allocation failure). Though I'd probably quickly learn to hate it.
The if syntax feels... iffy. What happens when you have optional bool? What happens when you have optional optional?
I like the error return traces. Although this seems doable as a library. Hmm... *takes out an old Rust compiler and IDE and runs updates*

15. Am I reading this correctly? Does Zig use a global compilation cache? I don't like it. I really really don't like it. I'll never let Zig live outside a VM. Been burned by these too many times.

And why the hell does it double as a C compiler?
I like the focus on cross-compilation.
I don't like inferred asyncness, for the same reason Zig devs don't like inferred return types.

19. One of the best implementation of coroutines/async functions I have ever seen. Maybe the best. And it doesn't use dynamic allocations! Although I think inferred async-ness is a bad decision. It's one of those things you really want to know about a function.

What exactly is the purpose of suspend blocks? What can be done with them that cannot be done otherwise?
Lots of targets working. Even WAsm. Nice.

So that sums it up. Overall - quite nice, although it's very apparent it aims at the C crowd and ignores the needs of high-level programmers (unlike Rust!). A few interesting design decisions. But the auto-pass-by-ref thing (7) is a deal breaker to me. And even without that, I just don't see anything very compelling to make me switch from Rust. But if I ever find myself on a target that doesn't have Rust support, I'd definitely consider Zig.

I'd like to learn about the async implementation more. It sounds too perfect to be true. There are some big pitfalls to watch out for. I just know it.

error

@error said in Discussion of NodeBB Updates:

My name is Gá̵̛͈̦̟̞̗͍̺͂̊͌̔̀͋̑͌͘ska, and it has been one year, two months, six days, and 4 hours since I last used Rust.

@Gąska said in Zig programming language:

takes out an old Rust compiler and IDE and runs updates

sadly flips counter back to 0

pie_flavor

@topspin It's funny that he mentions Rust. In fact, the + operator in Rust only calls a function. Every single usage of it is an invocation of std::ops::Add::add, and every single usage of == is std::cmp::PartialEq::eq, whether numeric or miscellaneous. So it's not hidden at all, and in fact quite the opposite.

pie_flavor

@Gąska said in Zig programming language:

@Rhywden said in Zig programming language:

@PleegWat Or switch to UTF8 and use ⋅ and ✕?

I'm fairly sure this is actually possible in Scala.

In Raku, it would not even be out of place, and instead following stdlib convention.

pie_flavor

@sockpuppet7 said in Zig programming language:

@error said in Zig programming language:

I was pointing out that == vs equals is a false dichotomy. There are, in fact, many forms of equality (string coalitions, deep comparison, shallow comparison, reference, value, etc). In this respect, I agree with you, but on the other hand, I feel the better solution is to be more explicit about what type of comparison you intend.

I think java would be saner if it didn't have a == operator at all than this shit they did

Debatable. At least it's consistent. C# is worse, as there's something like three kinds of equality, all user-implementable, all implemented separately.

pie_flavor

@Gąska said in Zig programming language:

ignores the needs of high-level programmers (unlike Rust!).

Not just that, it ignores the capability of previously C code to become high-level. Sig line 2.

Gąska

@pie_flavor said in Zig programming language:

@Gąska said in Zig programming language:

@Rhywden said in Zig programming language:

@PleegWat Or switch to UTF8 and use ⋅ and ✕?

I'm fairly sure this is actually possible in Scala.

In Raku, it would not even be out of place, and instead following stdlib convention.

The important thing is that they have an excuse why nobody uses it. "People just don't have all these keys on the keyboard, otherwise we'd rival Java!"

error

@Gąska said in Zig programming language:

@pie_flavor said in Zig programming language:

@Gąska said in Zig programming language:

@Rhywden said in Zig programming language:

@PleegWat Or switch to UTF8 and use ⋅ and ✕?

I'm fairly sure this is actually possible in Scala.

In Raku, it would not even be out of place, and instead following stdlib convention.

The important thing is that they have an excuse why nobody uses it. "People just don't have all these keys on the keyboard, otherwise we'd rival Java!"

They need to design a language that's a superset of TeX.

Zecc

@error Now I'm hoping there's a language which is a subset of TeX and is named SubTeXt.

cvi

@error said in Zig programming language:

They need to design a language that's a superset of TeX.

Long time ago, I added a bunch of TeX as abbreviations to my editor. So when I type \epsilon; it replaces it with ε, \times; => × etc. (The semicolon at the end is to disambiguate it from actual TeX, where I want to keep the "command".)

I originally did it mostly on a lark, but I've ended up using it somewhat frequently.

Unicode even has some support for multi-line stuff, like

⎛ a b c ⎞ 
⎜ δ e f ⎟
⎝ g h i ⎠

dkf

@Gąska said in Zig programming language:

It says "no hidden control flow". I read it as "no destructors, no transparent smart pointers, no RAII, and likely no lambdas". I don't like where this is going.

FWIW, I'm mostly of the no-implicit-stuff camp, but you seem to be getting some misconceptions of what that might mean as a result of your exposure to ~~massive impact-induced brain trauma~~ C++. To whit:

I couldn't even figure out if the language has constructors, their documentation was that poor. If it doesn't, lacking destructors is at least unsurprising (and the result is that you have to make allocation and freeing functions for all your non-trivial data structures, just as one probably does in C at the moment).
The language designers probably see the “no transparent smart pointers” as a feature. That's the kind of hidden magic that they don't like. I'd guess that they'd be happier with having smartness of pointers only if they were a base feature of the language, as that would lock out third-parties from putting in non-obvious stuff: it's not that smart pointers are themselves a problem, but rather that making them implementable using standard features opens up the less-than-wise to being able to make some true horrors. Which is the whole point of “no-implicit”.
In languages without RAII, you get constructs like using (C#), with (Python) or try-with-resources (Java). There are equivalents in other languages too. These all have the controlled wind-down after running a block of code yet also have the explicit-ness property. The examples I've cited are all in garbage-collected languages, but that's a wholly orthogonal feature.
Lambdas are always considered to be explicit, but care needs to be taken with variable capture in their definition for that to be fully true. For example, capturing the whole visible stack frame and then allowing that to be passed out (closure semantics) leads to exceptionally non-trivial behaviours and would be considered to be implicit in critical aspects. Only capturing variables that are explicitly mentioned would be less complex, especially if they were constrained to be constants within the lambda. Not capturing at all would be extremely explicit, but make lambdas little more than unnamed conventional functions. (Capturing mutable values without GC is where language implementations get… tricky.)

Details matter. Which is where the crappy documentation comes to the fore…

Gąska

@dkf said in Zig programming language:

@Gąska said in Zig programming language:

It says "no hidden control flow". I read it as "no destructors, no transparent smart pointers, no RAII, and likely no lambdas". I don't like where this is going.

FWIW, I'm mostly of the no-implicit-stuff camp

Well, your compilers are buggy as hell, so I understand why you would.

(Real answer coming when I get back home.)

dkf

@Gąska said in Zig programming language:

I'm not sure how I feel about arbitrary bit-width integers. Feels very weird, but then it guarantees type-safety of bit fields.

One of the main reasons it is usually not done is because working out what the bit widths of the result of intermediate functions should be is tricky (and not always obvious). It's something of a pain in practice, and results in other problems. What is the bit width of the number 1 anyway? Or of the expression x + 1? Yes, it is possible to figure out something that would work, but it's still a level of bonus mess that most programmers are not at all close to being used to.

I did some work with/on a language (for hardware) that had explicit integer widths. In that case it made a ton of sense, but it was definitely hard work.