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

Problems of C, and how Zig addresses them

avestura.dev

Post reply on HN
Print view View original

101–110 of 290 posts

Re: Problems of C, and how Zig addresses them

#101

Post by messe »

IshKebab wrote: post #54
Joker_vD wrote: post #45

Earlier quoted context omitted.

> The operations C gives you map 1-to-1 with assembly int test(int x, int y) { return x % y; } test: // @test sdiv w8, w0, w1 msub w0, w8, w1, w0 ret Surprisingly, assembly doesn't have the remainder instruction, but instead it has a multiply-then-subtract instruction which is not corresponding 1-to-1 to anything in C.

x86 doesn't have remainder. Other instruction sets do. But yeah I agree with your point. Some targets might not even have multiply.

> x86 doesn't have remainder

The code in the comment you replied to is 64-bit ARM assembly.

Re: Problems of C, and how Zig addresses them

#102

Post by luckystarr »

chongli wrote: post #95
pixelpoet wrote: post #83

I'm super sold on Zig except that it doesn't make graphics/vector coding with operator overloading possible :( I've heard what Andrew Kelley has to say about it ("that ONE little feature from C++...") but it's just a very sad situation for what otherwise looks like a lovely basis for graphics coding. Actually, I don't even want operator overloading in general (leading to stuff like the C++ stream API), it's JUST for…

Don’t even need operator overloading for vectors/matrices. It would be fine if we could simply define new operators (functions with infix notation) and use those. This would allow us to define an operator for matrix multiplication, matrix-vector product, dot product, and cross product. Having to define these operators as functions with unique text names is extremely ugly and serves no purpose that I can see.

What was the language which used backticks to transform any function into an infix binary operator? Ruby? Perl?

Something like this could actually fulfill Andrews goal of not having any hidden control flow, as the function would be plainly visible.

The other thing of course would be, what then the valid function names would be? Definitely not `*` but probably `×` or whatever.

Re: Problems of C, and how Zig addresses them

#103

Post by WalterBright »

travisgriggs wrote: post #18

Tangentially... I'm grateful that these new batches of systems languages have chosen to use the u8, i32, etc, style integer types. Rather than the uint8_t and int32_t style. First thing I do in any of my low level embedded C projects is put in the various uNN/iNN types.

D uses byte, short, int, long for i8, i16, i32, i64, and ubyte, ushort, uint, and ulong for the unsigned versions. After 5 minutes with the language there is no longer any point to emphasizing the number of bits. Besides, they're just easier to touch type.

Re: Problems of C, and how Zig addresses them

#104

Post by tialaramex »

matrix_overload wrote: post #72
tialaramex wrote: post #55

Earlier quoted context omitted.

If you just keep C ideas you might almost just as well give up altogether. C# actually only resembles C rather superficially, idiomatically there's a large gap and of course you should write idiomatic code, for example it's true you can write a C-style for loop in C#, but you almost never should, C# has a (not great, but it's something) for-each loop that's idiomatic. C#'s primitive types look superficially like C ty…

>for example it's true you can write a C-style for loop in C#, but you almost never should, C# has a (not great, but it's something) for-each loop that's idiomatic. This makes the learning curve way easier. You can start meaningfully using C# while using C-style for loops, and eventually switch to 'foreach' once you realize it's better. If I wanted to give Zig a try today by using it for some small low-priority task,…

> I would keep stumbling on these minor syntax differences all the time, and would eventually give up

I can't necessarily fault Zig for the state of this so early in its lifetime, but - that should not be a big problem, handling transition is work for the diagnostics.

Suppose I write this in Rust: printf("%d", count);

Rust says it can't find a function named printf, but it suggests perhaps I want the print! macro instead?

OK, let's try again: print!("%d", count);

No, says Rust, % style format strings aren't a thing in Rust, use {curly brackets}

Sure enough: print!("{count}"); // compiles and works.

Re: Problems of C, and how Zig addresses them

#105

Post by sfpotter »

jorangreef wrote: post #48
sfpotter wrote: post #38

C is standardized and is one of the most (the most?) widely used programming language on the planet. If you write code targeting a C standard and don't include many unstable dependencies, it has a good chance of running correctly for a very long time. If you move from C to Zig, you lose that stability. Are Zig's convenience features really enough to compensate for this loss?

One of the main reasons, in fact, that we picked Zig for TigerBeetle (over C, which was the alternative, given we needed to handle memory allocation failure), was because of Zig's excellent interoperability with the C ABI. For example, we write the reference TigerBeetle client implementation completely in Zig, then wrap this with the C ABI, and then bind to this C ABI from all target languages, to increase our veloci…

Sounds cool but doesn’t address my question. Do you think the relative instability of Zig will hurt you? Or do the benefits outweigh the costs? Lots of languages make it easy to talk C ABI (including… C itself). So why Zig?

I guess the people downvoting my assume I’m hostile to Zig. I’m not. I’m saying that the stability of C is a selling point and I’m curious what features of Zig are so valuable that people are giving that up.

Re: Problems of C, and how Zig addresses them

#106

Post by chrisoverzero »

luckystarr wrote: post #102
chongli wrote: post #95

Earlier quoted context omitted.

Don’t even need operator overloading for vectors/matrices. It would be fine if we could simply define new operators (functions with infix notation) and use those. This would allow us to define an operator for matrix multiplication, matrix-vector product, dot product, and cross product. Having to define these operators as functions with unique text names is extremely ugly and serves no purpose that I can see.

What was the language which used backticks to transform any function into an infix binary operator? Ruby? Perl? Something like this could actually fulfill Andrews goal of not having any hidden control flow, as the function would be plainly visible. The other thing of course would be, what then the valid function names would be? Definitely not `*` but probably `×` or whatever.

> What was the language which used backticks to transform any function into an infix binary operator? Ruby? Perl?

Haskell.

Re: Problems of C, and how Zig addresses them

#107

Post by tyg13 »

luckystarr wrote: post #102
chongli wrote: post #95

Earlier quoted context omitted.

Don’t even need operator overloading for vectors/matrices. It would be fine if we could simply define new operators (functions with infix notation) and use those. This would allow us to define an operator for matrix multiplication, matrix-vector product, dot product, and cross product. Having to define these operators as functions with unique text names is extremely ugly and serves no purpose that I can see.

What was the language which used backticks to transform any function into an infix binary operator? Ruby? Perl? Something like this could actually fulfill Andrews goal of not having any hidden control flow, as the function would be plainly visible. The other thing of course would be, what then the valid function names would be? Definitely not `*` but probably `×` or whatever.

Haskell does this.

Re: Problems of C, and how Zig addresses them

#108

Post by xcv123 »

matrix_overload wrote: post #43

It is nice and innovative, no doubt. But reinventing the syntax from scratch instead of introducing just the minimal amount of changes to the original C is a barrier that will deter 90% of possible adopters. The reason C# took off is that it's as close to C/C++ as possible. If there is a difference, it's due to a fundamental semantic change. E.g. it moved from painstakingly reinterpreting hundreds of small header fil…

> And that's the main reason why many people will never consider even looking into the advantages Zig offers.

I think you got it upside down. Syntax is the least of its problems. Any experienced developer has already learned several languages and can pick up new syntax quickly. Zig syntax is straightforward, similar to other languages, and can be learned in a couple of hours. Easy stuff. The problems with Zig are more related to uncertainty around long term support, the network effect, and so on.

Re: Problems of C, and how Zig addresses them

#109

Post by estebank »

throwawaymaths wrote: post #100
estebank wrote: post #94

Earlier quoted context omitted.

Careful, you're dangerously close to suggesting an effects system. If the function explicitly marked as doing unsafe math operations calls another that doesn't specify a preference, should its math operation be safe or unsafe? If the former, this makes it likely a better default, but limiting in its usefulness. If the later, then your compiler now has to keep track of this information for the entire call graph.

The form of safety we are talking about here is not like rust's "safety", it does not color functions, and is strictly scoped to the compiled unit (in this case, function) https://ziglang.org/documentation/master/#setRuntimeSafety

I am aware, my point is about how the following is dealt with:

  fn foo(x: i32) i32 {
      return x + 100;
  }
  fn bar(x: i32) i32 {
      @setRuntimeSafety(false);
      return foo(x + 100);
  }
Particularly when you have arbitrarily deep call graphs where some explicitly enable and disable runtime safety.

Re: Problems of C, and how Zig addresses them

#110

Post by rscho »

luckystarr wrote: post #102
chongli wrote: post #95

Earlier quoted context omitted.

Don’t even need operator overloading for vectors/matrices. It would be fine if we could simply define new operators (functions with infix notation) and use those. This would allow us to define an operator for matrix multiplication, matrix-vector product, dot product, and cross product. Having to define these operators as functions with unique text names is extremely ugly and serves no purpose that I can see.

What was the language which used backticks to transform any function into an infix binary operator? Ruby? Perl? Something like this could actually fulfill Andrews goal of not having any hidden control flow, as the function would be plainly visible. The other thing of course would be, what then the valid function names would be? Definitely not `*` but probably `×` or whatever.

Racket
Post reply on HN