3 ms·

Please understand that this is subjective - some people will have good experiences with a language, and some people won't, and thats okay. That's the nature of

by yen223 6y ago

Please understand that this is subjective - some people will have good experiences with a language, and some people won't, and thats okay. That's the nature of languages. But yeah, I use Scala at work for what should be a simple crud app, and I absolutely hate it. Never felt less productive in my life. The biggest problem with Scala is the type system. Types are great for catching bugs _within_ a program, but don't really help much for catching bugs when the program interacts with the outside world, which CRUD apps do a lot with a database. So I'm paying the cost of having to learn this complex type system and all the wacky ways the type checker can fail, but I'm not reaping much of the benefits that comes from actually using Scala's type system. And if I'm not using Scala's type system, then what's the compelling reason for choosing it over Kotlin, or even Java?

lrobinovitch 6y ago
My work was doing the same (scala for crud app) and I gave a lightning talk at about exactly this - the expressiveness of the type system is hamstrung by the capabilities/quirks/documentation quality of the various serdes required to move scala objects into some other domain and back. Made everything so much harder than it should be.
tiew9Vii 6y ago
You can use types to help with the outside world by making error states explicit encoding them in types. ZIO for example. I can write programs without code covering all scenarios by stubbing out methods with types, using ADTs etc then it’s a case of implementing a function to run it all. However, I completely understand where you are coming from. I had some of the same issues until I worked with a great team who showed me the abstractions, why they are useful and how they work. If I hadn’t of worked with the team I did I would likely of still been agreeing with you. I think the biggest problem is it’s hard to understand on your own unless you are deep in to the theory. You don’t need to know the theory deeply to use the abstractions but unless someone shows you how to apply them it’s hard to discover. With that your last comment is exactly right. If you are not utilising Scala type system and other features Kotlin or Java will be better. Java is moving quick these days and Kotlin is closer to a better Java than Scala is.
noughtme 6y ago
During the interview process with the company I referred to above, I found out they were moving to a micro service based arch around TypeScript/Express which seemed like a bit of a 180. I was up for a front end position, but spent a couple weeks looking at Scala. The divisiveness between the pure functional and multi-paradigm communities left me confused on the preferred approach and syntax, and obviously this results in different library/framework preferences. I really want to like the language, but some of the build tools, like SBT seem to come from the JVM legacy, when more modern tooling like Mill exist.
whateveracct 6y ago
Since when do types not help with "the outside world"? People model "the outside world" with strong types all the time and have been doing so for years. SQL, typed API bindings, typed errors, etc Also I've spent some time with Kotlin now and ... it is just pure shit lol - its ADT support is comically inadequate. It's like the designers wanted them but only made a superficial copy without the hard part (real pattern matching.) Amatuerish. The language is pure sugar.

by yen223 6y ago

lrobinovitch 6y ago

My work was doing the same (scala for crud app) and I gave a lightning talk at about exactly this - the expressiveness of the type system is hamstrung by the capabilities/quirks/documentation quality of the various serdes required to move scala objects into some other domain and back. Made everything so much harder than it should be.

tiew9Vii 6y ago

You can use types to help with the outside world by making error states explicit encoding them in types. ZIO for example. I can write programs without code covering all scenarios by stubbing out methods with types, using ADTs etc then it’s a case of implementing a function to run it all. However, I completely understand where you are coming from. I had some of the same issues until I worked with a great team who showed me the abstractions, why they are useful and how they work. If I hadn’t of worked with the team I did I would likely of still been agreeing with you. I think the biggest problem is it’s hard to understand on your own unless you are deep in to the theory. You don’t need to know the theory deeply to use the abstractions but unless someone shows you how to apply them it’s hard to discover. With that your last comment is exactly right. If you are not utilising Scala type system and other features Kotlin or Java will be better. Java is moving quick these days and Kotlin is closer to a better Java than Scala is.

noughtme 6y ago

During the interview process with the company I referred to above, I found out they were moving to a micro service based arch around TypeScript/Express which seemed like a bit of a 180. I was up for a front end position, but spent a couple weeks looking at Scala. The divisiveness between the pure functional and multi-paradigm communities left me confused on the preferred approach and syntax, and obviously this results in different library/framework preferences. I really want to like the language, but some of the build tools, like SBT seem to come from the JVM legacy, when more modern tooling like Mill exist.

whateveracct 6y ago

Since when do types not help with "the outside world"? People model "the outside world" with strong types all the time and have been doing so for years. SQL, typed API bindings, typed errors, etc Also I've spent some time with Kotlin now and ... it is just pure shit lol - its ADT support is comically inadequate. It's like the designers wanted them but only made a superficial copy without the hard part (real pattern matching.) Amatuerish. The language is pure sugar.