6 ms·

Sorry to see this at the bottom of the thread, because you have a real point here. None of the attempts at "better C" or even "replacing C" have been serious at

Sorry to see this at the bottom of the thread, because you have a real point here. None of the attempts at "better C" or even "replacing C" have been serious attempts, and it's frankly getting a bit insulting. No one who still uses C wants its replacements to "catch up" on the past 20 years of new language development. We want C, but without the problems. We don't want D but less so. The response below - "you don't have to use any features if you don't want to!" - is a ridiculous cop-out and the same thing people who defend C++ are saying.

snazz 7y ago
While I understand the value in a small language that you can wrap your head around, I think that that is a relatively uncommon problem that real-world language developers shouldn't be catering to today (and C certainly isn't small or simple). These days, programs are simply expected to do more while not suffering from the kinds of security vulnerabilities that C code is so chock-full of. A lot of the solutions for these problems necessitate an increase in complexity. I can understand that "you don't have to use any features if you don't want to" is somewhat silly when talking about C++, since it has so many features that can bite you when you least expect it, especially when dealing with years of legacy code. D is far better designed than C++, however; it would not take you nearly as long to learn enough D to be comfortable reading others' code. All I'm trying to say is that "C, but without the problems" might actually look more like BetterC than you think it does. True zero-cost abstractions are clearly still an unsolved problem, but abstractions are a necessity. C's niche is rapidly disappearing. Also, out of curiosity, what don't you like about Zig? I saw this on your website, but I couldn't find any specific issues you'd had with it. > Wow, Zig is competitive with assembly? > Yeah, I totally had the same reaction. I’m interested to see how it measures up under more typical workloads. People keep asking me what I think about Zig in general, and I think it has potential, but I also have a lot of complaints. It’s not likely to replace C for me, but it might have a place somewhere in my stack.
kreco 7y ago
Thanks for your comment. It's pretty normal to face this downvotes when talking about language. And my phrasing was not the most kind of all. It's just the CS community, at some point when you are writing languages you tend to try to outsmart the language you are fixing by creating overly complex behavior. Over-engineering is every single new languages. Even Zig fails to do better than C, I think it's syntactically a disaster. Here is a few lines from the documentation: const ptr = @intToPtr(?*i32, 0x0); while (it.next()) |item| { /* ... */ } pub fn main() anyerror!void { /* ... */ } exe.addCSourceFile("test.c", [_][]const u8{"-std=c99"}); const file = std.fs.cwd().openFile("does_not_exist/foo.txt", .{}) catch |err| label: { /* ... */ }
- snazz 7y ago
  Do you not like those because they're unfamiliar? What about the syntax indicates over-engineering? Here's what I see in your example: - @ indicates built-in function, which avoids namespace collisions. - Optional types via the ?, which solves the null pointer problem. - Real iterators, which are less error-prone and nicer to read than traditional for loops in a lot of common applications. - The || syntax is better than something like `for (type var : array)` in Java, don't you think? Especially since it works with any iterator? - anyerror!void is a nice way of saying that the function can return an error. Remember that we don't have exceptions here. - It has interoperability with (multiple standards of) C. - Error handling is higher-level and less error-prone than in C without exceptions that can create hidden jumps in your code. So it clearly solves issues that people run into frequently in C. It brings in a nice sampling of high-level language features without doing anything that would compromise its niche as a systems language. It still has manual memory management and does not have exceptions. The behavior is simpler and requires that you language-lawyer the specification for undefined behavior far less often than in C. Your knowledge of C isn't necessarily enough to be able to immediately read Zig code, but that's because Zig isn't C. It's not hard to learn.
  - kreco 7y ago
    Thanks for spending your time explaining this. I think a lof people will understand those lines better. I actually already knew everything. I watched closely the development of Zig, and just give up when I realized all those decisions where made carelessly in my view or I just simply disagree with the direction of the syntax. Since you took your time I will take mine to address what I don't like: - There is no way to write "int" by default. I understand why. But I don't agree. - struct and enum statements (within braces) are separated by a comma which is inconsistent with statements in function separated with ",". In my view expect a difference between parameters and statements. parameters (a,b,c) statement {a;b;c} - You have to type "var" or "const" everywhere, but not in struct statement and enum statement. Sometimes it's like a "def" sometimes not. - You have to type const when importing module: const std = @import("std"); // Why ? Why should I specify const, this should be inferred. Same when I define a struct. - the "undefined" keyword when it means "uninitialized" even in the documentation. var my_var: i32 = undefined; - The worst, no default values for struct. - The list of keywords is insane: errdefer, allowzero, orelse, unreachable, anyerror - About iterator I was doing well with: while(get_next(context, &item)) { /* ... */ } It's like everything has been carefully design to be even less readable than C code. I have the feeling that the syntax help more the compiler than de developer. I wish I could bet thousands of dollars that there will be only one compiler in the whole life of Zig language (also because it relies way too much to LLVM).

snazz 7y ago

While I understand the value in a small language that you can wrap your head around, I think that that is a relatively uncommon problem that real-world language developers shouldn't be catering to today (and C certainly isn't small or simple). These days, programs are simply expected to do more while not suffering from the kinds of security vulnerabilities that C code is so chock-full of. A lot of the solutions for these problems necessitate an increase in complexity. I can understand that "you don't have to use any features if you don't want to" is somewhat silly when talking about C++, since it has so many features that can bite you when you least expect it, especially when dealing with years of legacy code. D is far better designed than C++, however; it would not take you nearly as long to learn enough D to be comfortable reading others' code. All I'm trying to say is that "C, but without the problems" might actually look more like BetterC than you think it does. True zero-cost abstractions are clearly still an unsolved problem, but abstractions are a necessity. C's niche is rapidly disappearing. Also, out of curiosity, what don't you like about Zig? I saw this on your website, but I couldn't find any specific issues you'd had with it. > Wow, Zig is competitive with assembly? > Yeah, I totally had the same reaction. I’m interested to see how it measures up under more typical workloads. People keep asking me what I think about Zig in general, and I think it has potential, but I also have a lot of complaints. It’s not likely to replace C for me, but it might have a place somewhere in my stack.

kreco 7y ago

Thanks for your comment. It's pretty normal to face this downvotes when talking about language. And my phrasing was not the most kind of all. It's just the CS community, at some point when you are writing languages you tend to try to outsmart the language you are fixing by creating overly complex behavior. Over-engineering is every single new languages. Even Zig fails to do better than C, I think it's syntactically a disaster. Here is a few lines from the documentation: const ptr = @intToPtr(?*i32, 0x0); while (it.next()) |item| { /* ... */ } pub fn main() anyerror!void { /* ... */ } exe.addCSourceFile("test.c", [_][]const u8{"-std=c99"}); const file = std.fs.cwd().openFile("does_not_exist/foo.txt", .{}) catch |err| label: { /* ... */ }

snazz 7y ago
Do you not like those because they're unfamiliar? What about the syntax indicates over-engineering? Here's what I see in your example: - @ indicates built-in function, which avoids namespace collisions. - Optional types via the ?, which solves the null pointer problem. - Real iterators, which are less error-prone and nicer to read than traditional for loops in a lot of common applications. - The || syntax is better than something like `for (type var : array)` in Java, don't you think? Especially since it works with any iterator? - anyerror!void is a nice way of saying that the function can return an error. Remember that we don't have exceptions here. - It has interoperability with (multiple standards of) C. - Error handling is higher-level and less error-prone than in C without exceptions that can create hidden jumps in your code. So it clearly solves issues that people run into frequently in C. It brings in a nice sampling of high-level language features without doing anything that would compromise its niche as a systems language. It still has manual memory management and does not have exceptions. The behavior is simpler and requires that you language-lawyer the specification for undefined behavior far less often than in C. Your knowledge of C isn't necessarily enough to be able to immediately read Zig code, but that's because Zig isn't C. It's not hard to learn.
- kreco 7y ago
  Thanks for spending your time explaining this. I think a lof people will understand those lines better. I actually already knew everything. I watched closely the development of Zig, and just give up when I realized all those decisions where made carelessly in my view or I just simply disagree with the direction of the syntax. Since you took your time I will take mine to address what I don't like: - There is no way to write "int" by default. I understand why. But I don't agree. - struct and enum statements (within braces) are separated by a comma which is inconsistent with statements in function separated with ",". In my view expect a difference between parameters and statements. parameters (a,b,c) statement {a;b;c} - You have to type "var" or "const" everywhere, but not in struct statement and enum statement. Sometimes it's like a "def" sometimes not. - You have to type const when importing module: const std = @import("std"); // Why ? Why should I specify const, this should be inferred. Same when I define a struct. - the "undefined" keyword when it means "uninitialized" even in the documentation. var my_var: i32 = undefined; - The worst, no default values for struct. - The list of keywords is insane: errdefer, allowzero, orelse, unreachable, anyerror - About iterator I was doing well with: while(get_next(context, &item)) { /* ... */ } It's like everything has been carefully design to be even less readable than C code. I have the feeling that the syntax help more the compiler than de developer. I wish I could bet thousands of dollars that there will be only one compiler in the whole life of Zig language (also because it relies way too much to LLVM).