You can repeat "C is a minimal abstraction over assembly" as many times as you want, it doesn't make it true.
C is an abstraction over assembly. It is also minimal compared to prolog.
So is JOVIAL, FORTRAN 66, PL/S, BLISS...
Problems of C, and how Zig addresses them
241–250 of 290 posts
Re: Problems of C, and how Zig addresses them
#242You can repeat "C is a minimal abstraction over assembly" as many times as you want, it doesn't make it true.
I’m just old enough to remember when C and Pascal were called high-level languages. “C is actually assembly” was quite a plot twist from there.
You can thank Rob Pike for that, about a decade ago he wrote a Google Plus post arguing that one of the things C brought to the table was that it essentially was portable assembly compared to most other high level language projects at the time. I guess the tiny sliver of nuance that the "essentially" added was quickly lost.
Re: Problems of C, and how Zig addresses them
#243That was a nice, clear explanation that even I could understand. One thing I wasn't sure about, though. var arr = [_]u32{ 1, 2, 3, 4, 5, 6 }; // 1, 2, 3, 4, 5, 6 const slice1 = arr[1..5]; // 2, 3, 4, 5 const slice2 = slice1[1..3]; If I were to use indices out of range, presumably that would that give me a compile time error? Could I use variables as the indices and, if so, could I get a seg fault at runtime or are th…
Zig has bounds checking built-in. You can decide to remove it if you compile for ReleaseSafe instead of ReleaseFast, but it's always in debug builds.
I just realized I swapped the two but it's too late. The bounds checks obviously stay in ReleaseSafe, not ReleaseFast.
Re: Problems of C, and how Zig addresses them
#244I remain confused about how Zig makes it to the front page of Hacker News so often. As far as I know, no one is using it in production after 7 years of development. Are people just really excited about this project? Are the people behind it just really good at marketing? Honest question: why do we all keep talking about Zig?
One thing nobody has pointed out yet - and this is not a knock on any language whatsoever but moreso a commentary on HN itself , so take it with a grain of salt, but: if you've followed this site since the beginning, programming languages cycle through here with a hype phase every few years like clockwork. The one most people jump to from the past few years is Rust and/or Go, but we've experienced this with other lan…
Go was mostly hated on when it came out iirc.
Re: Problems of C, and how Zig addresses them
#245Earlier 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.
Legacy stuff like the compiler and runtime used by the new hip languages or the webserver, browser, database, libraries needed to run those programs, or the OS, hypervisor, device drivers needed by the machine those programming run on.
Thankfully most of those are C++ and not C, and some hip languages are bootstraped.
Re: Problems of C, and how Zig addresses them
#246Earlier quoted context omitted.
> When it was crated it would be difficult and unwise to assume that an integer has size of 2 bytes It was still a bad design. Of course this is in hindsight, but history has taught is it would have been much better if the default was for specific sized integers, with an option to use `uint_fast32_t` or whatever.
History says otherwise: C was so successful it is still widely used.
Just because something is popular doesn't mean it's good. Tobacco smoking is also popular.
Re: Problems of C, and how Zig addresses them
#247Earlier quoted context omitted.
How would the language require it to be numerical? For example, if you're defining complex numbers in a library, what would the compiler be checking about your ComplexNumber type before allowing you to define `+` for it?
A few ways. The compiler could enforce commutativity, associativity and other properties of those operators. Another possible route is to require that all types contained within the exported types are also numerical, or have some specific set of operators defined.
Do you mean at the type level or also for the operational semantics? In the latter case it's undecidable.
Also, you mentioned matrices in the previous comment, but multiplication between matrices is not commutative.
Re: Problems of C, and how Zig addresses them
#248Earlier quoted context omitted.
Apple shipped a LLVM cross-compiler for Apple silicon on day one? Not entirely sure what you mean here.
Somehow no one managed to make cross-compilers work, even though it is the standard way of working in embedded and game consoles for decades.
Yeah idk. I don’t want to be snarky but “we had a cross compiler for ARM with a few tweaks” that had already had hardware shipping for half a decade doesn’t sound all that impressive.
Re: Problems of C, and how Zig addresses them
#249Earlier quoted context omitted.
> When it was crated it would be difficult and unwise to assume that an integer has size of 2 bytes It was still a bad design. Of course this is in hindsight, but history has taught is it would have been much better if the default was for specific sized integers, with an option to use `uint_fast32_t` or whatever.
Then we would be stuck with 16 bits integers. We are lucky to be in a point in time where integer types have been stable for a while, but it wasn't always so.
We wouldn't. People would update their code eventually or opt in to variable sized integers.
Re: Problems of C, and how Zig addresses them
#250Earlier quoted context omitted.
May I suggest you give arguments why it is not (and why we should care about those arguments from a practical standpoint), and what language should better earn the title?
Others have already made a few in response, but for reference, this ACM queue article [1] is a good place to start. It has been widely discussed both on HN and elsewhere, and a simple search of the title can bring up several counter-arguments etc. if you're interested and want to know more. > what language should better earn the title? None. 1: https://queue.acm.org/detail.cfm?id=3212479
This article states that "C is not a Low-Level Language", not that it is not a thin abstraction over assembly. The arguments in the article could as well be used to make a point that "Assembly is not a Low-Level Language".