[profdemarco]

> Scala gives you are a much faster way to achieve the level of reliability you need than the level of testing you need in a less typed language

I have serious doubts about this since practically everything in the Scala standard library is horribly broken (collections, views, everything in scala.io, scala.xml and scala.actors etc.). The number of bugs found by Paul Phillips alone is absolutely ludicrous.

As it stands now, both Haskell and Clojure have vastly superior libraries, build systems that actually work, and implementations that people actually understand and can modify.

[octo_t]

How are collections broken? Views are deprecated/set to be deprecated, I don't really use scala.io, I find java io sufficient for my needs, scala.xml is being split out in 2.11 and macros will let people use a third party implementation, scala.actors is also deprecated, having been replaced by Akka.

Paul has definitely found a lot of "bugs", he has certainly contributed a huge amount to the cleanliness of the code base, and has been a big pusher for removing certain levels of unsoundness in the type system, but if you were looking for bug-finders + fixers, Simon Ochsenreither is probably a better bet.

[Hakeashar]

Just a quick question - if the views are set to be deprecated, what would be the way to do a (long) series of collection transformation without spawning multiple intermediate collections? So, essentially, equivalent of .view, transformations, .force?

[profdemarco]

You use an iterator, which has its own caveats, or you simply accept that chaining collection transformations is going to be ridiculously inefficient.

[lmm]

The scala collections library is the most powerful/flexible I've ever seen in a strongly typed language; it combines the safety of Haskell with the flexibility of Clojure. Given the amount of ongoing complaints I see around cabal I don't think it's fair to say it "actually works" (fwiw I'm very happily using maven to build my Scala projects, so I never really know what the sbt fuss is about). And the rate of features and other progress in recent scala releases clearly demonstrates there are plenty of people who understand the implementation well enough to modify it.

[profdemarco]

> it combines the safety of Haskell with the flexibility of Clojure

Foldable, Traversable, Monoid etc. are all far better abstractions than what Scala collections provide, and they don't lead to unmanageable inheritance hierarchies and ridiculous APIs. How many bugs have been caused by that? A few hundred maybe? Does Set equality work in the current release or is that broken again? Is it possible to do thread safe efficient merges in immutable collections yet?

The only thing Scala collections offers that Haskell doesn't is the CanBuildFrom travesty. At least in Clojure you can chain transformations together without generating tons of intermediate values. In Scala you're forced to choose between being ridiculously inefficient or using iterators.

[happy4crazy]

Can you expand on the CanBuildFrom travesty?

(It seems like you've got interesting things to say, but you're being a bit strident. It bums me out that Scala discussions on HN take such a heated tone.)

[profdemarco]

CanBuildFrom is essentially a typeclass in Scala that is used for converting between collection types. Ignoring the coherency issues associated with using implicits for typeclasses, it makes the implementation of the collections library significantly more complicated and causes issues with type inference.

In the rare cases where you actually need to convert between collection types, it's usually trivial and more efficient to do it manually. Essentially they've added tons of complexity for negligible benefit. One of my main gripes with the Scala collections library is that it's overly complex and that this complexity has been the source of hundreds of bugs.

If there was any real benefit to the way it's currently done they wouldn't be hiding the true type signature for things like `List.map` in the official Scaladocs.

[frowaway001]

You are kind of either ignoring or not knowing the core use-case of CanBuildFrom. Why talk about things you don't understand?

[profdemarco]

The reasons other than the ones I've outlined are caused by implementation details and wouldn't exist if they chose the correct abstractions.

[Sssnake]

You should try haskell sometime, their version of collections is much better. Complaints about cabal are of the same nature as complaints about every package manager "hey I tried to do something that can't be done and it said it can't be done". Having used all three languages, I still use haskell daily, I would use clojure again if demanded without complaint, and I would never in a million years consider touching scala again, ever.

[frowaway001]

The last time I looked chaining collection operations still required unnecessary boilerplate and was not even the default way to use collections. Did they fix that? As far as I know, they didn't.

Additionally, it seems that moving from lists to a different collection type still involves rewriting your whole code due to the insane idea of using different functions by default (fmap/map, mempty/[], mappend/++).

I just don't have to deal with any of these design mistakes in Scala. Having sane defaults and stuff that "just works" consistently are a huge benefit.

[Sssnake]

>The last time I looked chaining collection operations still required unnecessary boilerplate and was not even the default way to use collections. Did they fix that?

I can't even imagine what you are talking about, so I can't say if they "fixed it" or not.

>Additionally, it seems that moving from lists to a different collection type still involves rewriting your whole code due to the insane idea of using different functions by default

"I did something dumb and now I don't like it". So, don't do it? Why were you using map in the first place?

>I just don't have to deal with any of these design mistakes in Scala

I don't have to deal with them in haskell either. But I do have to deal with the hundreds of other mistakes scala made if I use it.

[koeninger]

"build systems that actually work"

Maybe I'm feeding a troll here, but I've been building production software for over 4 years using SBT. It works.

[saryant]

Scala.xml and scala.actors are both deprecated. XML has been moved out of the language and scala.actors has been replaced with Akka actors (which are awesome, BTW).

[profdemarco]

They were (or are) being deprecated because they were broken beyond repair. That's pretty damning considering that all of the things I mentioned have been done properly in plenty of other languages. They aren't treading new ground here.

> Akka actors (which are awesome, BTW).

PartialFunction[Any, Unit]. Ridiculous.

[saryant]

The found a better solution so they switched to it?

That's bad?

As for the PartialFunction[Any, Unit] comment: well, yeah. That's the way actors work. They can be sent any message but may or may not respond. The company I work for has a very large Akka-based backend and that has honestly never been an issue for us. Moreover, it's necessary to facilitate hop-swapping (changing an actor's behavior dynamically during runtime). That is most certainly not a feature I would be willing to sacrifice. "context.become" is an incredibly powerful tool within Akka, especially in how it makes modeling a finite-state machine quite trivial in practice.

[lmm]

FWIW as a big scala fan I've given up on akka actors, until they manage to make typed ones that work (the current ones rely on an experimental reflection library that has threading bugs). The biggest advantage of Scala is type safety; if I wanted an unsafe language with actors I'd use Erlang.

[saryant]

Quite honestly, it's never a problem. In fact, I think it's a huge advantage. I simply would not be willing to give up the ability to change an actor's behavior dynamically.

We use the FSM helper [1] heavily in our backend at Conspire. For data-pipeline use cases, it's invaluable. Keeps our code concise, readable and testable. Even basic become/unbecome operations are big for us, I've written up one of their use cases on our blog [2].

[1] http://doc.akka.io/docs/akka/2.2.3/scala/fsm.html

[2] http://blog.goconspire.com/post/64901258135/akka-at-conspire...