251–260 of 559 posts
Earlier quoted context omitted.
The huge volume of boilerplate makes the code harder to read, and annoying to write. I like go, and I don’t want exceptions persay, but I would love something that cuts out all the repetitive noise.
The example in the article is a good one. Result and Optional as first class sum types
Great! Something I've always wanted. I'd love to be able to use a bit more type-y Go such as Borgo, and have a Pythonesque dynamic scripting language that latches onto it effortlessly. Dynamic typing is great for exploratory work, whether that's ML research or developing new features for a web app. But it would be great to be able to morph it over time into a more specified strongly typed language without having to r…
The larger problem is building an ecosystem and a stdlib that's written in python, not C. Use ffi or similar instead of C-API.
This addresses pretty much all of my least favorite things with writing Go code at work, and I hope--at the very least--the overwhelming positivity (by HN standards -- even considering the typical Rust bias!) of the responses inspires Go maintainers to consider/prioritize some of these features, or renews the authors interest in working on the project (as some have commented, it seems to have gone without activity fo…
Earlier quoted context omitted.
An Enum type has to be on the core Go team's radar by now. It's got to be tied with a try/catch block in terms of requested features at this point (now that we have generics).
I am so tired of reading Java/C++/Python code that just slaps try/catch around several lines. To some it might seem annoying to actually think about errors and error handling line by line, but for whoever tries to debug or refactor it's a godsend. Where I work, try/catch for more than one call that can throw an exception or including arbitrary lines that don't throw the caught exception, is a code smell. So when I lo…
It's the best strategy for short running programs, or scripts if you will. You just write code without thinking about error handling at all. If anything goes wrong at runtime, the program aborts with a stacktrace, which is exactly you want and you get it for free.
For long-running programs you want reliability, which implies the need to think about and explicitly handle each possible error condition, making exceptions a subpar choice.
Earlier quoted context omitted.
I am so tired of reading Java/C++/Python code that just slaps try/catch around several lines. To some it might seem annoying to actually think about errors and error handling line by line, but for whoever tries to debug or refactor it's a godsend. Where I work, try/catch for more than one call that can throw an exception or including arbitrary lines that don't throw the caught exception, is a code smell. So when I lo…
>the error handling was one of the many positive features. sounds good on paper, but seeing "if err!=nil" repeated million times in golang codebases does not create positive impression at all
Earlier quoted context omitted.
The example in the article is a good one. Result and Optional as first class sum types
That just changes the boilerplate from if's to match's.
The main benefits of a Result type are brevity and the inability to accidentally not handle an error.
Earlier quoted context omitted.
> are not as performant as Go. Ymmv, you might be surprised if you actually bothered to benchmark. Depending on the workload, either JS or erlang can ultimately turn out on top. They're all optimized to a degree that each has a niche it excells at and leaves the others in the dust. even with heavily scewed benchmark like techempower fortunes ( https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s... ) you end…
Well hold on a second. The JS impl that you're talking about uses a minimal custom runtime ( https://github.com/just-js/just ) that you would never use—it barely implements JS. It's basically only used for this benchmark. It doesn't make sense to compare that to Go when we're talking about Javascript vs. Go performance. Scroll down to the "nodejs" entry for a more realistic comparison.
I'm not saying that JS is "just as fast as golang" generally. My argument is specifically that it's optimized to a degree that there are cases in which JS, an interpreted language, does end up on top.
The same applies to erlang and it's optimization for efficient concurrency.
On average you'll likely get better performance with go, but depending on the workload the results can differ
Earlier quoted context omitted.
I am so tired of reading Java/C++/Python code that just slaps try/catch around several lines. To some it might seem annoying to actually think about errors and error handling line by line, but for whoever tries to debug or refactor it's a godsend. Where I work, try/catch for more than one call that can throw an exception or including arbitrary lines that don't throw the caught exception, is a code smell. So when I lo…
Yes, it's the ability to unwind the stack to an exception handler without having to propagate errors manually. Go programs end up doing the exact same thing as "try/catch around multiple lines" with functions that can return an error from any point, and every caller blindly propagating the error up the stack. The practice is so common that it's like semicolons in Java or C, it just becomes noise that you gloss over.
Earlier quoted context omitted.
No one wants try/catch/exception in Go.
Let’s hope Go never gets try/catch exceptions
func try(fn func()) { fn() }
func catch(fn func(any)) {
if v := recover(); v != nil {
fn(v)
}
}
func throw(v any) { panic(v) }
func fail() {
throw("Bad things have happened")
}
func main() {
try(func() {
defer catch(func(v any) {
fmt.Println(v)
})
fail()
})
}
This looks like an interesting sweet spot. Rust is often praised for the borrow checker, but honestly I really only like rust for the type system and error handling. Go is praised for it's simplicity, but hated for it's error handling.