proposal
Gin
proposal | Gin | |
---|---|---|
46 | 152 | |
3,290 | 75,577 | |
0.4% | 0.8% | |
4.4 | 8.5 | |
about 2 months ago | 4 days ago | |
Go | Go | |
BSD 3-clause "New" or "Revised" License | MIT License |
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.
proposal
-
Does Go Have Subtyping?
The conclusion is pretty weird to me.
Go does rely on monomorphization for generics, just like C++ and Rust. The only difference is that this is an implementation detail, so Go can group multiple monomorphizations without worrying about anything else [1]. This form of hybrid monomorphization is being increasingly common, GHC does that and Rust is also trying to do so [2], so nothing special for Go here.
On the other hand, explaining variance as a lifted polymorphism is---while not incorrect per se---also weird in part because a lack of variance is at worst just an annoyance. You can always make an adopter to unify heterogeneous types. Rust calls it `Box`, Go happens to call it an interface type instead. Both languages even do not allow heterogeneous concrete (or runtime) types in a single slice! So variance has no use in both languages because no concrete types are eligible for variance anyway.
I think the conclusion got weird because the term "subtyping" is being misused. Subtyping, in the broadest sense, is just a non-trivial type relation. Many languages thus have a multiple notion of subtyping, often (almost) identical to each other but sometimes not. Go in particular has a lot of them, and even some relation like "T implements U" is a straightforward record subtyping. It is no surprise that the non-uniform value representation has the largest influence, and only monomorphization schemes and hetero-to-homogeneous adapters vary in this particular group.
[1] https://github.com/golang/proposal/blob/master/design/generi...
[2] https://rust-lang.github.io/compiler-team/working-groups/pol...
- Backward Compatibility, Go 1.21, and Go 2
-
Defining interfaces in C++ with ‘concepts’ (C++20)
https://github.com/golang/proposal/blob/master/design/generi...
-
Why Turborepo is migrating from Go to Rust – Vercel
Go Team wanted generics since the start. It was always a problem implementing them without severely hurting compile time and creating compilation bloat. Rust chose to ignore this problem, by relying on LLVM backend for optimizations and dead code elimination.
-
Are you a real programmer if you use VS Code? No Says OP in the byte sized drama
Hold up, did the members actually push this forward or was support just often memed about and suddenly this proposal was made: https://github.com/golang/proposal/blob/master/design/43651-type-parameters.md
-
Major standard library changes in Go 1.20
As far as I can tell, the consensus for generics was "it will happen, but we really want to get this right, and it's taking time."
I know some people did the knee-jerk attacks like "Go sucks, it should have had generics long ago" or "Go is fine, it doesn't need generics". I don't think we ever needed to take those attitudes seriously.
> Will error handling be overhauled or not?
Error handling is a thorny issue. It's the biggest complaint people have about Go, but I don't think that exceptions are obviously better, and the discriminated unions that power errors in Rust and some other languages are conspicuously absent from Go. So you end up with a bunch of different proposals for Go error handling that are either too radical or little more than syntactic sugar. The syntactic sugar proposals leave much to be desired. It looks like people are slowly grinding through these proposals until one is found with the right balance to it.
I honestly don't know what kind of changes to error handling would appear in Go 2 if/when it lands, and I think the only reasonable answer right now is "wait and find out". You can see a more reasonable proposal here:
https://github.com/golang/proposal/blob/master/design/go2dra...
Characterizing it as a "lack of vision" does not seem fair here--I started using Rust back in the days when boxed pointers had ~ on them, and it seemed like it took Rust a lot of iterations to get to the current design. Which is fine. I am also never quite sure what is going to get added to future versions of C#.
I am also not quite sure why Go gets so much hate on Hacker News--as far as I can tell, people have more or less given up on criticizing Java and C# (it's not like they've ossified), and C++ is enough of a dumpster fire that it seems gauche to point it out.
-
Go's Future v2 and Go's Versioning
There will almost certainly not be a Go 2 in that sense. There is a Go 2 transition doc which extensively discusses what "Go 2" means. The conclusion is
-
What's the status of the various "Go 2" proposals?
As it says on that page - those were not proposals. They were draft ideas to get feedback on. You can see the list of proposals in this repository: https://github.com/golang/proposal
-
An alternative memory limiter for Go based on GC tuning and request throttling
Approximately a year ago we faced with a necessity of limiting Go runtime memory consumption and started work on our own memory limiter. At the same time, Michael Knyszek published his well-known proposal. Now we have our own implementation quite similar to what has been released in 1.18, but there are two key differences:
- Shaving 40% off Google’s B-Tree Implementation with Go Generics
Gin
-
How to Build and Document a Go REST API with Gin and Go-Swagger
Now let’s define the functions that will be called whenever a request hits our API. All the functions will be referencing the context provided by the Gin web framework. Paste the following code below the sample slice we just added to api.go:
-
Password-less Login in Go from Scratch
We will be using Gorilla Mux. As per their last update, they have a new group of maintainers, and their repos have shown activity to confirm that. The tutorial can be easily replicated in any other framework or library as well. So, while we will be using Gorilla Mux, you can try to replicate it in Gin or Fiber as well.
- Autenticação com Golang e AWS Cognito
-
Implementing JWT Authentication in a Golang Application
Now, let's dive into the fun part – creating our basic ToDo application using the powerful Gin framework. This section will walk you through the steps, breaking down the code into manageable snippets.
-
Build a Serverless GenAI solution with Lambda, DynamoDB, LangChain and Amazon Bedrock
Thanks to the AWS Lambda Web Adapter, the application built as a (good old) REST/HTTP API using a familiar library (in this case, Gin.
-
From Django or Flask to Sponge: How to Easily Develop High-Performance Web Services with Golang
Excellent Performance: Sponge is built on the gin framework, providing outstanding performance for web service development.
-
Uploading and Serving Images from MongoDB in Golang
In this blog, we will delve into the fascinating realm of handling images in a Golang application, leveraging the power of the Gin framework for RESTful API development, MongoDB as a robust NoSQL database, and the mongo-driver library for seamless interaction with MongoDB. To store images efficiently, we'll explore the intricacies of GridFS, a specification within MongoDB for storing large files as separate chunks.
-
Building RESTful API with Hexagonal Architecture in Go
It uses Gin as the HTTP framework and PostgreSQL as the database with pgx as the driver and Squirrel as the query builder. It also utilizes Redis as the caching layer with go-redis as the client.
-
Different CORS settings for different paths?
I have created an application with Go in Gin-Gonic. In my frontend (Nuxt3/TypeScript) I always get a CORS error:
-
Rapid Prototyping of Design-First APIs in Go
We use Gin web framework https://gin-gonic.com for the routing, Gin provides a balance between performance, ease of use and extensibility making it a preferred choice for building and running web applications in Go.
What are some alternatives?
go - The Go programming language
Fiber - ⚡️ Express inspired web framework written in Go
vscode-gremlins - Gremlins tracker for Visual Studio Code: reveals invisible whitespace and other annoying characters
mux - A powerful HTTP router and URL matcher for building Go web servers with 🦍
avendish - declarative polyamorous cross-system intermedia objects
chi - lightweight, idiomatic and composable router for building Go HTTP services
too-many-lists - Learn Rust by writing Entirely Too Many linked lists
Echo - High performance, minimalist Go web framework
go-generic-optional - Implementation of Optionals in Go using Generics
Beego - beego is an open-source, high-performance web framework for the Go programming language.
go_chainable - With generics, allowing chainable .Map(func(...)).Reduce(func(...)) syntax in go
Iris - The fastest HTTP/2 Go Web Framework. New, modern and easy to learn. Fast development with Code you control. Unbeatable cost-performance ratio :rocket: