Comment by uDontKnowMe | Hacker News Reader

Comment by uDontKnowMe | Hacker News Reader

Parent Full thread

Unfortunately like you say the pure FP crowd are extremely vocal online and that seeps into the culture of any company that uses Scala. Most of the visible members of the community value and advocate for fp purity and 100% type-safety at any cost, and that has a large effect on who gets attracted to learn Scala in the first place, what they consider to be good or bad code, etc. The resulting culture of firms using Scala ends up being one of pure-fp aspirational, if not pure-fp outright. Anyone who denies the superiority of a pure fp approach is constantly brow-beaten for being such a simpleton.

Every time you dare use something as impure as a mutable object, or a non-const reference (so var instead of val), or even want to look up an item in a collection by index (unsafe operation since it will throw exception if index >= length) you'll have to prepare for a heckling from your team mates. Anyone you might ask help from online will first look down their nose at you for even wanting to do something so despicable, and you'll have to humour them with "well yes oh great FP lords, I know that this is really really bad I know, but I have to for .... reason, please help me anyways!".

There is definitely some truth in what you’re saying —- especially at startups without a strongly developed internal Scala culture.

I think it’s less of an issue at large companies like Twitter, Asana, Databricks, etc, which overall probably employ most working Scala programmers but not the most vocal.

Zalando has probably surpassed Twitter as the biggest Scala shop for a few years now. If you look at Twitter's ecosystem you'll see that while it's mature, the style is very good overall and not so different from modern and opinionated FP libraries. Twitter used to employ people like Travis Brown for instance.

Spark (and Kafka too maybe) are outliers here.

I agree with your evaluation that parts of the FP community are extremely vocal and extremely smug, and this can and does have a bad effect on a community. This is a problem. Dealing with this problem requires leadership. In particular a project leader typically has to decide (in a Scala context) whether to go FP or imperative, because mixing both is often a problem. Similar to e.g. using message passing or shared memory for communication between threads.

    throw exception

This is a good example. It is really important to be very clear from Day 1 how to handle errors in a project. One hybrid choice that is popular is: use exceptions for errors that you cannot recover from, use Options for local error handling.

Option does throw away the error. I like Try { expr } a lot, to the point that I retry, give up, and then serialize a Try[T <: Product] into a Row so flaky dependencies don't trash all the output from a big Spark job.

Yes, that's true, if you want to propagate information about the nature of what went wrong locally (e.g. logging) you need to use something richer (e.g. Either).

Yeah, Try[T] is basically Either[Throwable, T] with some glue for catching and rethrowing.

Reply on news.ycombinator.com