3 ms·

> Java’s a pretty nice language, and when my code compiles, which is often the first time, it’ll usually also run correctly. This is the exact opposite experie

by zumu 5y ago

> Java’s a pretty nice language, and when my code compiles, which is often the first time, it’ll usually also run correctly. This is the exact opposite experience for me. I find Java's type system to be extremely lacking (e.g. nullability, no discriminated unions, etc.), such that I write plenty of application code to mimic what a robust type system would enforce. Unfortunately, since it's not a compile time check, if you do it wrong, you get errors in production. In this way, it is the same as a fully dynamic language—what compiles has loose guarantees about correctness. Excuse me for a moment, but I'm going to be that annoying guy—but once you get some experience with an ML style language (e.g. Haskell, OCaml, SML, etc.) it's painful to go back to these class name based type systems.

nextos 5y ago
F# might be a great compromise. A HM type system plus a Java-like platform with excellent libraries and support.
- zumu 5y ago
  Do you know anywhere that actually use it? I've heard Walmart Labs, but that's about the only place I know about.
- lmm 5y ago
  Scala is similar, with a somewhat nicer type system (full HKT) and an even more Java-like platform.
- shirogane86x 5y ago
  just as a heads up, as someone who's worked as an F# dev for the last three years: it's HM, but compared to the other languages mentioned (Haskell, OCaml, SML), it still tends to feel C#-y when doing fairly complex things. Also some things don't quite feel right: indentation is sometimes finnicky, type inference only really works left-to-right (might only be a problem for me, I do a lot of Haskell in my free time so right to left feels more natural), still has all the baggage from other .NET languages, which helps interop, but also means that when you try to bend the type system a bit you end up with method overloading. Even for simple things like optional or named parameters (which can only be done on uncurried instance and static methods, but not on functions). Type providers feel great until you have enough that they break your editor and they slow compilation down massively. editor tooling also feels pretty immature (it didn't work well at all on my machine, but YMMV). I think if you want to use an HM language, go with OCaml/Haskell, don't bother with F#, unless you specifically need the ecosystem. OCaml/Haskell's ecosystems are smaller compared to .NET, but you can still get by a lot of the time, and IMHO you get a more polished language + an ecosystem that was designed for it, as opposed to getting a language that at points feels dodgy + a big ecosystem that (for the most part) wasn't at all designed for the language you're using. TL;DR: F# is only worth it if you need to take advantage of the .NET ecosystem, otherwise just go with SML/Haskell/OCaml
imtringued 5y ago
> when my code compiles, which is often the first time, it’ll usually also run correctly. I don't understand this, this is extreme hyperbole. Even when I used one of the strictest JVM languages where almost everything was a compiler error I still only had the guarantee that 99% of the time it is not going to crash, not that the code is correct. Of course, Java crashed all the time, groovy crashes a lot of the time, but it's a dynamic language that is supposed to fail like that. Once the code compiled, the business logic could still be wrong but getting the business logic correct is my job, not the machine's and the benefits of avoiding machine errors cannot be understated.
kaba0 5y ago
> discriminated unions Java now has sealed classes/interfaces. They are sum types, not sure what is actually the difference between discriminated unions. And with records, you have named tuples, basically product types. As far as I know, Haskell also only has algebraic datatypes. The syntax is like so: ``` sealed interface Expression permits Add, Multiply {} record Add(Expression a, Expression b) implements Expression {} ``` (written on phone so it may not actually compile) And you also have switch expressions enforcing that you have used up every possibility (even null!), and with the coming better pattern matching, Java will become quite an expressive language.
- zumu 5y ago
  Thanks for bringing this up. I am actually very excited about these features, but they are still not quite available for most of us Java devs yet. The LTS version that contains them doesn't release until September, and it will take months (if not years) for many shops to upgrade. My critique was more targeted to the Java of the time period this article was written in (2014), but these new additions are another point for the "Just write it in Java" folks.

by zumu 5y ago

nextos 5y ago

F# might be a great compromise. A HM type system plus a Java-like platform with excellent libraries and support.

zumu 5y ago
Do you know anywhere that actually use it? I've heard Walmart Labs, but that's about the only place I know about.
lmm 5y ago
Scala is similar, with a somewhat nicer type system (full HKT) and an even more Java-like platform.
shirogane86x 5y ago
just as a heads up, as someone who's worked as an F# dev for the last three years: it's HM, but compared to the other languages mentioned (Haskell, OCaml, SML), it still tends to feel C#-y when doing fairly complex things. Also some things don't quite feel right: indentation is sometimes finnicky, type inference only really works left-to-right (might only be a problem for me, I do a lot of Haskell in my free time so right to left feels more natural), still has all the baggage from other .NET languages, which helps interop, but also means that when you try to bend the type system a bit you end up with method overloading. Even for simple things like optional or named parameters (which can only be done on uncurried instance and static methods, but not on functions). Type providers feel great until you have enough that they break your editor and they slow compilation down massively. editor tooling also feels pretty immature (it didn't work well at all on my machine, but YMMV). I think if you want to use an HM language, go with OCaml/Haskell, don't bother with F#, unless you specifically need the ecosystem. OCaml/Haskell's ecosystems are smaller compared to .NET, but you can still get by a lot of the time, and IMHO you get a more polished language + an ecosystem that was designed for it, as opposed to getting a language that at points feels dodgy + a big ecosystem that (for the most part) wasn't at all designed for the language you're using. TL;DR: F# is only worth it if you need to take advantage of the .NET ecosystem, otherwise just go with SML/Haskell/OCaml

imtringued 5y ago

> when my code compiles, which is often the first time, it’ll usually also run correctly. I don't understand this, this is extreme hyperbole. Even when I used one of the strictest JVM languages where almost everything was a compiler error I still only had the guarantee that 99% of the time it is not going to crash, not that the code is correct. Of course, Java crashed all the time, groovy crashes a lot of the time, but it's a dynamic language that is supposed to fail like that. Once the code compiled, the business logic could still be wrong but getting the business logic correct is my job, not the machine's and the benefits of avoiding machine errors cannot be understated.

kaba0 5y ago

> discriminated unions Java now has sealed classes/interfaces. They are sum types, not sure what is actually the difference between discriminated unions. And with records, you have named tuples, basically product types. As far as I know, Haskell also only has algebraic datatypes. The syntax is like so: ``` sealed interface Expression permits Add, Multiply {} record Add(Expression a, Expression b) implements Expression {} ``` (written on phone so it may not actually compile) And you also have switch expressions enforcing that you have used up every possibility (even null!), and with the coming better pattern matching, Java will become quite an expressive language.

zumu 5y ago
Thanks for bringing this up. I am actually very excited about these features, but they are still not quite available for most of us Java devs yet. The LTS version that contains them doesn't release until September, and it will take months (if not years) for many shops to upgrade. My critique was more targeted to the Java of the time period this article was written in (2014), but these new additions are another point for the "Just write it in Java" folks.