What I really like about Zig is its C compatibility story, which you mentioned. I would love to see some blog posts about how that works (as I understand it, Zig depends on the Clang front end.)
(I’m working on Oil, which likewise goes to great lengths to be compatible with the existing ecosystem, which I think most languages don’t focus enough on. C linkage doesn’t cut it IMO.)
I wasn’t as big a fan of the “perfect code” angle. It felt a bit unrealistic. Is the Zig compiler perfect code? It depends on LLVM so probably not? That doesn’t mean it isn’t very high quality. The overcommit discussion at the very beginning felt like a distraction.
Anyway, that’s just my feedback on how to “market” the language. Unfortunately it looks like everyone got caught up in a tabs vs. spaces discussion, which was not entirely unpredictable :-)
Congrats on all the progress! I’m looking forward to learning more about Zig.
Nothing’s wrong with it. All I meant to say was, if someone couldn’t find examples maybe it could be made clearer where to find them. By “design” I didn’t mean just the CSS.
Disallowing tabs seems rather silly. As far as I can tell, zig syntax does not depend on indentation (like, for example haskell or perhaps python), so there seems to be no technical reason for this. Appeals to simplicity seem unfounded, since tooling can just as easily ignore two characters as one.
I really don’t understand why tabs are so disliked: Guido allegedly said it was one of the mistakes he did in Python (tabs for indentation), so Nim did that. And now I sadly realise Zig too (but not for the same reasons). Tabs are used to align to columns, have a width that can be adjusted in most editors, and prevent errors of adding extra spaces. What’s not to like there?
I personally like the ASCII tab character in my file(s) but I take a pragmatic approach anymore, as long as the file is consistent, I could care less. But let’s face it, the ASCII tab character people have basically lost the war, and we should move on and embrace our new ASCII 9 free world.
Because it’s the defacto standard for the language. You run gofmt on your code, and move along with your life. basically ALL Go code is formatted with gofmt and if it isn’t you are very much in the minority. So it’s ended the war in Go-lang before it ever started, for the most part. I’m sure there are a few wacky places that refuse to use gofmt for one reason or another. I’ve never bothered to check, but I’d bet well over 90% use gofmt, making it a non-issue in Go lang. There is no war in Golang, you use gofmt, and you forget about the problem and spend energy on other things.
Other languages with formatters , if they get built early enough get the same benefits.
Not according to Silicon Valley (the show ;). I complain but I did the exact opposite in languages I’ve written: tabs are mandatory for indentation. Writing the grammars, I liked the fact that there was only one way to indent, and as a user that this would let me adjusted the indentation at will without changing the contents of the file.
Should I have used couldn’t care less in writing here; arguably yes, since it works much better in written form, and definitely in formal settings, however I tend to type as I speak, especially in non-formal places like here; hence my use of the phrase “I could care less”.
Anyways, this is pretty much WAY off topic. If you still feel very, very strongly that I’m wrong, you can message/email me privately, or you can call into: https://www.waywordradio.org/ who may put your complaint on the air and say a few things about it’s history, usage, and if they agree with you or not. I’ll happily bow to their wisdom.
is reasonable, IMO. The one thing I like about Go is gofmt; I don’t want to argue about style, waste time on it in code review, or think about it really.
Then why does Zig have a sort of half-way approach to this sort of thing? The official style guide says they are “are not enforced by the compiler, but… [are] a point of reference.” I think it’s strange to leave most of your style up for interpretation and and enforce the most controversial element in the compiler.
Pretend tabs are only 1 character then. The only thing the compiler has to do is be consistent with the editor (so the programmer can find the error). Vim shows the number of columns by both logical and visual characters, and presumably other editors do as well.
The whole Zig mantra and philosophy is that edge cases matter and to be explicit about handling them - It can work, I’m just explaining why it is not what Zig does.
Explicitly requiring formatting and ignoring are two different things, and that sort of “well what about” reasoning seems like a weak argument without the bug tracker where I saw it was under discussion.
What I really like about Zig is its C compatibility story, which you mentioned. I would love to see some blog posts about how that works (as I understand it, Zig depends on the Clang front end.)
(I’m working on Oil, which likewise goes to great lengths to be compatible with the existing ecosystem, which I think most languages don’t focus enough on. C linkage doesn’t cut it IMO.)
I wasn’t as big a fan of the “perfect code” angle. It felt a bit unrealistic. Is the Zig compiler perfect code? It depends on LLVM so probably not? That doesn’t mean it isn’t very high quality. The overcommit discussion at the very beginning felt like a distraction.
Anyway, that’s just my feedback on how to “market” the language. Unfortunately it looks like everyone got caught up in a tabs vs. spaces discussion, which was not entirely unpredictable :-)
Congrats on all the progress! I’m looking forward to learning more about Zig.
Really wish this had example programs on the page or just something I could see without watching a video.
https://ziglang.org/documentation/master/
Looks like a design bug for @andrewrk (or someone) to fix :-)
What’s wrong with minimal (or no) design? It’s fully functional as is.
Nothing’s wrong with it. All I meant to say was, if someone couldn’t find examples maybe it could be made clearer where to find them. By “design” I didn’t mean just the CSS.
Disallowing tabs seems rather silly. As far as I can tell, zig syntax does not depend on indentation (like, for example haskell or perhaps python), so there seems to be no technical reason for this. Appeals to simplicity seem unfounded, since tooling can just as easily ignore two characters as one.
I really don’t understand why tabs are so disliked: Guido allegedly said it was one of the mistakes he did in Python (tabs for indentation), so Nim did that. And now I sadly realise Zig too (but not for the same reasons). Tabs are used to align to columns, have a width that can be adjusted in most editors, and prevent errors of adding extra spaces. What’s not to like there?
I personally like the ASCII tab character in my file(s) but I take a pragmatic approach anymore, as long as the file is consistent, I could care less. But let’s face it, the ASCII tab character people have basically lost the war, and we should move on and embrace our new ASCII 9 free world.
see: https://www.jwz.org/doc/tabs-vs-spaces.html
Apparently not. At the very least there is a substantial portion of developers who use tabs.
Yeah, for example, pretty much everyone when writing in Go. All Go style guides use tabs and Gofmt always formats as tabs.
I was actually convinced by this post back in 2012 :)
AWESOME, but mostly, I just want the stupid war to be over. This is why I support tools like gofmt, yapf and friends, who make it a non-issue.
Gofmt uses tabs, so I don’t see how it helps ending any “war.”
Because it’s the defacto standard for the language. You run gofmt on your code, and move along with your life. basically ALL Go code is formatted with gofmt and if it isn’t you are very much in the minority. So it’s ended the war in Go-lang before it ever started, for the most part. I’m sure there are a few wacky places that refuse to use gofmt for one reason or another. I’ve never bothered to check, but I’d bet well over 90% use gofmt, making it a non-issue in Go lang. There is no war in Golang, you use gofmt, and you forget about the problem and spend energy on other things.
Other languages with formatters , if they get built early enough get the same benefits.
Not according to Silicon Valley (the show ;). I complain but I did the exact opposite in languages I’ve written: tabs are mandatory for indentation. Writing the grammars, I liked the fact that there was only one way to indent, and as a user that this would let me adjusted the indentation at will without changing the contents of the file.
“could care less” should be “couldn’t care less” . The expression means you care so little that caring more is impossible.
Logically you are absolutely 100% correct, however English is not very logical in many, many ways: http://www.slate.com/blogs/lexicon_valley/2016/04/05/the_real_reason_people_say_i_could_care_less.html
Should I have used couldn’t care less in writing here; arguably yes, since it works much better in written form, and definitely in formal settings, however I tend to type as I speak, especially in non-formal places like here; hence my use of the phrase “I could care less”.
Anyways, this is pretty much WAY off topic. If you still feel very, very strongly that I’m wrong, you can message/email me privately, or you can call into: https://www.waywordradio.org/ who may put your complaint on the air and say a few things about it’s history, usage, and if they agree with you or not. I’ll happily bow to their wisdom.
The rationale given in that issue,
is reasonable, IMO. The one thing I like about Go is
gofmt; I don’t want to argue about style, waste time on it in code review, or think about it really.Then why does Zig have a sort of half-way approach to this sort of thing? The official style guide says they are “are not enforced by the compiler, but… [are] a point of reference.” I think it’s strange to leave most of your style up for interpretation and and enforce the most controversial element in the compiler.
I can’t answer that. 🙂 I was merely commenting on what I saw in the issue. It does talk about a
zig fmttool in future tense, though.I agree it’s strange to enforce a few bits in the compiler.
Its about making column numbers in compiler errors consistent.
Pretend tabs are only 1 character then. The only thing the compiler has to do is be consistent with the editor (so the programmer can find the error). Vim shows the number of columns by both logical and visual characters, and presumably other editors do as well.
“presumably” and “pretend” are not serious solutions.
Sure they are. Operating systems pretend they have infinite memory. Presumably most editors can convert line endings.
And in this specific case all you have to do is always treat a tab as one character.
The whole Zig mantra and philosophy is that edge cases matter and to be explicit about handling them - It can work, I’m just explaining why it is not what Zig does.
I mean, in this case I think ignoring CRLF is a pretty big edge case.
Explicitly requiring formatting and ignoring are two different things, and that sort of “well what about” reasoning seems like a weak argument without the bug tracker where I saw it was under discussion.
This is a real problem. Rust “solves” this by always replacing tabs with 4 spaces in compiler errors, which is kind of silly.
Where did you get that shirt?
AndreaOrru made a one-off design and gifted it to me.