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?

That's the kind of thing you see in a comment and then back slowly out of the room, never breaking eye contact with the code until you are far enough away to turn tail and run.

At the very least they could have used the cute Japanese 「quotation marks」 to avoid confusion.

This is the person you need. Be assured that they were the person willing to log into the live prod server to fix that script that was killing your startups app at 2am on a Friday night in 2007 when everyone else was too gun-shy.

> 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.

Bow to the One whose Name cannot be expressed in the Basic Multilingual Plane

> > 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 significant. Every identifier must conform Normalization Form C.

I don't know about the standard, but both GCC and Clang accept ZWSP characters in the middle of variable names.

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.

> every character is significant. Every identifier must conform Normalization Form C.

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.

I'm dying. This is hilarious.

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.

It's similar when online editors try to be clever and replace a straight " with a fancy one (like in Word), really annoying.

That's why Powershell actually recognizes those fancy quotes and treats those as normal quotes.

So one Microsoft product contains an automatic workaround for an issue created by another Microsoft product.

On VSCode, I use the Gremlins extension which highlight all those suspicious characters.

https://github.com/nhoizey/vscode-gremlins

Pressing ga in command mode in Vim displays the ASCII / Unicode value of the character under the cursor.

Yes, but IntelljIDEA's Linter showed me the error. Without linter you'll need compiler/interpreter to tell you something is not right.

And in my case, even if compiler / interpreter reported about an invalid syntax - I would not think of checking the unicode codepoint as it the character appeared to look exactly like semicolon.

The rust compiler warns when it encounters confusable symbols like that. Not sure about other languages.

vim user here. Most of us are running the same linters and language servers as every other major editor, which does a pretty good job catching stuff like this. Modern vim is really only a C core with a web of JS, Python, Lua, and vimscript using the exact same third party solutions for every other part of an "IDE". emacs is probably similar, but no personal experience with that.

Java Certified Professional

Canadians now roll with the term Indigenous instead of Aboriginal

That may be, but in this case it is a precise technical term, referring to a particular block of Unicode: https://en.m.wikipedia.org/wiki/Unified_Canadian_Aboriginal_...

Maybe the Unicode Consortium should change it, but for now, Canadian Aboriginal is the correct term.

In 10 years a new word may become fashionable. Better to keep technical terms the same.

It's not about fashion, it's about cultural identity. I take it you don't see a problem with master/slave either?

Just do a find and replace, refactoring is easy and trying to argue on the internet about it is tiring.

I take it you didn’t grow up in the 80s. Trends in words change: you’ll see it with your own eyes.

> trying to argue on the internet about it is tiring.

… exactly.

If identity is about appearance, that would seem to admit fashion for consideration.

Colloquially in the north "native" is ubiquitous.

For now...

I love the reply: “c++ allows zero width spaces in variable names. where’s your god now?”

Fixed in C++23 by adoption of P1949R7 [0], which didn't originally set out to fix that, but seems to have after a Netherlands national body ballot comment.

[0] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p194...

I once read a comment like "Gives a new meaning to the term native code".

I'm actually curious if Go would normalize the characters AND if it had used angle bracketd, and make those equivalent to angle brackets? Would he then not have to even change his code?

I guess that's a lot of ifs/ands but it's interesting that one could have future proofed their code if their bet on syntax paid off

They're semantically different characters and Go supports multilingual identifiers, so I would not expect normalization to impact this. At most I would expect normalization to simply deal with ordering combining marks and standardizing on composed or decomposed forms of characters (where applicable.)

This got me curious what I'd read about domain names and visual normalization of Unicode, and found this: http://www.unicode.org/Public/security/revision-05/confusabl...

It might be useful for editors and compilers to check for tricky Unicode (lookalikes for common characters, atypical changes in direction, invisible spaces or other formatting control codes, etc.) in this era of copy/paste coding.

I believe Rust will warn you if your non-ASCII identifiers are potentially confusing based on this list.

It's funny how codegen has become widespread in Golang to work around its deficiency.

