

-
> I cannot conceive of the scenario where it makes sense to recover a bounds-checking induced panic.
A bog-standard HTTP server (or likely any kind of request-serving daemon). If a client causes a bounds-checking panic, I do not want that to crash the entire server.
It's not even really particular to bounds-checking. If I push a change that causes a nil pointer dereference on a particular handler, I would vastly prefer that it 500's those specific requests rather than crashing the entire server every time it happens.
The Go HTTP server does this internally (though there is talk about not doing it, deferred til Go 2 https://github.com/golang/go/issues/5465).
> The process should crash; the alternative is to continue operating in an unknown, irrecoverable, and potentially security compromised state.
The goroutine should probably crash, but that doesn't necessarily imply that the entire program should crash. For some applications the process and the goroutine are one and the same, but that's not universally true. A lot of applications have some kind of request scope where it's desirable to be able to crash the thread a request is running on without crashing the entire server.
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
Rust shares Go's "errors as values + panics" philosophy. Rust also has a standard library API for catching panics. Its addition was controversial, but there are two major cases that were specifically enumerated as reasons to add this API: https://github.com/rust-lang/rfcs/blob/master/text/1236-stab...
> It is currently defined as undefined behavior to have a Rust program panic across an FFI boundary. For example if C calls into Rust and Rust panics, then this is undefined behavior. Being able to catch a panic will allow writing C APIs in Rust that do not risk aborting the process they are embedded into.
> Abstractions like thread pools want to catch the panics of tasks being run instead of having the thread torn down (and having to spawn a new thread).
The latter has a few other similar examples, like say, a web server that wants to protect against user code bringing the entire system down.
That said, for various reasons, you don't see catch_unwind used in Rust very often. These are very limited cases.
-
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
-
https://github.com/evcxr/evcxr can run Rust in a Jupyter notebook. It's not Golang but close enough.
-
https://github.com/gopherdata/gophernotes
I've had this bookmarked for some time and just havent gotten around to it.
-
Gitea
Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
-
> 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)?
-
Nutrient
Nutrient – The #1 PDF SDK Library, trusted by 10K+ developers. Other PDF SDKs promise a lot - then break. Laggy scrolling, poor mobile UX, tons of bugs, and lack of support cost you endless frustrations. Nutrient’s SDK handles billion-page workloads - so you don’t have to debug PDFs. Used by ~1 billion end users in more than 150 different countries.
-
Niklaus Wirth, rest his soul, would disagree.
Like would the the selling USB Armory, with Go written firmware.
https://www.withsecure.com/en/solutions/innovative-security-...
Back in my day, writing compilers and OS services were also systems programming.
-
Not sure these are really popular, but I cannot resist advertising a few utilities written in Go that I regularly use in my daily workflow:
- gdu: a NCDU clone, much faster on SSD mounts [1]
- duf: a `df` clone with a nicer interface [2]
- massren: a `vidir` clone (simpler to use but with fewer options) [3]
- gotop: a `top` clone [4]
- micro: a nice TUI editor [5]
Building this kind of tools in Go makes sense, as the executables are statically compiled and are thus easy to install on remote servers.
[1]: https://github.com/dundee/gdu
[2]: https://github.com/muesli/duf
[3]: https://github.com/laurent22/massren
[4]: https://github.com/xxxserxxx/gotop
[5]: https://github.com/zyedidia/micro
-
Not sure these are really popular, but I cannot resist advertising a few utilities written in Go that I regularly use in my daily workflow:
- gdu: a NCDU clone, much faster on SSD mounts [1]
- duf: a `df` clone with a nicer interface [2]
- massren: a `vidir` clone (simpler to use but with fewer options) [3]
- gotop: a `top` clone [4]
- micro: a nice TUI editor [5]
Building this kind of tools in Go makes sense, as the executables are statically compiled and are thus easy to install on remote servers.
[1]: https://github.com/dundee/gdu
[2]: https://github.com/muesli/duf
[3]: https://github.com/laurent22/massren
[4]: https://github.com/xxxserxxx/gotop
[5]: https://github.com/zyedidia/micro
-
Not sure these are really popular, but I cannot resist advertising a few utilities written in Go that I regularly use in my daily workflow:
- gdu: a NCDU clone, much faster on SSD mounts [1]
- duf: a `df` clone with a nicer interface [2]
- massren: a `vidir` clone (simpler to use but with fewer options) [3]
- gotop: a `top` clone [4]
- micro: a nice TUI editor [5]
Building this kind of tools in Go makes sense, as the executables are statically compiled and are thus easy to install on remote servers.
[1]: https://github.com/dundee/gdu
[2]: https://github.com/muesli/duf
[3]: https://github.com/laurent22/massren
[4]: https://github.com/xxxserxxx/gotop
[5]: https://github.com/zyedidia/micro
-
Not sure these are really popular, but I cannot resist advertising a few utilities written in Go that I regularly use in my daily workflow:
- gdu: a NCDU clone, much faster on SSD mounts [1]
- duf: a `df` clone with a nicer interface [2]
- massren: a `vidir` clone (simpler to use but with fewer options) [3]
- gotop: a `top` clone [4]
- micro: a nice TUI editor [5]
Building this kind of tools in Go makes sense, as the executables are statically compiled and are thus easy to install on remote servers.
[1]: https://github.com/dundee/gdu
[2]: https://github.com/muesli/duf
[3]: https://github.com/laurent22/massren
[4]: https://github.com/xxxserxxx/gotop
[5]: https://github.com/zyedidia/micro
-
Not sure these are really popular, but I cannot resist advertising a few utilities written in Go that I regularly use in my daily workflow:
- gdu: a NCDU clone, much faster on SSD mounts [1]
- duf: a `df` clone with a nicer interface [2]
- massren: a `vidir` clone (simpler to use but with fewer options) [3]
- gotop: a `top` clone [4]
- micro: a nice TUI editor [5]
Building this kind of tools in Go makes sense, as the executables are statically compiled and are thus easy to install on remote servers.
[1]: https://github.com/dundee/gdu
[2]: https://github.com/muesli/duf
[3]: https://github.com/laurent22/massren
[4]: https://github.com/xxxserxxx/gotop
[5]: https://github.com/zyedidia/micro
-
Yes. There are long standing feature requests for (e.g.) the reflect package that simply don't get done because they'd break this assumption and/or force further indirection in hot paths to support "no code generation at runtime, ever".
Packages like Yaegi (that offers an interpreted Go REPL) have "know limitations, won't be addressed" also because of these assumptions.
https://github.com/golang/go/issues/4146
https://github.com/golang/go/issues/16522
https://github.com/traefik/yaegi?tab=readme-ov-file#limitati...
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives