vscode-gremlins VS proposal

Visuo studio has a plugin for detecting those invisible characters. https://github.com/nhoizey/vscode-gremlins You should look for one for your IDE.

PHPStorm detects \u3164 "HANGUL FILLER" but VS Code does not. I tried using the Gremlins plugin, but looks like it currently doesn't detect this confusable. Is there any alternative plugin or setting in VS code to help detect these characters?

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

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

One of the big reasons that the try proposal ( https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md ) was abandoned is that people felt that simply returning without handling errors is't enough for such a language feature to be added.

Not to detract from your general point, but I believe that this specific situation was addresses in Go 1.18's GC pacer rework: https://github.com/golang/proposal/blob/master/design/44167-....

Go is not quite doing this level of expansion: https://github.com/golang/proposal/blob/master/design/generi...

In particular, a single expansion is shared for all pointer types.

It’s not a satisfying answer, but the truth is that there just isn’t that much Go code out there suffering from a lack of the kind of basic generics being introduced. It exists, but it’s not the norm.

Instead, what is likely to happen is, a lot of problems that generics can be applied to, they more often will be, simply because the option is on the table, regardless of whether it really improves anything. Go taught me to stop worrying and trust the For loop, and now we’re probably going to have dozens of utility libraries with Map and Reduce routines that people will use for extremely simple loops that don’t need them, probably resulting in slower code that takes longer to compile that needs a slower and more complicated optimizer to make up for it. In my opinion, the antithesis of what makes Go great.

Not saying generics is all bad, or that reduce is bad, or anything like that. But once a programming language has a new way to do something, you can be damn well sure people will use it, often even to their own disadvantage. Go doesn’t have pattern matching control flow, so the best degree of soundness you can pull out of an Optional type is ugly visitor-pattern type interaction. And yet, I’m worried routines will superfluously return Optional types anyways, just because you can, even though it’s not really any better than just returning a type and a boolean.

And yes. Actual code that actually needs generics for real will benefit, undeniably. Data structure and generic algorithm implementations will benefit greatly. The ugly sort package can finally be cleaned up. That’s great. But, most Go programs simply aren’t suffering from a lack of basic generics. Operative words: most, and basic generics. Many programs simply don’t need any data structures other than a basic growable vector type and a basic hashtable, and Go has both and they are built-in and work generically. Yet the more complex problems that C++ templates and Rust generics solve will probably not be aided at all by Go generics, which are simply much more limited in scope.

And despite that, this is quite an increase in compiler complexity. I know many are thinking “how hard could it be? Tons of languages do it today”—but Go isn’t really like all of the other languages. The simpler compiler is a huge benefit to the compiler and the whole ecosystem. Arguably, Go’s simplicity enabled them to experiment with things that wouldn’t be very easy to do in other languages, with regards to its GC and threading model. They’ve got it figured out of course, but it really isn’t a simple walk in the park. Any single aspect has a lot going on:

https://github.com/golang/proposal/blob/master/design/generi...

My hope is that the relatively mature ecosystem of Go will somewhat encourage people to keep their code simple and use generics sparingly, but with such a major shift in the language it’s hard to imagine what is “idiomatic” won’t change over time. I feel Go’s brutalist simplicity is its strong point and that it will just be an inferior option if you try to write code in it like C++ or Rust.

Of course… we’ll see.

I thought this was something like traits, but it goes way beyond that.

Sub-dictionaries are described here: https://github.com/golang/proposal/blob/master/design/generi...

It looks like the compiler needs to walk down the entire call tree from the top-level generic and then compute new dictionaries for each called function. Since the compiler may not know the entire call tree, it may have to build nested dictionaries.

Wacky stuff!

I'm afraid that this initial implementation strategy impacts too much the runtime speed and people will get the wrong conclusions. If I'm not mistaken they are doing work for 1.19 according to the other implementation model: https://github.com/golang/proposal/blob/master/design/generics-implementation-stenciling.md that should have little to no impact on runtime but increase the compile time.