Hacker News Reader

Comment by hota_mazi | Hacker News Reader

Go gives you the illusion of simplicity because it gets rid of guard rails and error checking. If you remove all error checking, of course your code is going to look a lot simpler. It's also going to be a lot more wrong and crashy.

Wait until your code base grows, your team grows to >10 developers, and you will understand what I mean.

Java (and preferably Kotlin) are a lot more serious about making sure your code is robust before it compiles.

View on HN

Wait, are you implying Go doesn't have error checking? In what way? It has famously verbose error semantics.

It's verbose yes, but also more error prone.

No exhaustive enum checks.

No Option type, so you can still use results of a function if it returns an error.

well... https://github.com/search?q=%22f%2C+_+%3A%3D+%22+language%3A...

98k results...

I've heard this argument before, and I point out Kubernetes to them. Is that code base complex enough, because it's pure Go doing just fine and runs on plenty of systems?

You can point to a complex project in any language, and that would prove nothing.

I mean, that’s pretty much go’s first complex application that was specifically written with that, so don’t think it is a good example.

> Java (and preferably Kotlin) are a lot more serious about making sure your code is robust before it compiles.

You are making great points for Rust, Ocaml and Haskell.

There isn't all that many plus in their type systems that is not expressible in Java. OCaml and Haskell has Monads, sure. There is Scala for that on the JVM.

> There isn't all that many plus in their type systems that is not expressible in Java.

Thanks to Turing, anything that is Turing-complete can duplicate any other thing that is Turing-complete. So, yes, you can do all of Haskell's types in Java. That is not a flex.

The flex is doing them in a non-horrific way.

The kind of Turing completeness certain type systems have is useless beside academic curiosity - look at the vavr library, that’s what I’m talking about. You can have plenty Haskell types without any hacks, except for Monads in Java.

> vavr - turns java™ upside down

"turn X upside down" are different words for "use X contrary to its original intention and design".

You will find very few people willing to let go what people undestand as Java so as to be able to do Haskell-in-Java.

It’s goddamn immutable collections and Optionals, not brain surgery come on.

It’s not like Java hasn’t been going in the same direction, see records, sum types, pattern matching.

Yes, it's goddamn immutable collections and Optionals.

People still hate it because it's immutable, therefore you can't do hashmap.add(), and it's hard because they can't randomly return nulls, and it's slow because the hashmap now takes o(log n) always instead of o(1) sometimes and o(n) other times.

People hate it because it's different to the Java they learnt 20 years ago, that they claim is exactly the same as today.

Is it possible to express Rust enums (tagged unions) and especially the option type in Java? Ofcourse. But the power of good type system doesn't come from the fact if you can express something, but rather how seamlessly it is integrated in to the language.

Rust has sum types named wrongly as enums, which java also has as sealed interfaces. The option type is just one example for a sum type, which is as easy to express in Java as

  sealed interface Option<T> permits Some<T>, None<T> {
    record Some<T>(T value) {}
    record None<T>() {}
  }

Sure, you have written 3 words more than Rust, and?

Reply on news.ycombinator.com