Codegen is a super flexible and versatile tool, and simply having a strong generics feature does not mean you can avoid it: at $DAYJOB we use codegen even for C++ for e.g. grpc/openapi types, generating rapidjson streaming unmarshallers, etc not even counting Qt's moc/uic.

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 / reduce / filter and the like, but readability and performance will be dreadful.

Strongly agree. Some people like to be on this endless treadmill of cutting edge features, like in this case parametric polymorphism but I refuse to be dragged in. They just make the code more complex with no benefit.

Next thing you know they will try to force me into structured programming (I'm sure there are people already working on do...while). They can pry goto from my dead cold hands.

Look, I'd just kill for a generic Set, tbh.

I've come to prefer code quantity over code complexity. I mean, what the fuck is

    def traverseImpl[F[_], A, B](fa: Option[A])(f: A => F[B])(implicit F: Applicative[F]) =
      fa map (a => F.map(f(a))(Some(_): Option[B])) getOrElse F.point(None)

This is probably less readable than it has to be due to the lack of whitespace. I don't know the language (Scala?), but I don't think it's too hard to work it out. First, the '[F[_], A, B]' part are type parameters, where I assume the 'F[_]' part is just a bad notation for a type of kind '* -> *' (i.e. a higher-ranked type). The next value parameter has type 'Option[A]', and after that we have 'A => F[B]'. This confirms my suspicion that 'F' is a higher-ranked type - and probably a functor or something. The 'f' parameter is a function for converting a value of type 'A' into a value of type 'F[b]', which looks like it's tranforming a value and putting it into a functor or something. The final '(implicit F: Applicative[F])' hints at deep problems in the language, but I think it basically just says something like 'the higher-rank type F must implement the trait/typeclass/whatever Applicative'.

That's the type. The expression makes little sense to me, but I suspect you removed a bunch of dots and maybe some parens, and it should actually look like this:

          fa.map (a => F.map(f(a))(Some(_): Option[B])).getOrElse(F.point(None))

So this function essentially just operates on an option value inside of some functorial context. This seems like a building block function that you might use often, but probably not write very frequently.

(If you didn't remove anything, then I suppose this language has infix 'map' and 'getOrElse' operators. I think that's bad, but it's not related to the type system.)

scala has infix everything ‘operators’. f(x) can be written as f x and f.g(x) can be written as f g x if the parser manages to figure out what it means (I’m sure they phrase that differently)

Idea, I think, is to make the repl look more like a CLI, but it also may be a fight against punctuation.

Its only hard to read because you don't know the language, otherwise, its fairly straightforward. Although the Applicative type would require some research. I would much rather use a language like this, that can create enough abstraction to enforce consistency throughout the codebase, rather than relying on boilerplate conventions. Just had a bug this week in Go where a previously defined "err" variable was re-used instead of creating yet another "err" variable, which caused the actual error never to get checked.

This function is certainly hairy, but its use in the codebase might very well be intuitive and simplify code that would otherwise be way less expressive. I personally think it can be worth it.

Transform fa using f, collecting the results as an option

What is funny about it? People have worked around deficiency of systems since forever in almost every field. Is it something you have never seen in real life?

C++ and Java also used codegen before they got templates and generics respectively, but since Go's matra is to relearn history, they had to have a go at it.

S̷͕͂̒c̴͉͈̆ŕ̶̘͚̄e̸̘̽̌ͅa̵̼̳͌m̷̬̓̈́͜s̴͙͆ ̸̨͓̾̈́i̴͈̼͐ņ̶̟̊̍ ̵͍̐̊Ű̸̪̤n̴̪̝̅̍i̶̜͌c̷͎̩̑̀ỏ̶̜͊d̴̟̎͠e̴̘̿

Oh gosh oh gosh zaglo variables please no

HE COMES

The syntax the OP gave reference to has nothing to do with how generics in Go 1.18 will look like.

If you are interested in generics in Go 1.18 please read https://go.googlesource.com/proposal/+/refs/heads/master/des...

Oh my god.