Are you miserable when using other FP languages?

I got some knowledge on Elixir quickly, the language is very simple and straightforward. I feel that even not having a deep understand at the language I could contribute to any codebase. Now, I’m having to learn Scala for a new position and I never been more miserable, to a point that I’m considering a 30% pay cut to jump to another company just to not have to program in Scala anymore.

Just curious to know if this is something that others have experience as well with Scala or any other FP language. Maybe Elixir is just too good :sweat_smile:

2 Likes

I was also trying to learn scala professionally about half a year ago after not being able to find an elixir job for long.

I made a few conclusions about the language for myself:

  1. It has features of FP mixed with features from OOP and imperative, which makes codebases a mess, I like functional languages because they have less complex features, not the other way around;
  2. because of so many features, the ecosystem is fractured into lots of philosophies/frameworks/libraries that all do things in different ways, one worse than the other;
  3. the standard language constructs are designed as an afterthought. Take for example what they call monads and how they are implemented like some kind of list interfaces under the hood, the way you chain them with what they call a for loop is just horrible design that has no reason to be like that.

At this point I would rather pick kotlin, as it is more focused and has a clear goal on what it tries to achieve, while scala tries to do a lot of things and none of them that well.

I would recommend to try out clojure instead, I’ve heard many great things about the language and the revolving ecosystem.

5 Likes

30% is a large paycut so whatever decision you make, don’t make it quickly.

2 Likes

Scala has a learning curve issue, but I don’t think its “miserable” to work with in the long term. Don’t jump the ship too early.

You already have pretty solid comments so I’ll only remark that if you don’t want to take a pay cut then you can make a philosophical compromise and look into Golang.

Far from perfect but the one thing it has in common in Elixir is that it’s mostly explicit and self-explanatory.

1 Like

Scala should be amazing

I dont know Scala, but there are good reasons to call it amazing

  1. Interop with Java
  2. I heard that the JVM is faster than the Beam
  3. Zio (zio.dev)
  4. Smart creator who makes very nice videos ( Martin Odersky)
  5. Lost of big projects are built on scala ( spark , akka pekko, play )
  6. It speaks javascript (Scala.js)
  7. Rock the JVM is very Scala centric

There is a lot to like about Scala … I would say you are lucky to be working in a place where they are using it

1 Like

Spark/Scala experience for a couple of years here

  1. Toooo many features, specially for the FP part I would say.
  2. The language prefers to be implicit more than explicit. You end up reading the whole codebase to understand just a single file.
  3. People who choose Scala tend to abstraction, so projects tend to be very complex because of that and it becomes difficult to switch from one project to another.

That being said, the language is very likeable and allows you to go deeper in you FP knowledge if it’s whats you want. Just don’t give up on your first try :slight_smile:

Can’t agree more XD

2 Likes

I’ve developed in many functional languages professionally, from various lisps to Haskell, Scala, F# and they differ.

Languages like Haskell and Scala that emphasize development with types are entirely different from most dynamically typed languages. You have to at least get a basic understanding of monads, type classes (implicits) and type systems (which isn’t impossible). This implies a steep learning curve in both, methodology, as well as syntax. To top it all, Scala has one of the most versatile type systems I worked with.

That said, the struggle you are feeling is expected, but the understanding and insights you’ll get are valuable and this will even improve your coding in Elixir. I recommend to get used to it and enjoy the insights into different concepts of software development. Even if it hurts.

3 Likes

I am not sure people would reject Scala because it’s difficult to learn. I was left with the impression that the too many paradigms mixed in and too many ways to do the same thing are the main turn-off.

2 Likes

Which I would argue makes it hard to learn :stuck_out_tongue: because you have to learn many techniques to do one thing. And many of these (subtyping, implicits, monads, inheritance) are not trivial, if seen for the first time.

1 Like

Ok, this will be a long answer because I’ll answer all comments in one reply. Bear with me.

@D4no0, indeed, from the FP languages maybe Scala is the one with more open positions. I totally agree with the points you raised.

@joey_the_snake and @v0idpwn , hey, thanks for that. That’s a good advice, it’s hard to take this decisions with your head hot. I’m trying to digest this change for more time.

@dimitarvp, I’m quite productive with Go and I would chose it over Scala at any time. Still, the market is not good right now and I’m kinda of well paid at my current position. I’ll wait for a better opportunity to jump the ship, maybe until there I start to appreciate more Scala, who knows.

