241–250 of 526 posts
I wonder what makes someone go such a great length to bash a language, any language. I say bashing, because even the few valid points in the post are not written in a constructive style. After all is there a language that can't be criticised? Is the post written to make one feel better having a failed a project the language? (It's not me, it's the language) Or is it the failure to understand that not everyone thinks…
Earlier quoted context omitted.
Checked exceptions are more trouble than they're worth. That doesn't make exceptions in general bad.
What does make exceptions bad in my opinion (and shared by Go developers?) is a few things: 1. Exceptions are expensive (at least in Java / C#), as they generate a stack trace every time. Which is fine for actually exceptional situations, the equivalent of `panic()` in Go, but: 2. Exceptions are thrown for situations that are not exceptional, e.g. files that don't exist, database rows that don't exist, etc. Those are…
Ugh NO. Please don't. You should never "check if the file exists first". It can stop existing between your check and your later attempt at opening the file (the same with database rows). That can even lead to security issues. The name for that kind of programming mistake, as a vulnerability class, is TOCTOU (time-of-check to time-of-use).
The correct way is always to try to do the operation in a single step, and handle the "does not exist" error return, be it a traditional error return (negative result with errno as ENOENT), a sum type (either the result or an error), or an exception.
Earlier quoted context omitted.
Abort on the other hand is used WAY to liberally in Rust. How I hate it, that every second function call can break my program when it's clearly not a "halt the world, it's totally unrecoverable that the user sent us nonsense" type. Return a Result and get on with your life!
If a Rust function can panic, there's generally a non-panicking alternative. For example, `Vec` indexing has `vec[n]` as the panicking version and `vec.get(n)` as the version that can return `None` when there's nothing at that index.
Earlier quoted context omitted.
What does make exceptions bad in my opinion (and shared by Go developers?) is a few things: 1. Exceptions are expensive (at least in Java / C#), as they generate a stack trace every time. Which is fine for actually exceptional situations, the equivalent of `panic()` in Go, but: 2. Exceptions are thrown for situations that are not exceptional, e.g. files that don't exist, database rows that don't exist, etc. Those are…
> e.g. files that don't exist, database rows that don't exist, etc. [...] The workaround is defensive coding, check if the file exists first, check if the row exists? Ugh NO. Please don't. You should never "check if the file exists first". It can stop existing between your check and your later attempt at opening the file (the same with database rows). That can even lead to security issues. The name for that kind of p…
an exception is meant for EXCEPTIONAL behavior.
So it may be that the file access throws an exception but generally, I wouldn't agree.
Earlier quoted context omitted.
Bah, no, I hated that you had to wrap basically every code block in a try/catch in Java, because the underlying lib could change and suddenly throw a Runtime-Exception. At the same time Checked Exceptions were a nightmare as well, because suddenly they were part of the contract, even though maybe wrong later.
Checked exceptions are more trouble than they're worth. That doesn't make exceptions in general bad.
But then over in Java world, your checked exception paradise (which it of course isn't because the syntax and toolkit for managing the things is so clunky) is easily broken by the number of unchecked exceptions which could be thrown from anything at any time and break your code in unexpected and exciting ways, so not only do you have to deal with that system you also don't get any assurance that it's even worth doing.
But this doesn't actually mean checked exceptions are a bad idea, it means that Java didn't implement them very well (largely because it also has unchecked exceptions, and NullPointerException is unchecked because otherwise the burden of handling it would be hideous, but that comes down to reference types being nullable by default, which is a whole other barrel of pain they didn't have to do, and oh look, Go did the same thing wooo).
Rust and Go are very different and I feel people want a middle ground that just doesn't exist currently. A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc. Syntactically, Gleam and Kotlin come somewhat close but not really. I like Rust but I do believe it is too complicated for many people who are capable of creating some…
> A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc. You just described Ocaml and ReasonML (which is Ocaml with Go-like syntax).
Rust and Go are very different and I feel people want a middle ground that just doesn't exist currently. A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc. Syntactically, Gleam and Kotlin come somewhat close but not really. I like Rust but I do believe it is too complicated for many people who are capable of creating some…
Rust syntax, compiles to Go.
I find it fascinating the extent to which language choice makes a programmer emotional looking around at these comments.
Since this article was written Go introduced generics which does solve some of the complaints. The rest I mostly solve with linters, libraries, and conventions.
Go has a syntax that is well designed (arguably one of the best) if you’re aiming for familiarity with C style syntax in an imperative language. Other than that it’s a poorly designed language with by far the best engineering work having gone into things that aren’t actually the language per say (cross compilation, asynchronous runtime, GC, module system, super fast builds, etc). They wrote an ACM Queue article essentially stating that: https://cacm.acm.org/research/the-go-programming-language-an...
Not sure why Go is compared to Rust all the time, whilst most appropriate comparison is Java.
Go is an iteration of C, not of Java. It's a really bad choice for situations where Java is a good choice as not only is the language limited, the ecosystem around it is also very limited when compared to say Java. I'm maintaining Go, C# and TypeScript as my main languages as that gives me excellent coverage. I'll add Rust to the mix when I have 6 months where I can accept the productivity drop or have a project wher…
Someone please explain to me what's C-like about Go other than vaguely the syntax and that it compiles to machine code.