Can you explain how it's worse? For me, all algol/c family looks roughly the same, so I don't see how one is worse than the other. I guess zig does something quirky with how array, tuple, and struct can be created with .{}.
I see syntax comparison as very subjective. There's no one syntax that everyone will be happy about. So I'm just gonna ask what's the ideal syntax for you?
As someone coming from Java/C++98 things look off. .{} looks weird. So does .x. And ?[8]u32 looks like something written by a person that delved too deep into Bloodborne bosses. Not a fan of the \\ string syntax either, nor the lack of multiline comments.
That said these are my gut reactions. Nothing too special about being turned-off by a syntax. Many languages appear weird at first, but you get used to them.
There are literally tools written to explain C types because the syntax is that bad https://cdecl.org/
Compare:
char * const (*(* const bar)[5])(int )
(which cdecl explains as "declare bar as const pointer to array 5 of pointer to function (int) returning const pointer to char")
to Zig's:
const bar : *[5]fn(i32)const*u8
or Rust's:
let bar = &[fn(i32)->&u8; 5]
Note how the structure of the type nests nicely in both Zig and Rust, while C intentionally has it inside-out because "you declare it how you use it" or some other bullshit excuse that isn't actually true.
while C intentionally has it inside-out because "you declare it how you use it" or some other bullshit excuse that isn't actually true.
It's not important because it's highly subjective. I'm sure to a C programer first example reads perfectly fine, while others just look weird and wrong. In the same way, to a person who reads left-to-right, reading right-to-left is bizarre.
Arguing about what reads better in a programming language is about as valid as picking the color and placement of the bikeshed. As long as you don't place it inside the nuclear reactor (I'm looking at you APL), you're fine.
I dont think Zig syntax is superior to anything else and if you ask my personal preference is that i dont like to type or read it which is one of the reason i am no longer interested in the lang, not the only one but it matters
Not to mention that for me the "delimiter" forced by the compiler is also a syntax matter and well, i dont take well being forced to what to use, i dont really care at all spaces vs tabs but when it is mandatory yeah, not a nice move
I dont really understand the praise and love Zig syntax gets, i see much complex than what it needs to be and a general mess with no real benefit over the ones who use more chars but they are clearer and much more well thinked and designed
Preface: I don't understand much hype either. I don't quite get the Zig Coolaid.
But to be devil's advocate, there are a few things I can agree:
- .x makes it easy to see where .x is assigned, true. So would have using = as a special literal.
- and and or as syntax for && and || would have been my preference.
- I guess const raw = \\ string is a marked improvement over Rust's syntax.
I don't know. This whole blog post seems like a man with his language on a honeymoon phase. I've programmed for several years in Java, and the syntax is nothing to write home about but gets the job done.
If I may hypothesize for a bit. I think making a language whose syntax is ASCII only (God help you if you're writing UTF8 only syntax) with a limited number of sigils and limited mental bandwith of humans, you're bound to make compromises somewhere. Telling me syntax is lovely, is telling me you haven't been bitten by the wild edge cases of your languague - yet. As someone that used a language for every letter of the alphabet and then some, I can tell you they all have their bitey parts.
Preface: I don't understand much hype either. I don't quite get the Zig Coolaid.
Zig's primary value proposition is that it's for people who correctly identify that C sucks, but are broadly either too stupid or too stubborn to use Rust.
but are broadly either too stupid or too stubborn to use Rust.
That argument falls on its face because the author is well versed in Rust. He wrote Rust Analyzer when Rust LSP was a thing, and surpassed it in popularity.
Compared to Rust, Zig is great at few things: integrating with C, compilation speed and comptimes.
The assignment argument is strange. I have heard it where people say that:
x := 5
is better than
x = 5
The Io language used that, for assign-slot (:=) and updated-slot (=).
For some reason I found that languages just using =, say ruby or python,
make this much easier instead.
Rust has a pretty bad syntax too. I don't understand why the language designers there really care nothing at all about syntax. Syntax is not everything of course, but bad syntax is much easier to create than good one. Perl 5 shows this wildly.
For some reason I found that languages just using =, say ruby or python, make this much easier instead.
Easy isn't the be all end all. Easy means familiar. For people coming from Pascal := is easier than =. Because they can easily say this is asignment := and this is equality ==.
This also has the benefits of prevent errors. Famous C footgun goes like this
if (c = 0) {
puts("meow")
} else {
puts("will never happen");
}
Rust has a pretty bad syntax too. I don't understand why the language designers there really care nothing at all about syntax.
Or = is definition and equality while <- is assignment, if you're coming from an ML language background. Not that there's many low level languages with ML syntax... Or at least not until I finish mine lol.
OK I’ll bite, what makes you say that Rust’s syntax is “bad”? Don’t paste some horrible esoteric type declaration, the important bits are the ones you actually use.
Which i have to calm down and see what it is going on, starting from what i think is one of the biggest issue in Java syntax, the ))))) hell, where you have to start counting ( or ) to know what is where. And the whole line is just an "assert(type_of_foo.align(4))" to check that it is 4 bytes aligned
Can someone explain what it is going on? Because i have now to start from the end to make some sense, ok, i have a reference of something (foo) so this is must be a pointer or a reference to that. I have not deep down that much in Zig so this is my wild guess, i have the pointer to the first byte of that referenced foo. Do you think it is not complex or messy?
So i have a function derp that returns an i32, fine but i have to code in real code (not annotations like most other langs do) just to mark it to make sure that return variable it is 8 bytes aligned, if derp() had some arguments inside the ( ) hell will be there, having to look explicitely for where the arguments end and where the "metadata" starts
I am not bothering to put the line but i have no idea of what it is "*align(4)" that it is somewhere in the code, i guess it is just C style where in the end whatever it is created it is a pointer, or in other words * (align(4) + whatever else .... ) but it is again a guess
.
All that simpliciity in the end means harder to code and harder to read making code much more complex to what other langs do, when you start needing to use lang stuff in other than toy code things get messy really fast. When i read or code other better designed langs i dont have to pause and read carefully, it is really clear what it is going on, something that it is not the case with Zig
Not to mention that not everyone in the world uses a US layout keyboard, mine shares [] and {} in the same keys, if i press shift it is one and if i press the alt one the other (it is also a standard key) and @ is the same so i would prefer to type standard chars that i can withouth having to look at the keyboard even if it is longer than using that type of syntax based on special chars that i have to look to make sure i am pointing at the proper one
What about ASM? https://ziglang.org/documentation/master/#Assembly I dont think this is also nice or simple to do, the fact that Zig will refuse to make ASM for any other than AT&T x86 or 64 targets is another history. They are hardcoding asm structure in the lang, not all ASM are that way, i have not tried but if i want to use some SIMD ASM will this work? I dont know because since Zig docs are so poor i will have to figth my self to make it work and not for the moment but i am sure that propietary Intel or AMD ASM ones wont, stuff like AMX (or the NPU functions that are going to be everywhere soon) just will need NASM (or the one you like) as used to be the case. Not to mention that if at some point they decide to include ARM or RiscV targets ASM they will have to break compability or just have dedicated function to asm generation depending on the target, something the dev will have to handle himself, adding another complexity layer
Compare to Rust https://doc.rust-lang.org/rust-by-example/unsafe/asm.html#inputs-and-outputs is clear which one is easier and cleaner to use, i put exactly the memotechnic words of that ASM target and the compiler will transalte to the 0x__ code needed to be. It doesnt matter the op code, i can type whatever i want and at compile time it will check if the target have or not that op code, it is flexible and powerful while really easy to use
Now is time to return to that 0.1% of users, Zig is targeted as a better C (or C++ or Rust, it doesnt matter) and it is not a general programming lang, it is a sytem one which targets people that will deal with memory allocations (and alignement of memory since it is a must when you allocate yourself) or ASM as strong points since C, C++, Zig, Rust and others target performance over most other things. It makes sense that the "hardcode devs" are more than 0.1% of the users, at least in my view
I could buy the 0.1% arguement from Java, C#, Node and similar but not on a lang designed to that people, at least in theory
I have my doubts Zig can create ARM or any other architecture rather than x86 because they have hardcoded the structure and ASM dont work that way
Also it is on the docs
Next is the output. It is possible in the future Zig will support multiple outputs
So you can only use one returned value and only one, which is why AVX or any other SIMD dont work, at least i wasnt able to make it work and they do on Rust or with NASM + C++ so they should. Not to mention the 2 64 bits mul that of course failed if they overflow since i can only got the low register and never the high one, i can always do the mul twice and first get the low and then the high register but common...
Forcing AT&T ASM specs has as drawback that you cant use other, the % is not used in many others ASM and because it is hardcoded in the core part of the lang means that you have a real issue in your hands. I have a PI here with me so i am happy to being proved wrong, send some ARMv8 ASM code that i can try
LLVM does but not Zig since they have hardcoded the asm instructions structure means that other ASM that are not AT&T for x86 or 64 bits are not going to work unless they share the same specification which is not happening. It is there:
For x86 and x86_64 targets, the syntax is AT&T syntax, rather than the more popular Intel syntax. This is due to technical constraints; assembly parsing is provided by LLVM and its support for Intel syntax is buggy and not well tested
Which means that Intel ASM could work if they share the same structure as the AT&T which is a decent amount of then but if is not the case expect "buggy" or in other words, it is not going to work
So even if LLVM allows many targets the fact is that Zig dont and only work with one, the easier to handle
It does have section links: https://ziglang.org/documentation/master/#Comments
Hmm the issue here is that the language doc is full of snippets that you would never encounter in real code. All your examples are very unusual zig code. Not a good place to see what zig code looks like in practice.
This is type introspection, you almost never need to get the alignment of a pointer, if you often need it, make a function to get it. @alignOf() is available to get the alignment of a type.
*align(4) [1]u8
This is a 4 bytes aligned pointer, to an array of u8 of length 1.
The concept of this type itself is pretty messy, apart from that how it is written reads well to me.
fn derp() align(@sizeOf(usize) * 2) i32
Arguments are metadata as well, I don't really see what you mean by this. Here the function itself is aligned (the asm code of the function) it's a very very rare thing to want to do.
Wasn't OP's problem that they wanted to point to an array of const NoteEvents via a fat pointer to a slice of mutable NoteEvents? So the initial code was simply broken and therefore correctly failed to compile.
Yeah, that part seemed truly bizarre. And this stuff being some fringe feature aside:
It trades annoying indentation for annoying #. How would that be a net win?
It seems concerned about lexing single lines independent. All problems that could possibly solve (lexing performance, syntax highlighting broken off beyond a buffer window) are already solved by static data file inclusions. Which Zig has.
They won't be able to, because it's impossible in Zig to express that generic bound. Zig doesn't have anything like interfaces, and with comptime, while you can check the names and types of struct fields, for methods the best you can do is check that the method names match what you expect. You can't check method signatures, nor do you have any way to ensure that the type actually intends to implement this interface and doesn't just accidentally have the same method names.
You will get a compile error if a method doesn't exist or the signature doesn't match where the generic function tried to call it, but it's not as good as a properly defined interface where the error occurs at the call site of the generic function.
Zig also cannot express the lifetime bound 'static, which means that the type must not have any upper bound on its lifetime. In practice, this means that it owns all of its data, and doesn't contain any references with a non-'static lifetime.
Rust syntax tends to be information dense, I don't know how you would make this syntax any more clear without dropping out information or making it harder to read other than maybe move the generic contrains to it's own where block
pub fn new_with_client<C>(client: C) -> Self
where
C: 'static + CaClientTrait,
I feel like other "C replacement" languages do a better job at Syntax. Sometimes being more verbose actually is simpler to read and reason about. The main syntax issues from C that need resolving is the whole "declaration precedes use" concept that doesn't really work. I.e. declaring a pointer and dereferencing a pointer is the same syntax which can be confusing
shevy-java@reddit
The syntax seems to be worse than both C++ and C.
I don't understand why about 99% of the languages that try to replace C, end up with a worse syntax.
layaryerbakar@reddit
Can you explain how it's worse? For me, all algol/c family looks roughly the same, so I don't see how one is worse than the other. I guess zig does something quirky with how array, tuple, and struct can be created with
.{}.I see syntax comparison as very subjective. There's no one syntax that everyone will be happy about. So I'm just gonna ask what's the ideal syntax for you?
-Y0-@reddit
As someone coming from Java/C++98 things look off.
.{}looks weird. So does.x. And?[8]u32looks like something written by a person that delved too deep into Bloodborne bosses. Not a fan of the\\ stringsyntax either, nor the lack of multiline comments.That said these are my gut reactions. Nothing too special about being turned-off by a syntax. Many languages appear weird at first, but you get used to them.
TicklishPickleWikle@reddit
I agree but what's nice about the types is u can read them from left to right
complex C types are nontrivial to read but you could just put them behind a typedef
-Y0-@reddit
Honestly. That's a coping mechanism. Being readable is how people got into
dd/mm/yyyyversusmm/dd/yyyy.vytah@reddit
Nah, it's actually important.
There are literally tools written to explain C types because the syntax is that bad https://cdecl.org/
Compare:
(which cdecl explains as "declare bar as const pointer to array 5 of pointer to function (int) returning const pointer to char")
to Zig's:
or Rust's:
Note how the structure of the type nests nicely in both Zig and Rust, while C intentionally has it inside-out because "you declare it how you use it" or some other bullshit excuse that isn't actually true.
-Y0-@reddit
It's not important because it's highly subjective. I'm sure to a C programer first example reads perfectly fine, while others just look weird and wrong. In the same way, to a person who reads left-to-right, reading right-to-left is bizarre.
Arguing about what reads better in a programming language is about as valid as picking the color and placement of the bikeshed. As long as you don't place it inside the nuclear reactor (I'm looking at you APL), you're fine.
TicklishPickleWikle@reddit
this reply was basically "it aint that deep bro" lol
-Y0-@reddit
It's not just ain't deep, it's a discussion pit, everyone feels comfortable discussing it, and it has no clear answer.
You could discuss for decades which color of bikeshed looks best (or whether
:=or=are better assignment operators) and not have a clear winner.TicklishPickleWikle@reddit
it aint that deep bro
-Y0-@reddit
Neither is "it's readable, so it's a plus". You know what's also pretty readable - COBOL.
Uncaffeinated@reddit
I've seen a pretty wide variety of languages (C++, Java, Python, Rust, Ocaml, Haskell, etc.) and the
.{}still looks weird to me.TankAway7756@reddit
Of course things look off if you aren't used to them.
The eldritch abominations probably being any C type more complex than
*T.JuanAG@reddit
I dont think Zig syntax is superior to anything else and if you ask my personal preference is that i dont like to type or read it which is one of the reason i am no longer interested in the lang, not the only one but it matters
Not to mention that for me the "delimiter" forced by the compiler is also a syntax matter and well, i dont take well being forced to what to use, i dont really care at all spaces vs tabs but when it is mandatory yeah, not a nice move
I dont really understand the praise and love Zig syntax gets, i see much complex than what it needs to be and a general mess with no real benefit over the ones who use more chars but they are clearer and much more well thinked and designed
-Y0-@reddit
Preface: I don't understand much hype either. I don't quite get the Zig Coolaid.
But to be devil's advocate, there are a few things I can agree: -
.xmakes it easy to see where.xis assigned, true. So would have using=as a special literal. -andandoras syntax for&&and||would have been my preference. - I guessconst raw = \\ stringis a marked improvement over Rust's syntax.I don't know. This whole blog post seems like a man with his language on a honeymoon phase. I've programmed for several years in Java, and the syntax is nothing to write home about but gets the job done.
If I may hypothesize for a bit. I think making a language whose syntax is ASCII only (God help you if you're writing UTF8 only syntax) with a limited number of sigils and limited mental bandwith of humans, you're bound to make compromises somewhere. Telling me syntax is lovely, is telling me you haven't been bitten by the wild edge cases of your languague - yet. As someone that used a language for every letter of the alphabet and then some, I can tell you they all have their bitey parts.
levelstar01@reddit
Zig's primary value proposition is that it's for people who correctly identify that C sucks, but are broadly either too stupid or too stubborn to use Rust.
-Y0-@reddit
That argument falls on its face because the author is well versed in Rust. He wrote Rust Analyzer when Rust LSP was a thing, and surpassed it in popularity.
Compared to Rust, Zig is great at few things: integrating with C, compilation speed and comptimes.
shevy-java@reddit
The assignment argument is strange. I have heard it where people say that:
is better than
The Io language used that, for assign-slot (:=) and updated-slot (=).
For some reason I found that languages just using =, say ruby or python, make this much easier instead.
Rust has a pretty bad syntax too. I don't understand why the language designers there really care nothing at all about syntax. Syntax is not everything of course, but bad syntax is much easier to create than good one. Perl 5 shows this wildly.
-Y0-@reddit
Easy isn't the be all end all. Easy means familiar. For people coming from Pascal
:=is easier than=. Because they can easily say this is asignment:=and this is equality==.This also has the benefits of prevent errors. Famous C footgun goes like this
_Noreturn@reddit
you csn easily precent the above footgun by making = void statement
mot_hmry@reddit
Or
=is definition and equality while<-is assignment, if you're coming from an ML language background. Not that there's many low level languages with ML syntax... Or at least not until I finish mine lol.Ok-Armadillo-5634@reddit
It comes from algo used to be a ton of languages used :=
somebodddy@reddit
Not really, because they eliminate the syntactical distinction between definition and assignment - which is bad when scoping gets involved.
simonask_@reddit
OK I’ll bite, what makes you say that Rust’s syntax is “bad”? Don’t paste some horrible esoteric type declaration, the important bits are the ones you actually use.
Sharp_Fuel@reddit
I agree, find zigs syntax very disjointed Vs something simpler (yet maybe occasionally more verbose) like Odin
Pyrolistical@reddit
can you give an example where zig's syntax is much more complex than it needs to be?
JuanAG@reddit
That simplicity at first in the end means that you start having to handle that complexity yourself at read time or even coding
From test_variable_func_alignment.zig in https://ziglang.org/documentation/master/ (i would used the # of that section but Zig docs lacks any of that)
''' try expect(@typeInfo(@TypeOf(&foo)).pointer.alignment == 4); '''
Which i have to calm down and see what it is going on, starting from what i think is one of the biggest issue in Java syntax, the ))))) hell, where you have to start counting ( or ) to know what is where. And the whole line is just an "assert(type_of_foo.align(4))" to check that it is 4 bytes aligned
''' const as_pointer_to_array: *align(4) [1]u8 = &foo; '''
Can someone explain what it is going on? Because i have now to start from the end to make some sense, ok, i have a reference of something (foo) so this is must be a pointer or a reference to that. I have not deep down that much in Zig so this is my wild guess, i have the pointer to the first byte of that referenced foo. Do you think it is not complex or messy?
''' fn derp() align(@sizeOf(usize) * 2) i32 { return 1234; } '''
So i have a function derp that returns an i32, fine but i have to code in real code (not annotations like most other langs do) just to mark it to make sure that return variable it is 8 bytes aligned, if derp() had some arguments inside the ( ) hell will be there, having to look explicitely for where the arguments end and where the "metadata" starts
I am not bothering to put the line but i have no idea of what it is "*align(4)" that it is somewhere in the code, i guess it is just C style where in the end whatever it is created it is a pointer, or in other words * (align(4) + whatever else .... ) but it is again a guess
.
All that simpliciity in the end means harder to code and harder to read making code much more complex to what other langs do, when you start needing to use lang stuff in other than toy code things get messy really fast. When i read or code other better designed langs i dont have to pause and read carefully, it is really clear what it is going on, something that it is not the case with Zig
Not to mention that not everyone in the world uses a US layout keyboard, mine shares [] and {} in the same keys, if i press shift it is one and if i press the alt one the other (it is also a standard key) and @ is the same so i would prefer to type standard chars that i can withouth having to look at the keyboard even if it is longer than using that type of syntax based on special chars that i have to look to make sure i am pointing at the proper one
Pyrolistical@reddit
fair point on alignment. it is one of the ugliest thing. but it is also a niche feature that the vast majority of people never have to deal with.
so 0.1% of zig's syntax is ugly, but what about the rest?
JuanAG@reddit
Lets just say is just 0.1% of users, for now
What about ASM? https://ziglang.org/documentation/master/#Assembly I dont think this is also nice or simple to do, the fact that Zig will refuse to make ASM for any other than AT&T x86 or 64 targets is another history. They are hardcoding asm structure in the lang, not all ASM are that way, i have not tried but if i want to use some SIMD ASM will this work? I dont know because since Zig docs are so poor i will have to figth my self to make it work and not for the moment but i am sure that propietary Intel or AMD ASM ones wont, stuff like AMX (or the NPU functions that are going to be everywhere soon) just will need NASM (or the one you like) as used to be the case. Not to mention that if at some point they decide to include ARM or RiscV targets ASM they will have to break compability or just have dedicated function to asm generation depending on the target, something the dev will have to handle himself, adding another complexity layer
Compare to Rust https://doc.rust-lang.org/rust-by-example/unsafe/asm.html#inputs-and-outputs is clear which one is easier and cleaner to use, i put exactly the memotechnic words of that ASM target and the compiler will transalte to the 0x__ code needed to be. It doesnt matter the op code, i can type whatever i want and at compile time it will check if the target have or not that op code, it is flexible and powerful while really easy to use
Now is time to return to that 0.1% of users, Zig is targeted as a better C (or C++ or Rust, it doesnt matter) and it is not a general programming lang, it is a sytem one which targets people that will deal with memory allocations (and alignement of memory since it is a must when you allocate yourself) or ASM as strong points since C, C++, Zig, Rust and others target performance over most other things. It makes sense that the "hardcode devs" are more than 0.1% of the users, at least in my view
I could buy the 0.1% arguement from Java, C#, Node and similar but not on a lang designed to that people, at least in theory
funny_falcon@reddit
Zig reuses LLVM for ASM, so it certainly can ARM and RISCV. Nothing in documentation states it is limited to x86 and x86_64.
JuanAG@reddit
I have my doubts Zig can create ARM or any other architecture rather than x86 because they have hardcoded the structure and ASM dont work that way
Also it is on the docs
So you can only use one returned value and only one, which is why AVX or any other SIMD dont work, at least i wasnt able to make it work and they do on Rust or with NASM + C++ so they should. Not to mention the 2 64 bits mul that of course failed if they overflow since i can only got the low register and never the high one, i can always do the mul twice and first get the low and then the high register but common...
Forcing AT&T ASM specs has as drawback that you cant use other, the % is not used in many others ASM and because it is hardcoded in the core part of the lang means that you have a real issue in your hands. I have a PI here with me so i am happy to being proved wrong, send some ARMv8 ASM code that i can try
Sir_Factis@reddit
It does support ARM instruction set, it's all over their code base:
```
asm volatile (
\\ cbz w16, 8f
\\ .inst 0x08a07c41 + 0x00000000 + 0x000000
\\ ret
\\8:
\\ uxtb w16, w0
\\0:
\\ ldxrb w0, [x2]
\\ cmp w0, w16
\\ bne 1f
\\ stxrb w17, w1, [x2]
\\ cbnz w17, 0b
\\1:
\\ ret
:
: [__aarch64_have_lse_atomics] "{w16}" (__aarch64_have_lse_atomics),
: .{ .w15 = true, .w16 = true, .w17 = true, .memory = true });
```
JuanAG@reddit
LLVM does but not Zig since they have hardcoded the asm instructions structure means that other ASM that are not AT&T for x86 or 64 bits are not going to work unless they share the same specification which is not happening. It is there:
Which means that Intel ASM could work if they share the same structure as the AT&T which is a decent amount of then but if is not the case expect "buggy" or in other words, it is not going to work
So even if LLVM allows many targets the fact is that Zig dont and only work with one, the easier to handle
johan__A@reddit
It does have section links: https://ziglang.org/documentation/master/#Comments
Hmm the issue here is that the language doc is full of snippets that you would never encounter in real code. All your examples are very unusual zig code. Not a good place to see what zig code looks like in practice.
try expect(@typeInfo(@TypeOf(&foo)).pointer.alignment == 4);This is type introspection, you almost never need to get the alignment of a pointer, if you often need it, make a function to get it. @alignOf() is available to get the alignment of a type.
*align(4) [1]u8This is a 4 bytes aligned pointer, to an array of u8 of length 1.
The concept of this type itself is pretty messy, apart from that how it is written reads well to me.
fn derp() align(@sizeOf(usize) * 2) i32Arguments are metadata as well, I don't really see what you mean by this. Here the function itself is aligned (the asm code of the function) it's a very very rare thing to want to do.
JuanAG@reddit
So because it is rare to use something like this means that it is fine being complex or messy syntax?
Because i can use that syntax and if i need is the one i will have to use and for me is not easy or "lovely", it is messy and complex
Maykey@reddit
Array of structs, aka vomit of tokens
vytah@reddit
Wasn't OP's problem that they wanted to point to an array of const NoteEvents via a fat pointer to a slice of mutable NoteEvents? So the initial code was simply broken and therefore correctly failed to compile.
hammackj@reddit
Great points. I love rust and zig looks dumb to me not sure why. I have no idea why people hype this language at all.
jacobb11@reddit
And I stopped reading.
hissing-noise@reddit
Yeah, that part seemed truly bizarre. And this stuff being some fringe feature aside:
TemporalChill@reddit
Is the lovely syntax in the room with us right now?
TemporalChill@reddit
Is the lovely syntax in the room with us right now?
He's behind me, isn't he?
ldelossa@reddit
I like Zig syntax. Its small and easy to understand.
Rust fans will argue
Is somehow beautiful 😂
JuanAG@reddit
To make a fair comparation you should provide how it is the above done in Zig so people can compare, no?
MEaster@reddit
They won't be able to, because it's impossible in Zig to express that generic bound. Zig doesn't have anything like interfaces, and with comptime, while you can check the names and types of struct fields, for methods the best you can do is check that the method names match what you expect. You can't check method signatures, nor do you have any way to ensure that the type actually intends to implement this interface and doesn't just accidentally have the same method names.
You will get a compile error if a method doesn't exist or the signature doesn't match where the generic function tried to call it, but it's not as good as a properly defined interface where the error occurs at the call site of the generic function.
Zig also cannot express the lifetime bound
'static, which means that the type must not have any upper bound on its lifetime. In practice, this means that it owns all of its data, and doesn't contain any references with a non-'staticlifetime.vytah@reddit
Obligatory: https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html
juhotuho10@reddit
Rust syntax tends to be information dense, I don't know how you would make this syntax any more clear without dropping out information or making it harder to read other than maybe move the generic contrains to it's own where block
Sharp_Fuel@reddit
I feel like other "C replacement" languages do a better job at Syntax. Sometimes being more verbose actually is simpler to read and reason about. The main syntax issues from C that need resolving is the whole "declaration precedes use" concept that doesn't really work. I.e. declaring a pointer and dereferencing a pointer is the same syntax which can be confusing
Atulin@reddit
I kept reading it and 4jinking "ah, kinda like C# then?"