@shishini, in theory yes. The language itself is quite nice, but the ecosystem is the worst I’ve ever seen. It’s a niche language and the community is fragmented into multiple types of Scala: Better Python, Better Java, Haskell on the JVM with Cats and then with ZIO, and AKKA. The integration between the JVM and Scala is more of a curse than anything else. It’s not like Erlang and Elixir where they both share the same values.
In theory if you can select a subset of the language that you’ll use it can be enjoyable, but from personal experience every codebase is a mess and is a mix between all types of Scala. It’s crazy hard to understand what is happening.

@SirWerto, yes, the implicit part of the language is the worse. I don’t know why devs have this obsession to make things implicit and “faster” to write and then it becomes a nightmare to read and maintain. It’s crazy that every time I ask questions for more experienced Scala devs at my company they always need to open the file on their IDEs to give any advice. They can’t understand what is happening on a function just by taking a look at the function. This is such a non sense.

@murrgelb, thanks for the advice. I’m mainly a Go developer and working with Scala for the past 2 months has already opened my eyes to so many things. Not that I was not aware of them before, but how some things are made simpler with things like ADTs for example. (but yet, I would choose Go over Scala at any moment :sweat_smile:)

1 Like

I am not positive that the programming language plays an ultimate role here. I’ve worked in places where I hated to write elixir, just because the working conditions were horrible and vice-versa, had a nice job where I was writing on android with kotlin and enjoyed having some nice teammates that were open to write kotlin in a more functional way and simplifying the codebase.

I personally don’t mind working in whatever language, as long as the people I work with create readable and tested code, not drown themselves in some stupid design patterns and complexity that they have read from some random books, or try to abstract things that will never need abstraction in the lifetime of the project. Sadly no language is protected from such things in this regard, so it’s more important IMO to pick a company and a team you enjoy working with.

7 Likes

It’s been years since I’ve looked at Scala. I always thought they must have an odd sense of humor since the “Scala for the Impatient” book was > 1,000 pages.

The main selling point at that time (years ago now) was not the language but the number of libraries. I think CTOs at medium to large scale businesses are going to value 1) number/quality of libraries; 2) talent pool - how many developers know the language; 3) ability of language + libraries to work really well with their existing/projected infrastructure. I could go on but how much developers like a particular language probably isn’t near top of a CTO’s list (except as it impacts all the other things they’re looking for).

1 Like

Thanks for this post. I find it very informative.

So, what should I take out of this? Is is that Scala codebases are difficult to read because of its complex and fragmented feature set and developer practices?

I looked into Scala but gave up on it because of the small ecosystem, the need to interact with Java code and thus people overusing Design Patterns, and the unintuitive build system.

I write a lot of Rust now and find large Rust codebases also difficult to read because of the redirections in abstractions (functions calling functions), though it is way better than searching for factories or classes that implements some interface. I guess this is a common issue with languages with powerful implicit features and because actual “clean” code is such a chore.

What about Rust you find implicit?

Traits of course. They allow seemingly magical method calling and parameter passing, without even the need to specify what the trait is when the compiler thinks there is only one possibility (which was recently broken?). The simple example is Into::into, but there are crazier use cases like routers where you have little idea why you can even call that method and get that output unless you dig into it.

Normally I had no problems with traits… until I got to tokio and several other crates its seamless operation relies on. That was hell indeed. Hopefully LSP tooling and looking up who defines what and where has improved because yeah it was maddening.

I’ve worked with a number of programming languages. It always amazes me how us humans (me included) can make a complete muddle out of any programming language.

I worked at three different companies that used Java (or other JVM) languages and examined a number of larger libraries in Java. It’s amazing that this software worked at all. But it’s really not language specific. I’ve seen Elixir code that made me take a step back in amazement at what a complete mess had been created. Javascript… well… I won’t even go there.

What I did was to try and put myself in the shoes of the person who was going to have to come next and try and maintain the junk I was writing. I tried to use the best techniques I could find / learn to organize the code to make the work life of that future person (sometimes me) as little complicated as possible.

I do like Elixir and think it has a design and set of features that make me happy and productive and allow me (I hope) to produce code that isn’t too horrible for the next person that has to work on it.

Ultimately you have to make a living and working on code that is kind of painful to look at might be necessary. If you can make a living and work on code that better aligns with how you want code (and work in general) organized then definitely pursue that.

good luck.

1 Like