231–240 of 243 posts
Earlier quoted context omitted.
The conversation around Go on HN is as broken as a political discussion on Facebook. It’s pathetic.
I think “go haters” bring up plenty of valid points, unlike.. unfortunately any discussion on facebook.
Earlier quoted context omitted.
I don’t like Go error handling, but exceptions are terrible and not better. Rust/Zig/Swift approach is definitely the best.
Exceptions are much better, especially checked ones (which are analogous to Rust-style result types).
Rust-style result types continue the normal control flow.
Any exception thrown deep into a function can be very hard to debug. The normal line of execution is stopped, even without a return, and if it’s a checked exception it can “bubble up” to higher functions despite nothing signifying a return, just a marker saying somewhere this can throw an exception.
Exceptions are terrible.
Earlier quoted context omitted.
The parallels to Java are so fascinating on multiple levels. Did you know that Guy Steele was behind it too? At one point it was a revelation to me that the Java designers were not rookies, they just made a conscious decision to dumb things down. And in hindsight and after 15 years of cleaning up the mess we know that they just needlessly made a generation of developers suffer through primitive abstractions.
I don’t see anything on how Guy Steele would be behind Go. And Java is not a badly designed language at all, it did make several tradeoffs at places for various reasons, but it had a clear design goal and I think it did live up to it.
The most glaring issues were fixed in Java5 (similar to how golang just had their generics story improved). It took us all the way to Java8 to have a semi-pleasant language. I'm still waiting to see if Golang's generics are good enough to make abstractions/monadic operations similar to the Java's Streams widespread. If memory serves, basic pattern matching is coming in Java20, only 12+ years after Scala.
In contract to, say, virtual threads, a lot of these are language-level features. So they could have been done _much_ earlier. A generation of developers had their taste for abstractions skewed by the early days Java. Doing the job of the compiler in their heads. Now the next generation finds itself in the same situation with Golang.
Earlier quoted context omitted.
That's exactly the language I want as well. A mashup of Go and Rust that keeps the best of both. Also, don't forget "compiles fast "! And the garbage collector, although I'd love a language that allowed me to handle memory as well.
Here is one, https://dlang.org/
Beyond that, it actually looks really cool!
Earlier quoted context omitted.
The answer to error handling is ADT like Result or Maybe . The problem with old exception is that it is not part of the function signature. If a function says it accept a key and return a value; why should I expect it to return NullPointerException?
And what if an underlying library returns the exception? All the opposition to exceptions I have encountered are theoretical, and I have never seen it work that way in practice. What signature do you get from "if err := myFunction()"? It's still just a generic error object, possibly a string. You still have to write a handler for it. Why do it every time? I have a web application. There is a SQL query that produced n…
You provided an example from Go which is almost like an exception. And I think it is bad. You have a function that returns....something?? Instead, if you have something like Result, it tells you exactly what you're getting.
```
value = myFunction();
match value {
Ok(v) => // whatever
Err(MalformedSQL) => // oh something with sql happened?
Err(UserNotFound) => // oh can't find user?
```
Then you get "BZZZZZ, compile error. You forgot to check for another variant of the Error (ThirdPartyLibraryError)" which is a million time better than catch-all exception handling because you are afraid something might get out of this function call. If you do want to have a catch-all exception handling, then that is also possible by using "_ => {}" which is explicit. So just glancing at a piece of code, you know you have handled ALL the possible error cases.
>I have a web application. There is a SQL query that produced no results for an object. I throw an ObjectNotFoundException. It results in an HTTP 404, producing a web page or a JSON response, depending on the request location, and I handle it all once.
Also possible in axum. You have an error enum and then you implement a trait that converts said enum into an HTTP response. So your code looks something like
```
value = myFunction()?;
```
and if there's any error it will automagically turned into the appropriate response. So I get all the ease of exception but the type signature is not lying to me. If I forgot to implement a conversion from some new error to HTTP I get compile time error.
Earlier quoted context omitted.
I don’t see anything on how Guy Steele would be behind Go. And Java is not a badly designed language at all, it did make several tradeoffs at places for various reasons, but it had a clear design goal and I think it did live up to it.
I didn't phrase it correctly. What I meant was that Mr Steele was part of the Java org in the early days. He is from a generation before my time but from what I gather a Scheme/Lisp luminary is someone who is competitive with the Golang designers and the PLT PhDs in general. The most glaring issues were fixed in Java5 (similar to how golang just had their generics story improved). It took us all the way to Java8 to h…
I think this slow moving is really an advantage for Java, such a widely used language can’t allow breaking changes willy-nilly so any language feature will effectively become written in stone. Also, surprisingly many things can be expressed purely by “objects with method” APIs (Steele’s growing a language)
A new language on the other hand could have actually iterated fast because relatively few programs are written for them in the early years, go is just not a good language.
Earlier quoted context omitted.
Exceptions are much better, especially checked ones (which are analogous to Rust-style result types).
Not analogous. Rust-style result types continue the normal control flow. Any exception thrown deep into a function can be very hard to debug. The normal line of execution is stopped, even without a return, and if it’s a checked exception it can “bubble up” to higher functions despite nothing signifying a return, just a marker saying somewhere this can throw an exception. Exceptions are terrible.
Earlier quoted context omitted.
> Rust doesn't have nil/null values. Yeah, and it's also not popular. The reason I said "popular" is because the popular languages are addressing pain-points for devs. If nil/null was a pain point, none of the popular languages would allow nil/null values. The simple fact is that, for many developers, there is a pressing need to indicate lack of a value. Languages that don't address this pain-point never really get t…
"Old language have it, so it must not be a problem" is not a very convincing argument. Almost every new language that has come out in the last ~10 years or so tries hard to avoid null pointers, and old languages try very hard to mitigate the problem in various ways. Dart went through a tedious process of removing nullability. Kotlin doesn't have nullability (well, sort of, using Java bindings can still get you null p…
That strawman is not the argument. The argument is that "popular languages have it, so it must be solving some problem".
You can say what you like about popularity, but it still remains a good indicator of what works in practice and what doesn't, especially when the alternatives are all well-known and have been around for decades.
Earlier quoted context omitted.
> Rust doesn't have nil/null values. Yeah, and it's also not popular. The reason I said "popular" is because the popular languages are addressing pain-points for devs. If nil/null was a pain point, none of the popular languages would allow nil/null values. The simple fact is that, for many developers, there is a pressing need to indicate lack of a value. Languages that don't address this pain-point never really get t…
I don't think anyone gets to say that Rust isn't popular anymore. Especially considering it's now in the Linux kernel.
Popular amongst Rust fans, certainly. Popular amongst employers, no. It's still barely a rounding error for employers.