Relying on Go
Conversation activity · last 3 days peak 3/hr
Clustered from 16 items across 2 sources. Not yet parsed — the coverage below is the raw record.
Social posts 2
Voices from the web unedited
-
> All Solod code is translated to regular C11 and then compiled with GCC or Clang. Solod therefore relies on C tooling and decades of optimization work just as much as on Go's. This is an interesting choice. Personally, I view Go's build pipeline as one of its best selling points. I love how I can take a Go project and build a static binary for…
-
Yeah this is a bizarre direction. Go is a crappy language (with some neat tricks), on a good runtime. That's why there are many attempts to "TypeScript" Go by writing a superset with extra features that compiles to plain Go. To have to write in a *subset* of Go to make an eventual C compiler happy... oof why?
-
> To have to write in a subset of Go to make an eventual C compiler happy... oof why? I feel like if you have to ask, you're probably not in the target audience :-) But there's been [many stories posted](https://lobste.rs/domains/antonz.org) about Solod these last few months, in particular [this announcement](https://antonz.org/solod/) with their…
-
One of Go's biggest wins for many (not all) people is its simplicity. Some people like the direct, imperative style without too many frills, while still being able to handle concurrency in a reasonable manner (or, at least, a more reasonable manner than Python, say). That said, there are languages that target Go…
-
Just anecdotal evidence from my side but while a Go programs memory consumption might be higher than something written in a low-level non-GC language, I still haven't encountered a single Go program that uses nearly as much memory as an equivalent Java program. Quite the opposite is true in my experience.
-
> I love how I can take a Go project and build a static binary for every major platform with no difficulty, and without having to worry about the C stdlib's platform differences. C lovers can find this in the Zig toolchain.
-
My main grievances with Go as a language are (in order): 1. lack of semantics for controlling allocations--you have to try to guess and check about what the escape analyzer will do 2. No const generic type parameters 3. No sum types, emulating them is clumsy, verbose, error prone, and performance tradeoffs aren't great 4. Would like more const…
-
Obviously, those who think "Go is a crappy language" won't need this, but those who love Go as a language would appreciate being able to write software in it for the things they can't use the Go runtime. There's nothing bizarre in this direction.
-
I assume the GP was being a bit hyperbolic but as a refugee from Java there is almost no comparison. The Go runtime is a blessing, the Java runtime is a curse.
-
My biggest grievance by far has always been the awful error handling. "But errors as values bro!" Yes errors as values are great but Go is terrible at it. I love how Zig handles it including syntax for all the cases of null, undefined, and errors, and bubbling up an error (try) without a bunch of manual error checks that the Go compiler doesn't…