I wish Go had something like Ruff! A lot of languages are getting amazing tool but Go has a very fragmented ecosystem with a lot of tools but none of them feel as high quality has the likes of Ruff, Oxc, Biome or even PHP's Mago
It is fairly new so not well known but it is what powers go fix and go vet under the hood. And I believe the Go team is currently working on making it possible for module authors to easily describe their own custom analysis passes that would run automatically when running go fix.
It is extremely easy to define your own analysis.Analyzer struct that describes your own static analysis pass. You get access to all sorts of useful information such as the AST, types, even SSA info and you can even compose the information between analyzers. Then you can easily compile it into a binary and run it by passing that binary to go fix with a command line flag. The go toolchain itself handles all the complex caching logic so that your analyzers run fast.
Since it is made by the go team itself and part of the toolchain it should slowly become the unified standard you are looking for. So hopefully golangci-lint and others should eventually all unify under this framework.
You can easily give it a go by telling some AI agent to write some Go Analysis analyzers and telling them to drive them with go fix. My Go projects tend to accumulate a bunch of these to enforce all sorts of rules deterministically and automatically instead of some imprecise markdown file.
That sounds amazing! I do hope golangci-lint and the likes pick it up, I'm a big fan of the strict by default approach that Ruff and other linters have taken.
Gofmt is great but it's still not very strict, the amount of times my colleagues have argued about formatting in Go is still too great, stuff like consts, types, funcs, methods order, struct initialziation newlines and other details that do matter, but they should be decided one and then applied everywhere like that.
On problem of such go linters is they can only lint what the compiler sees so if you have multiple `build` tags, you need to run multiple lint passes. No other language's linter operates like they, they all operate on file level.
Yeah, that's how much Astral changed python. UV and Ruff are amazing tools.
Go can get there, but like I said, I think everyone is building some partial tools that solve some problems, but there is not that one player building that one great tool.
I’m not entirely sure what you mean by a fragmented ecosystem? Go has first-party formatting and linting and the language is deliberately restricted to ensure it is written in a certain way, even when written by complete novices.
Compare that to Python or TypeScript which are Wild West languages without opinionated first-party tooling, and it’s clear why Ruff/Biome feel great.
Go has a good start for that, but It's not enough for me.
Gofmt is a great idea but it isn't strict enough for my taste. Go does not have any first party static analyzers, closest is Staticcheck which is even sponsored by Google themselves
I don't believe you can add custom analyzers to `go vet`, which arguably rules it out.
But it is extremely simple to make a custom vet-like tool, because it's a trivial binary wrapper around the analysis framework, which is first-party (though it's structurally pretty limited by design, and won't handle all linting needs): https://cs.opensource.google/go/go/+/refs/tags/go1.26.5:src/...
I've been using golangci-lint for years, it's okay but it's slow even with a cache, as soon as you have good amount of lints enabled your ci can suddendly take minutes.
That's not the fault of golangci-lint, it's just the concept of bringing together a bunch of different linters and keeping it fast is impossible. And the configuration is a bit wild too, because every linter obviously has their own decisions on how it wants to be configured.
What? I feel go has one of the best language tooling out there without requiring a bully ide to do stuff. golangci-lint is quite comprehensive. What do you miss otherwise?
(Honestly go's distributing itself has covered a lot of it)
golangci-lint is good, but you have to glue together a bunch of linters, and it adds up. You can easily get runtimes of several minutes, there are caches etc but the main problem is that golangci-lint doesn't own the lints, so it will never be as fast as something like Ruff.
I have actually tried. But I'm not very knowledgable in the area, so it's more LLM slop than my good ideas. And I'm not sure I have the energy and passion to maintain it long term.
It's definitely possible, if Google would put like one or two smart minds on the problem full time they could easily solve this problem and make the ecosystem so much stronger. But I'm guessing they already have something like this in-house and no interest in open sourcing it.
I really didn't enjoy the cheap plastic construction of the Moonlander. I had two of them for home and work. I even modded a mousepad onto the wristrests to make it more comftable.
But in the end the housing being out of plastic, it creaked, wobbled and just was not satisfying to type on.
I came from premium mechnical keyboards with solid steel or aluminum construction.
I ended up with the Neo Ergo, a middle ground. Not as ergonomic, but solid feel, no plastic and great looks too.
Yea I used the kinesis 360 for a short time but couldn't stand how cheap it felt. Such a big difference from nicer custom keyboards, and it's essentially the same price which is a shame.
A custom one is worth it in my opinion. Mine feels quite nice. Not 100% of a gasket mount heavy keyboard, but pretty darn close. Took a while to find the switches that worked for me, but I love it. Also, I have lots of sound deadening in it that help make it feel and sound more solid.
But yeah, the stock browns are pretty bad and the plasticky case doesn't sound great stock.
You can keep "columnar" data in a row based database like postgres, it's just more expensive. But with little data that's fine and reduces infrastructural complexity. When you reach too much data it gets to a point where you then actually want to use the correct database for your usecase.
I just wish bind mounts would be more performant/native. I get that this is probably impossible, and probably also sucks on Linux, haven't tried.
But like having containers that need file watchers like vite dev server, or frankenphp in watch mode will overload OrbStack real quick since It seems to fallback to polling instead of listening to fs events.
So I'm stuck running vite dev servers and the like on the host.
Can you share more details? OrbStack has always supported inotify/fanotify (Linux fs watching APIs) on bind mounts and most people use watchers with no issues. Happy to look into whatever you're running into: danny@orbstack.dev
I'll remember it and email you when I try it again.
Last time I tried all of orbstack froze and I had to restart my whole mac to fix it. But you also did some recent releases that fix issues related to freezing up, so maybe it was unrelated.
Thanks for the great software! Happy enterprise customer
I agree. This thread is so negative, seeing everything black and white. 99% of the users of these tools are never going to bother trying to figure out how to remove synthId. And then for the small percentage that do bother, they would have the knowledge to usage image models that don't use watermarking in the first place.
reply