vscode-gremlins VS proposal

Compare vscode-gremlins vs proposal and see what are their differences.

vscode-gremlins

Gremlins tracker for Visual Studio Code: reveals invisible whitespace and other annoying characters (by nhoizey)

proposal

Go Project Design Documents (by golang)
Our great sponsors
  • Appwrite - The Open Source Firebase alternative introduces iOS support
  • Scout APM - Less time debugging, more time building
  • SonarLint - Deliver Cleaner and Safer Code - Right in Your IDE of Choice!
vscode-gremlins proposal
3 33
145 2,891
- 1.7%
6.8 7.3
14 days ago 9 days ago
JavaScript Go
GNU General Public License v3.0 or later GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.

vscode-gremlins

Posts with mentions or reviews of vscode-gremlins. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-02-23.

proposal

Posts with mentions or reviews of proposal. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-04-29.
  • Lies we tell ourselves to keep using Golang
    13 projects | reddit.com/r/programming | 29 Apr 2022
    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.
  • Generics can make your Go code slower
    6 projects | news.ycombinator.com | 30 Mar 2022
    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 1.18 Released
    20 projects | news.ycombinator.com | 15 Mar 2022
    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.

    20 projects | news.ycombinator.com | 15 Mar 2022
    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.

  • Go 1.18中是如何实现泛型的? (How generics are implemented in Go 1.18)
    1 project | reddit.com/r/hnzh | 1 Mar 2022
  • How generics are implemented in Go 1.18
    1 project | reddit.com/r/WhileTrueCode | 1 Mar 2022
    1 project | reddit.com/r/hackernews | 1 Mar 2022
    5 projects | news.ycombinator.com | 1 Mar 2022
    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!

  • Go 1.18 Implementation of Generics via Dictionaries and Gcshape Stenciling
    2 projects | reddit.com/r/golang | 1 Mar 2022
    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.
    2 projects | reddit.com/r/golang | 1 Mar 2022

What are some alternatives?

When comparing vscode-gremlins and proposal you can also consider the following projects:

go - The Go programming language

awesome-vscode - 🎨 A curated list of delightful VS Code packages and resources.

zio-prelude - A lightweight, distinctly Scala take on functional abstractions, with tight ZIO integration

vscode-javascript-extensions - VS Code extension examples written in in JavaScript

golang-set - A simple generic set type for the Go language. Trusted by Docker, 1Password, Ethereum and Hashicorp.

Discord-Tools - VSCode extension allowing the integration of a Discord chat, bot templates, snippets, themes and more!

go-generic-optional - Implementation of Optionals in Go using Generics

go_chainable - With generics, allowing chainable .Map(func(...)).Reduce(func(...)) syntax in go

Nim - Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).

genny - Elegant generics for Go