Comment by jaytaylor | Hacker News Reader

Comment by jaytaylor | Hacker News Reader

    type Ordered interface {
        Integer|Float|~string
    }

I kind of despise the keyword / syntax design choice of the tilde (~) signifying "anything where the underlying type is e.g. a string".

Usually a ~ signifies a bitwise-NOT operation*.

It reminds me of something more like a Ruby design mentality, where optimizing for code terseness is chosen. The nice thing about the crazy syntax in Ryby is that at least the chosen symbol is unique and doesn't conflict with meaning in other similar languages.

I realize the context where it's used is not part of the logic-execution pipeline, but it still forces me to contort my mind and special case this concept, and map it against what is effectively a namespace collision between Go and other C-style languages.

Naturally it's too late for Go (Generics are fully baked and released), but would have been nice to land with something more intuitive or at least less collision-prone, even if only to avoid the ambiguity.

Inevitably, the introduction of generics means increased opportunities for new kinds of complexity, and this choice needlessly increases the cognitive load when trying to read and reason about a go program.

I know it's the the end of the world, but I find it somewhat of a bummer for a technology I was previously so enthusiastic about.

* edit: Thank you Jtsummers for the correction- it is bitwise-NOT, I had mistakenly written bitwise-OR.

> Usually a ~ signifies a bitwise-OR operation.

That sounded wrong to me, I recalled it being a NOT, and double checked. Turns out my recollection was correct (it's also not something I ever used much), it is the bitwise-NOT in C.

That actually makes it a bit more awkward, in my mind, as I initially parsed the example as "not string". However, ~ is also often used to mean "about" or "approximately". In a text exchange:

"How many people will be at dinner?"

"~5"

Meaning "about 5 people" or "approximately 5 people". So this also works in that sense, ~string can be read as "something in the neighborhood of a string" or "something like a string".

https://en.wikipedia.org/wiki/Bitwise_operations_in_C

~ is the similarity sign as mathematical symbols.

Agreed, this is a slightly better way to think about it, yet still seems out of place for Go. Where else does Golang diverge from what an operator means in C?

For one, in the operator in question: bitwise negation in Go is expressed using prefix ^ rather than ~ as in C. Go also differs from C in operator precedence, which I would argue is a significantly larger change than the visible syntax for an operator.

++ and -- are also statements rather than expressions (and =, but lots of languages diverge from C on this).

Well, * can already mean any of "pointer to" (in type context), "dereference" (as a unary prefix operator) or "multiplication" (as a binary operator)...

> Usually a ~ signifies a bitwise-NOT operation*.

Only in expression context. C doesn't assign any meaning to ~ in type definition context, nor does it have an existing way to represent the concept of "any type reducible to X". Since it doesn't diverge from C in either syntactic or semantic meanings when considering context, I don't see this being an issue in practice. Any potential confusion argument you can lay onto ~ could also be used against |, but I don't see any mention of that being a problem.

I can't "disagree" with your reaction -- that would be silly even if I wanted to -- but I claim that you would likely stop suffering from increased mental effort as you read and write this syntax over time.

If you ask most programmer, ~ is definitely not a bitwise-NOT operation.

It's the bitwise-NOT operator in C, java, and python just off the top of my head, I think most people are familiar with it

In Go we use ^ for bitwise-NOT.

Surely that is xor? Ah I looked it up and it is xor, but unary ^ is NOT. Interesting overloading.

Reply on news.ycombinator.com