revive VS typescript-go

> Our coding standards require that functions have a fairly low cyclomatic complexity. The goal is to ensure that we never have a a function which is really hard to understand.

https://github.com/fzipp/gocyclo

> * We also require a properly descriptive header comment for each function and one of the main emphases in our code reviews is to evaluate the legibility and sensibility of each function signature very carefully. My thinking is the comment sort of describes "developer's intent" whereas the naming of everything in the signature should give you a strong indication of what the function really does.

https://github.com/mgechev/revive

> Now is this going to buy you good architecture for free, of course not.

It's not architecture to tell people to comment on their functions.

Also FTR, people confuse cyclomatic complexity for automagically making code confusing to the weirdest example I have ever had to deal with - a team had unilaterally decided that the 'else' keyword could never be used in code.

The Uber page does a pretty good job of summing it up. The only thing I'd add is that there has been a little bit of effort to reduce footguns since they've posted this article; as one example, the issue with accidentally capturing range for variables is now fixed in the language[1]. On top of having a built-in race detector since 1.1 and runtime concurrent map access detection since 1.6, Go is also adding more tools to make testing concurrent code easier, which should also help ensure potentially racy code is at least tested[2]. Accidentally capturing named return values is now caught by a popular linting tool[3]. There is also gVisor's checklocks analyzer, which, with the help of annotations, can catch many misuses of mutexes and data protected by mutexes[4]. (This would be a lot nicer as a language feature, but oh well.)

I don't know if I'd evangelize for adopting Go on the scale that Uber has: I think Go works best for shared-nothing architectures and gets gradually less compelling as you dig into more complex concurrency. That said, since Uber is an early adopter, there is a decent chance that what they have learned will help future organizations avoid repeating some of the same issues, via improvements to tooling and the language.

[1]: https://go.dev/blog/loopvar-preview

[2]: https://go.dev/blog/synctest

[3]: https://github.com/mgechev/revive/blob/HEAD/RULES_DESCRIPTIO...

[4]: https://pkg.go.dev/gvisor.dev/gvisor/tools/checklocks

The v1.3.4 of revive, the fast, configurable, extensible, flexible, and beautiful linter for Go, is available.

I would suggest checking out something like revive to improve the code. For instance you use an errors.New(fmt.Sprintf(... when you can just use fmt.Errorf(... to simplify it. I am not saying obey everything but there are some good lints included that can even catch bugs (for instance misusing errors.Is or errors.As or general equality).

Linting and static analysis: https://revive.run/

For people using this linter (like me) https://github.com/mgechev/revive

Been using https://github.com/mgechev/revive in all my projects.

The day after, I talked about the Hacktoberfest to Salvador (architect colleague and my technical/career unofficial mentor). He is known for contributing to revive a Golang linter. We decided that I could contribute by solving these 3 issues (2 new rules and add a docker image to the release). Since this moment, I have been coding every available hour I had. It felt so reviving to spend time coding on new projects, rewarding to solve issues for people actually using the tool. Here are all my contributions.

While golint may be deprecated it has been brought back as revive. You can also enable in golangci-lint.

The big names around are biome, oxc and an announced Microsoft-developed tsgo.

You didn't read the article. It wasn't a rewrite, it was a port.

https://github.com/microsoft/typescript-go/discussions/410

Here's the FAQs, where they explain the decision to go with Go and not, say, rust.

https://github.com/microsoft/typescript-go/discussions/categ...

First of all, the original TypeScript compiler under the hood is moving in the new version 7 from JavaScript to Go. That is, there will be conditionally TypeScript 6 (JS) and TypeScript 7 (Go). This was done mainly because of the scaling problem when used in very large projects, but also, of course, because of the speed.

Since you wrote this it looks like [Anders replied](https://github.com/microsoft/typescript-go/discussions/411#d...) to one of the threads.

I have to agree with the sentiment that is a success story that the team is allowed to use the best tool for the job, even if it suffers from "not built here".

This is really healthy and encouraging to see in these large OSS corporate-sponsored projects, so kudos to you and the team for making the pragmatic choice.