websocket VS gomock

Aria is a lightweight, event-driven WebSocket framework for Go. It is inspired by olahol/melody and built on top of coder/websocket.

As a regular Go user, I agree with this take. Though the tools exist, error wrapping and checking (with errors.Is and so on) is actually pretty rare in my experience.

Positive example of good and appropriate usage here: https://github.com/coder/websocket/blob/master/internal/exam...

Websocket

In my experience Go has been relatively approachable for people that are good at PHP. It has a great standard library and a pretty solid ecosystem, though frameworks aren’t as popular in Go. There are some well regarded libraries for things like WebRTC via https://github.com/pion/webrtc WebSicket via https://github.com/nhooyr/websocket

Also take a look at https://github.com/nhooyr/websocket - which is a good ws library, but I don't have anything specific about its memory usage per connection. But from what I see it will be somewhat similar to x/net/websocket.

nhooyr/websocket, shollz/pake, charmbracelet/bubbles, charmbracelet/bubbletea, charmbracelet/lipgloss, muesli/reflow, klauspost/pgzip and many, many more.

link: https://github.com/nhooyr/websocket

The commit mentions this rather sad thread: https://github.com/golang/mock/pull/627#issuecomment-1605169...

IDE: use whatever make you productive. I personally use vscode. VCS: git, as golang communities use github heavily as base for many libraries. AFAIK Linter: use staticcheck for linting as it looks like mostly used linting tool in go, supported by many also. In Vscode it will be recommended once you install go plugin. Libraries/Framework: actually the standard libraries already included many things you need, decent enough for your day-to-day development cycles(e.g. `net/http`). But here are things for extra: - Struct fields validator: validator - Http server lib: chi router , httprouter , fasthttp (for non standard http implementations, but fast) - Web Framework: echo , gin , fiber , beego , etc - Http client lib: most already covered by stdlib(net/http), so you rarely need extra lib for this, but if you really need some are: resty - CLI: cobra - Config: godotenv , viper - DB Drivers: sqlx , postgre , sqlite , mysql - nosql: redis , mongodb , elasticsearch - ORM: gorm , entgo , sqlc(codegen) - JS Transpiler: gopherjs - GUI: fyne - grpc: grpc - logging: zerolog - test: testify , gomock , dockertest - and many others you can find here

Normally I like to generate everything with Mockgen and test it using table driven test.

Looking at gomock's commit history, it seems like there hasn't been much activity on the project in a couple of years. I'm wondering if this is the case of software being mostly done and just in maintenance mode, or if gomock is falling behind. The reason I fear for the latter is there are still issues being opened up that don't seem to be engaged very much.

Yeah, that would work just fine. Nevertheless, as your business logic gets more complicated, you will want to test more scenarios and mocks will get complicated fast. In these cases tools like gomock really shine and make your life easier. I understand that this is a just-for-fun project, but it's never too early to experiment with a popular solution, especially if you plan on using Go professionally in the future.

Unit tests are leveraged to test individual units of code. As such it is not recommended for a developer to scaffold entire dependencies for the sake of testing a single object. Due to the way Go's specific implementations work, I've learned over time to declare interfaces for a lot of the structs that I use in Go. Interfaces not only define a contract for which struct-based implementations should adhere, but they also provide a mechanism for which struct methods can be mocked. While I've experimented with the mock package in testify, I've come to prefer the mock functionality which is provided by mockgen.