141–150 of 209 posts
Earlier quoted context omitted.
If you don’t have a result type then you don’t have better error handling!
Zig disagrees. Monads are cool and all, but we can do better than Result for error handling.
Earlier quoted context omitted.
I understand and agree, I've run many a Java project that used codegen to emit Protobuf/Avro IDLs as types. But Go having actual generics, and accordingly removing some need for codegen, is not a bad thing at all.
No, I do believe Go will be improved if it allows library maintainers to implement some things like new collection types and utilities using generics. I for one won't be using more advanced functional coding though, it's a lot more difficult to read / parse and the language is not designed with functional programming in mind. I'm sure people are already working on a functional programming library so you can do map /…
Earlier quoted context omitted.
> oh my god Definitely the correct response. Also, > c++ allows 0-width spaces in variable names. Where's your god now? Nowhere. We have strayed maximal distance from god's light and are currently in orbit around Satan.
> > c++ allows 0-width spaces in variable names. Is that true though ? > A valid identifier must begin with a non-digit character (Latin letter, underscore, or Unicode character of class XID_Start) and may contain non-digit characters, digits, and Unicode characters of class XID_Continue in non-initial positions. Identifiers are case-sensitive (lowercase and uppercase letters are distinct), and every character is sig…
This seems to be the only limitation for that to be true.
So the question is does 0-width space (U+200B) survive canonical decomposition, followed by canonical composition?
It feels like it does to me.
Earlier quoted context omitted.
> oh my god Definitely the correct response. Also, > c++ allows 0-width spaces in variable names. Where's your god now? Nowhere. We have strayed maximal distance from god's light and are currently in orbit around Satan.
> > c++ allows 0-width spaces in variable names. Is that true though ? > A valid identifier must begin with a non-digit character (Latin letter, underscore, or Unicode character of class XID_Start) and may contain non-digit characters, digits, and Unicode characters of class XID_Continue in non-initial positions. Identifiers are case-sensitive (lowercase and uppercase letters are distinct), and every character is sig…
Clang logs a warning about potentially invisible characters every time you use them. g++ just compiles the code without warning, even with -Wall and -Wpedantic.
What clang _doesn't_ warn for, is the use of the left-to-right override character. This can be used to confuse the victims of your code even more.
Earlier quoted context omitted.
Sigh. Go without generics was useful. We built useful things with it. Go with generics will continue to be useful, and it'll make it easier to build some things that were irritating to build earlier. The design of generics went though so many rounds of iteration and discussions to make sure it wasn't a detriment to the language - indeed you can build everything that Go has already been used to build without ever know…
That's an expected pivot. From "nobody needs generics" to "we absolutely needed 10 years to figure out the best way to do parametric polymorphism, which was already known for 35 years when the language was created". And of course in addition to that, there will probably be claims that "no one claimed that generics aren't needed". I'm glad that we have the archives to show that this isn't true, and it's a good thing t…
Please remember that this is a forum of a very big group of participants with varying points of view and resulting opinions.
Even if he was previously a person that said golang doesnt need generics, I struggle with your point of view. It seems you're of the opinion that nobody should be allowed to... change their opinion? Or at least has to be continuously told that they're dumb because they held an opinion that turned out to be incorrect? We're all people and make mistakes/have incorrect assumptions about topics, why not just accept that and move on?
You might want to refocus on what kind of person you want to be, because both of your comments come off as very hostile
Earlier quoted context omitted.
On the question of "what's this?": type ImmutableTreeListᐸElementTᐳ struct "If you look closely, those aren't angle brackets, they're characters from the Canadian Aboriginal Syllabics block, which are allowed in Go identifiers. From Go's perspective, that's just one long identifier." Simultaneously amusing and disturbing. Is there an award for which one might nominate this person?
I suppose there are many examples like this. Once I've copied a piece of code from SO but IntellijIDEA was warning me that the semicolon at the end of the line is not correct. Upon further investigation(I think IntelljIDEA reported Unicode value) I've found out that the 'semicolon' I copied is a Greek character that looks exactly like semicolon. I wonder how people on vim/emacs deal with situation like this.
Earlier quoted context omitted.
> It’s also extremely magical in that it needs special language-level support throughout in ways Result is not, but obviously that’s more of a matter of taste. That's a peculiar observation, it's like saying Rust's borrow checker is magical because it needs language-level support. I mean, that's the point. In any case re: zig error or rust's Result, I don't think either of us are discussing features and pros/cons, bu…
> That's a peculiar observation, it's like saying Rust's borrow checker is magical because it needs language-level support. I mean, that's the point. You can’t do borrow checking without language support (I think, at least not without a significantly more expressive type system) whereas Result is pretty much just a type, the features it uses are mostly non-exclusive, and those which are, are very much intended not to…
What you just described are error traces. They're generated by Zig auomatically for you, thanks also to the fact that errors are a special construct in the language.
Relevant langref passage:
https://ziglang.org/documentation/master/#Error-Return-Trace...
Earlier quoted context omitted.
> It’s also extremely magical in that it needs special language-level support throughout in ways Result is not, but obviously that’s more of a matter of taste. That's a peculiar observation, it's like saying Rust's borrow checker is magical because it needs language-level support. I mean, that's the point. In any case re: zig error or rust's Result, I don't think either of us are discussing features and pros/cons, bu…
> That's a peculiar observation, it's like saying Rust's borrow checker is magical because it needs language-level support. I mean, that's the point. You can’t do borrow checking without language support (I think, at least not without a significantly more expressive type system) whereas Result is pretty much just a type, the features it uses are mostly non-exclusive, and those which are, are very much intended not to…
Earlier quoted context omitted.
> How are you thinking of solving this with generics? People can now create Try or Option monads instead of returning the error. This was the one of the reasons anti generics people were anti generics
But that will make error handling more verbose.
But more verbose? I'm not so sure.
I'm glad that all the blog posts written by the apologetes and zealots, claiming that Go doesn't need generics and how they will actually be a detriment to the language, are archived somewhere in the wayback machines, so that they can't gaslight us into believing that they weren't just being silly for all this time.
Sigh. Go without generics was useful. We built useful things with it. Go with generics will continue to be useful, and it'll make it easier to build some things that were irritating to build earlier. The design of generics went though so many rounds of iteration and discussions to make sure it wasn't a detriment to the language - indeed you can build everything that Go has already been used to build without ever know…