llgo
nilaway
| llgo | nilaway | |
|---|---|---|
| 2 | 3 | |
| 1,238 | 2,774 | |
| - | 4.4% | |
| 0.0 | 8.7 | |
| over 9 years ago | 6 days ago | |
| Go | Go | |
| GNU General Public License v3.0 or later | Apache License 2.0 |
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.
llgo
-
Go: What We Got Right, What We Got Wrong
> And of course, today there is an LLVM-hosted compiler for Go, and many others, as there should be.
Isn't that the dead llgo effort?
https://github.com/go-llvm/llgo (now archived)
Its readme points to a dead link on the LLVM website, and it looks like there's no matching Go project under the LLVM org.
Does anyone know if there really is still a working LLVM based Go toolchain (other than TinyGo)?
-
What's the State of Alternate Compilers?
llgo https://github.com/go-llvm/llgo
nilaway
-
Go: What We Got Right, What We Got Wrong
I would have more respect if they at least admitted to the flawed type system but instead say it is not a problem. It is disappointing to see past mistakes repeated in a new programming language. Even the Java language creator was humble enough to admit fault for the null pointer problem. The Go devs do not have such humility.
https://github.com/uber-go/nilaway
-
Practical nil panic detection for Go
We'd be interested in the general characteristics of the most common ones you are seeing. If you have a chance to file a couple issues (and haven't done so yet): https://github.com/uber-go/nilaway/issues
We definitely have gotten some useful reports there already since the blog post!
We are aware of a number of sources of false positives and actively trying to drive them down (prioritizing the patterns that are common in our codebase, but very much interested in making the tool useful to others too!).
Some sources of false positives are fundamental (any non-trivial type system will forbid some programs which are otherwise safe in ways that can't be proven statically), others need complex in-development features for the tool to understand (e.g. contacts, such as "foo(...) returns nil iff its third argument is nil"), and some are just a matter of adding a library model or similar small change and we just haven't run into it ourselves.
What are some alternatives?
android-go - The android-go project provides a platform for writing native Android apps in Go programming language.
reviewdog - 🐶 Automated code review tool integrated with any code analysis tools regardless of programming language
gopherjs - A compiler from Go to JavaScript for running Go code in a browser
syft - CLI tool and library for generating a Software Bill of Materials from container images and filesystems
tardisgo - Golang->Haxe->CPP/CSharp/Java/JavaScript transpiler
go - The Go programming language
f4go - Transpiling fortran code to golang code
grype - A vulnerability scanner for container images and filesystems
c4go - Transpiling C code to Go code
tfsec - Security scanner for your Terraform code
esp32-transpiler - Transpile Golang into Arduino code to use fully automated testing at your IoT projects.
clair - Vulnerability Static Analysis for Containers