Hacker News new | past | comments | ask | show | jobs | submit login

It's not so much about what I would remove, it's more about gaining guidance/acceptance/standardization around the "right" way to do various things.

When creating a library should my functionality exist explicitly on the types? As extension methods on an implicit? As type classes?

When should I use infix/prefix notation? When should I use . syntax vs no .? What does _ mean in this particular line of code? Is an allocation happening for this lambda or not?

Why are map/flatmap/filter magical? Why are for comprehensions part of the language for those but not for type classes?

All of these kinds of questions are really hard to answer and I've been programming Scala in production for years.

Other complaints I have are about the mess that is the collections library, the push for actors when they are generally a bad solution, an emphasis on algebraic types without providing Union types, and all the opportunity costs represented in sbt (which is finally passable but no better) and Scala IDE.

Don't get me wrong, if you are targeting the JVM & want strong typing (I do), Scala is the best language for the job, but even for someone who uses it every day and is pretty expert there are some confusing corners & no 2 developers seem to write code the same way, so there is a price to be paid for that.




Wow, I have never heard anyone talk about actors that way, but have often thought it myself. What makes you say this?


I have 3 major complaints about actors (specifically Scala/Akka actors, but most of the models I've encountered have similar problems).

1) In general, I think that going parallel should be an architectural decision. On current commodity architectures it doesn't buy people as much as they think it does, and can in many cases over complicate code. Actors hide this complexity, but don't actually remove it. People think actors give them free license to add tons of threads when they shouldn't.

2) Actor code tends to mix business logic with threading logic, precisely what we should be trying to avoid.

3) The actor model subtly conflates publisher/consumer models which tend to decompose and perform better in parallel situations.

Normally, for calculation style parallelism I prefer future/promises and for event style parallelism I prefer single writer/multiple consumer based shared memory.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: