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

71–80 of 290 posts

Re: Problems of C, and how Zig addresses them

#71

Post by chc »

quirino wrote: post #33
square_usual wrote: post #27

You can repeat "C is a minimal abstraction over assembly" as many times as you want, it doesn't make it true.

Could you specify the main ways it isn't? I have limited experience in both but I haven't seen much that suggests otherwise

Many features of C do not directly correspond with most modern assembly languages. You cannot predict the exact assembly it will generate without knowing a lot of details about your compiler and platform, and even then it's often iffy. It seems like a bit of a leap to call something "a minimal abstraction" if you can't even correctly describe how an operation in the abstraction corresponds to operations in the lower level.

Re: Problems of C, and how Zig addresses them

#72

Post by matrix_overload »

tialaramex wrote: post #55
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…

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 and do it in C/C++ because the overhead outweighs my curiosity.

Most pragmatists don't have infinite time to learn a new programming language for fun. They have a very limited amount of attention and tight time constraints, and will move to the next pragmatic solution if it starts looking like the current one is not cutting it.

Re: Problems of C, and how Zig addresses them

#74

Post by flohofwoe »

square_usual wrote: post #27

You can repeat "C is a minimal abstraction over assembly" as many times as you want, it doesn't make it true.

Technically that's true because of the "C virtual machine", but pragmatically, C is still the "lowest-level high-level programming language" at least among the popular programming languages (arguably only Forth is lower level, but Forth isn't exactly mainstream).

(and I'd argue that C is closer to assembly than assembly is to what's actually happening inside the CPU, e.g. assembly itself is a high-level abstraction layer that's still pretty close to C - which isn't all that surprising because both probably developed as a symbiosis over time - especially when you look at all the non-standard language extensions in various C compilers)

Re: Problems of C, and how Zig addresses them

#75

Post by mike_hearn »

flohofwoe wrote: post #66
astrobe_ wrote: post #50

About macros and comptime: why is the compiler unable to detect that a function is a pure function, and if it is called with constants, the result can be computed ahead of time? At least in the simple cases such as the square example, which are I believe quite common, that would work. Maybe still add an annotation to make sure the compiler will do what the user expects, because humans are terrible compilers after all…

C/C++ compilers will do this when optimization is enabled (I guess the reason that's not done without optimization is to preserve "debuggability"). Notice how the add() function is completely 'disolved' into its result '5' here: https://www.godbolt.org/z/q98svvacW (the main difference to comptime is that this guarantees that the code is resolved at compile time, and if that's not possible you'll get an error). The bi…

Graal's native-image tool also does a form of this. The compiler actually executes parts of your program at compile time, but it's real execution so you can theoretically do anything. The heap data that's generated is then persisted into the program. You can debug such code just like normal code by just running it on HotSpot instead.

Re: Problems of C, and how Zig addresses them

#76

Post by matrix_overload »

Night_Thastus wrote: post #64
matrix_overload wrote: post #58

Earlier quoted context omitted.

I would dare say, different combination of early adopters/pragmatists in your target audience. C/C++ these days is mostly legacy stuff, so if you want to cater to that audience, you deliver small incremental improvements. Many people that could be bothered to learn Zig syntax, jumped ship to Python/Java/whatever already.

Zig and Python/Java are completely different beasts. One is a low-level systems language on the order of Rust or C. The other two are much higher level, easier to work with languages more attuned to desktop, mobile applications and enterprise work. I don't think anyone is seriously "jumping ship" from Zig to those.

Low-level programming isn't the holy grail. If a person gets fed up with limitations of C, they might as well move to a higher-level domain area as well. Especially, given the higher pay there.

Those who haven't will have a much lower tolerance for changes. Survivor bias of a kind.

Re: Problems of C, and how Zig addresses them

#77

Post by steveklabnik »

quelsolaar wrote: post #37

Technically there is no "compile time" in C. Any part of the program can be computed at compile time or at runtime. Its entirely up the the implementation. The AS-IF rule in the C standard lets implementations do whatever they want as long as the program outputs the same things. The pre-processor, const expressions, constexpr (a for this reason compliably broken feature in my opinion), even text parsing and tokenizat…

C23 includes constexpr for some constructs, by the way.

Re: Problems of C, and how Zig addresses them

#78

Post by LexiMax »

One thing that was unclear to me based on my prior noodling with Zig was what the plans were for supporting interface or trait-based polymorphism.

I've been falling in love with C++'s std::experimental::is_detected and am looking forward to being allowed to use C++20 in my environment since it will bring Concepts, but in my cursory examination it seems Zig seems to prefer vtable abstractions like Allocator.VTable.

Re: Problems of C, and how Zig addresses them

#79

Post by tmtvl »

k__ wrote: post #60
tmtvl wrote: post #29

Earlier quoted context omitted.

The problem I believe is being discussed is that dereferencing a pointer after the memory it references is freed does not throw a warning at compile time. This means the programmer has to manually keep track of pointers, making sure not to free the relevant memory until there are no more references to it lingering about. While there are programming techniques which to lesser or greater extent prevent problems from oc…

So, Zig set out to solve all but the biggest issue with C?

That seems to be what OP is implying. I haven't used Zig, so I can't say. I suppose people who want to avoid memory management related bugs who can't acccept a GC language can use Carp.

Re: Problems of C, and how Zig addresses them

#80

Post by flohofwoe »

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…

IIRC even K&R Second Edition acknowledges that the C type syntax is awkward for non-trivial cases.

The "new" style used by Go, Rust, Zig, Typescript etc... is a lot easier to read because it always 'resolves' from left to right.

Post reply on HN