Scala – 1 Star – Would Not Program Again - <AUTHOR> http://overwatering.org/blog/2013/12/scala-1-star-would-not-program-again/ <comment><USER5> I started learning Scala almost a year ago at my latest job - we use it for production systems at a large multinational investment bank.

Coming to Scala from experience including C, Java and Haskell, I intially found Scala quite difficult. It is true that there are some things in Scala that are not obvious to newcomers, and that are difficult to discover for yourself - such as the use of Implicits, and the strange precedence and binding rules for operator syntax.

That said, it doesn't take long to learn, and once you do, it all makes sense. There are other great languages out there (I'd say Haskell is one), but compared to for example Java, or one of the dynamically typed languages, Scala is superb.

Types, whilst not having the full H-M inference, are brilliant. That the author complains about having types rather than a simple map for keys shows a misunderstanding of what they are there for - the idea is to allow the compiler to prove at run-time what is valid code and what isn't. He comments that tests run too slowly in Scala (they don't - for our production systems building in SBT, a typical test run is significantly less than 10 seconds) but a lot of the time I don't even need to go that far - my IDE already highlights errors in the code as I type, where I have passed in incorrect or insufficient data.

Also, the author makes a strange comment that H-M 'enabled' Monads, and the comment is written in a way that implies that Scala does not have Monads. This is incorrect. Scala has monads, and the Scalaz library has huge support for Monadic programming. We use Monads and Applicative Functors (a close relative) daily to build high level abstractions, and we couldn't live without them. In Scala we say flatMap rather than bind (or >>=), but we mean the same thing. Although thanks to the same flexible method naming that the author complains about, you can in fact say >>= if you wish.

If you've only got a couple of days to use a language, and you're using it for a tiny project, then Scala is not for you. If want to learn a language that can make you vastly more productive whilst at the same time making your code safer and more robust, Scala is a very effective candidate. It's not the only candidate, but you should at least consider it.

<comment><USER6> I'll echo all of this (minus scalaz, we don't use that).

I'll give an example of the power of Scala's type system. When I first convinced one of our founders to give Scala a try, he used it to write the first pass of our analytics service. He'd never written Scala before but once it compiled, it ran _correctly_ on the first try, that's the power of its type system.

<comment><USER7> Having never used Scala before, does its type system provide details about errors that other languages do not? Watching a compile fail because of an incorrect type is not something I have run into very often, if ever, in other languages that provide similar type systems.

I mean mistakes can happen and if the type system can catch it for free, so to speak, that is great. I'm not about to argue that it is completely useless. But in terms of probabilities of what kind of bugs might be introduced, type errors seem to be on the low end.

To infer that Scala's type system is powerful enough to catch the more common types of mistakes programmers make, that is quite an impressive claim. I am curious to know more.

<comment><USER8> In Haskell, and I assume Scala, you can name types of the same form, so I might say a TimeSeries is a list of floating point values. If I use that data type, you can't accidentally pass a different kind of list of floating points even though they're the same type.

<comment><USER9> Yes, you can do this in scala with type aliases

<comment><USER10> Type aliases don't solve that problem. You need to use something like Shapeless' newtype.

</comment></comment></comment></comment></comment></comment><comment><USER11> Several years ago I picked up Odersky's book. I got a few hundred pages in, considered the types of problems I had encountered in my career so far, and decided life is too short to be spending my time learning some hyper-complex programming language that seemed, like C++, to seem unable to say "no" to introducing complexity where it would provide minimal upside in Getting Shit Done.

Instead, I learned Clojure. I use Ruby, the epitome of comfortable languages, for most things, and when the hard problems come up, I use clojure. My next major scientific computing problem, rare as they are, will be in Julia instead of Matlab for prototyping and java for production. Scala seems to be the hard language for easy problems. No thanks.

<comment><USER12> Scala reminds me of C++ too, but it's impressive that, in a mere 10 years, Scala has achieved all the multi-paradigm incoherence it took C++ 30 years and tortuous backwards compatibility constraints to attain.

Actually, I spent some time over the weekend trying to get familiar with Scala by using it to solve some Project Euler problems, and it was pretty entertaining. Still, the language's bias towards there being more than one way to do anything does worry me; it does seem that the kind of mutually incomprehensible code bases the OP talks about are likely. I would assume that, like C++, you need a strong style guide for a Scala project laying down which parts of the language you are going to use. Does anyone have any recommendations for guides on writing comprehensible, maintainable Scala?

<comment><USER13> Multi-paradigm incoherence? There is a huge difference between throwing multiple features/paradigms into one language (as C++ does) and _integrating_ them so that they are orthogonal and don't get into your way (as Scala does). The integration part is the hardest thing and Scala designers did the great job there, assuming the constraints that were given.

Scala does have some rough edges but they are not the kind of C++ ones, and even the complexity of the most powerful features (implicits) is very controllable.

Seriously - which features would you like to remove from Scala? I'm really curious because I don't find any redundant ones. All are pretty complementary and very useful.

<comment><USER14> I'm not sure I'd remove any, but there is a huge incoherence in what is and is not "idiomatic" scala.

The most obvious example that comes to mind is whether you should use mix in traits or type classes for api design. Another one is the "magic-ness" of map/flatmap/filter for for comprehensions but no way to extend that for Functor/Monad/Monoid type classes.

Finally, the Scala community is a huge advocate of Algebraic Data Types yet don't support Disjoint types making any sufficiently complex system cumbersome to model as an ADT.

</comment></comment></comment></comment><comment><USER15> I'm always interested to see intelligent criticisms of one of my choice languages. Let's take a look at what he has to say:

 _Slow build times complaint_

> It is essentially impossible to practice TDD in Scala simply due to the time > it takes to compile.

Hrmm, that's interesting, because it sure seems like other people are able to do this. I agree, the slow build times are annoying, but let's not exaggerate.

 _SBT critiques_

>That punctuation-strewn build system I was forced to use was just taking advantage of Scala's ridiculously flexible syntax.

Yeah, I get it, everyone makes fun of SBT's syntax.

 _Language is complicated_

This is where it just kind of descends into whining about how 'hard' the language is. He claims javascript is a "simple" language. Does he just not count the weird edge cases when thinking about complexity?

 _Type inference complaint_

> And this is the real death knell for Scala. Hindley-Milner Type Inference is > a fantastic thing.... It's enabled monads, which you want to be able to > understand and then use in a type-free language.

WAT. I don't think those words mean what you think they mean.

>In my mind, Hindley-Milner was always the promise and the pay-off for Scala...I know this is the fault of the JVM's use of type erasure. I don't care.

O REALLY? Go on...

Maybe if this guy had cared enough to do a five second google he'd realize that Scala doesn't use hindley-milner type inference.

Bottom line is, I think I have a good understanding of the type of programmer this guy is, and it's exemplified nicely in this quote right here:

>Sure, with another couple hours we would have been able to figure it out… [but] We ended up copying and pasting the same four lines into all our endpoints. A dark moment.

For an intelligent critique of the scala langauge see here:

[http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_...](http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_trouble_with_types_strange_loop_2013/cd3bgcu)

<comment><USER16> >Maybe if this guy had cared enough to do a five second google he'd realize that Scala doesn't use hindley-milner type inference.

That's his point. Scala doesn't use HM and it needs to. He says the reason it doesn't is because of the JVM, which seems misguided.

<comment><USER17> He states that H-M is not used because of the lack of reified generics, which is completely irrelevant. (Hint: type systems perform analysis at compile time; "reified generics" means having type arguments available at run-time.) H-M is not used because it is not compatible with subtyping or method overloading, which are both critical for Java interop. There is no particular reason that Scala needs to use exactly the H-M system.

</comment></comment></comment><comment><USER18> I like Scala. It's a JVM language, it's extremely powerful, but maybe it's too powerful for us mere mortals.

Eclipse allows very fast compilation times, but when I tried sbt, I gave up because I CAN'T wait for compilation: we're in 2013, I'm using a quad core at 3.4GHz, 12GB of RAM and SSD, so I'm not ready to wait. Eclipse allows fast incremental compilation.

Scala's type system is very rich. I don't know if there exists any type that can't be expressed in Scala. Since I don't know if such a type exists, I don't miss it. But that's probably too much, and in the end, idiomatic Scala emerges: some libraries use the type system in an idiomatic way. It's working, but understanding method signatures turns into a nightmare. Then you must learn the arcane of Scala to understand how the library works.

However, if YOUR Scala is simple enough, then the language can be cool, cooler than Java, and productive. Can be mixed with Java, runs fine for J2EE...

<comment><USER19> > I don't know if there exists any type that can't be expressed in Scala.

Scala has a very rich type system, but let us not get ahead of ourselves-- Scala, being non-dependently typed, cannot type many useful programs.

For an example of a useful dependent type, consider giving division the type Number -> {x : Number | x != 0} -> Number. Giving division the type Number -> Number -> Number is similar to how older Javas would type List<String> as List and require all get operations to cast from Object--in both cases, the type system is unable to guarantee that your program won't crash.

If you want a glimpse of the state of the art of programming with dependent types, try Agda[0].

[0]: [http://wiki.portal.chalmers.se/agda/pmwiki.php](http://wiki.portal.chalmers.se/agda/pmwiki.php)

<comment><USER20> How does that actually work? Does that "type" basically compile down to an added n != 0 check at runtime, or is there more sophisticated dataflow analysis/theorem proving going on?

<comment><USER19> It depends. In the most general case, you have to prove that the program you have given has the type you have asserted. This is similar to proving a mathematical theorem. Generally, the computer will assist you in this endeavor --for example, if you want to prove that A implies B, and A and B are linear inequalities, this can be solved automatically.

<comment><USER21> _Generally, the computer will assist you in this endeavor_

Kinda. Let's be honest: in production this often turns into a pain in the ass. There's some value in dependent typing, but providing evidence that concatenating UTF-8 strings is associative is not one of them.

<comment><USER22> That is hilarious. And I also hope your joking.

<comment><USER19> That user is not joking, but note that you generally prove that string concatenation is associative _once_ , not every time.

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> What is my biggest gripe theoretical gripe about Scala is that Trait order is important! Because traits can override common function. A class that is e.g. Ball with traits Shiny and Red is NOT the same as e.g. Ball with traits Red and Shiny. Why? Why complicate testing to a point where you need not only test traits for correct behavior, and not just composing of Traits, but even the order in which they are composed? Why?! Why complicate it so much?

Note: It's been a while since I've seen traits, this might have changed for better.

To me Scala is essentially if Java, Haskell and C++ went to a wizard to have a child. The result is a magical mess. I seriously think that Scala has at least twice as many concepts as C++ and same if not greater number of really weird edge cases. I don't want to keep Scala in my mind, no more than I want to keep Necromicon.

<comment><USER13> As long as your traits are independent, the order does not matter. Anyway, how do you imagine this could be done better? For order to not matter, the linearization could not be possible and we'd end up with something much more complex and ugly like multiple inheritance in C++ with all the diamond inheritance problems, etc.

<comment><USER23> Don't have an answer right this minute, but I think eschewing/forbidding variables in trait would prevent the most obvious such collisions.

If you can't override variables, you can't silently change the structure to depend on trait order. You'd have to explicitly state order.

PS. Of course if you have several same signature methods that call super, which is generated depending on order, same problem persist. So, forbidding variables and calling super elements should deal with most "magical" interactions.

<comment><USER13> If you can't call super nor use variables then this takes quite a lot of power from traits. IMHO being able to stack many traits one on another is a nice pattern.

<comment><USER23> Yeah, you trade power for easier testing and unforseen side-effects for determinism. IMO it's worth it.

</comment></comment></comment></comment></comment><comment><USER24> I tried learning Clojure, I really did, and I have to agree, the syntax is simpler, but I can't really read Clojure or code in Clojure the way I do in Scala, I don't know why. Whenever I read articles about Scala, I keep finding it amusing, prehaps this is because I had experience with Java, but for me Scala is a life saver, can't go back to Java after this. And I won't go back to Ruby, Python or JavaScript. So I can't really understand what these articles try to achieve, it's like the "don't buy bitcoin" articles, not sure what is the goal. If you don't like Scala, thanks for sharing, but I don't see how it affects me, I will still continue using it as my go to language until I find something better (there are contenders, Kotlin, Ceylon, Dart, TypeScript, and my favorite now - Nimrod, but there is still a big gap for me to fully switch)

So for someone like me who wants a statically typed language (there goes Ruby, Python JavaScript, Clojure), who thinks Haskell is too academic to be really productive (I have to think too much to get things done with it) and who don't get what is all the rage about Go (perhaps because I'm not a system programmer, in any case I still don't get it, sorry) This leaves me with no other options (except C#, which I would probably use if it was really portable)

Scala is not perfect, but I feel more productive with it than with any other language, if anyone who never used Scala will decide not to even try it because of this article, I wish them luck, but I doubt this will be the case. for those who use it, they will still continue.

So I really don't think I understand what is the point of such an article. Try the language for yourself, if you like it use it, if not, and you have a choice, don't.

p.s. for all those poor bastards who are forced to use Java at work, Scala is by far a gift from the Gods, so it helps to keep things in proportions, one man's source for a rant article, is other's source of means to finish work at 5pm and go back to the SO and kids. (they would go back at 1pm but their Sun Certified Java EE team lead brain will explode if they will use Clojure, with Scala your EJBs or Spring code can still look recognizable, perhaps a bit more pretty) p.s. did I forgot to say I love Scala?

<comment><USER25> This times 1000. I have been using Scala for the past 3 months in a play framework app that serves json. Today I had to write some quick Java for an Android client, and was quickly reminded how much freedom Scala's expressiveness gives you vs Java old cruft.

I mistakenly wrote a Java anonymous inner class that called a closed over variable from the outer scope like one would do with Scala closures. Of course the Java compiler threw an error because I didn't mark the variable as final.

When programing in Scala, one never has to deal with such low level rigidness. It just let's you get shit done.

<comment><USER6> Well, be careful with those closures. Scala's compiler won't (yet) throw an error if you close over a variable from the outer scope while operating on a Future.

The Scala team does have a plan to fix this though. Of course, if you aren't operating asynchronously or you're only closing over immutable values it doesn't matter anyways.

</comment></comment></comment><comment><USER26> Problem: author is pining for Go, and doesn't know it.

Solution: author should abandon the JVM ecosystem and use Go.

\- Fast compiles.

\- Ultra simple, non extensible syntax, yet not verbose in practise.

\- The code you see is 100% of the code.

\- A culture of implementing the simple algorithm.

\- Stable, with version compatibility guarantees.

\- Nobody is trying to make the types jump through hoops, so the type inference works.

<comment><USER27> I tried Go for the same reasons. It looked to me like a statically typed Java, but in practice it was not the best experience. The Code is not more expressive than Java, but you lose all the good libs and tools from Java. Most annoying was the in ability to create concise mocks, because you cannot implement interfaces at runtime with Go.

<comment><USER27> I wanted to say: "it looked to me like a statically typed _Python_ "

</comment></comment></comment><comment><USER28> Scala after 2 weeks = 1 star Scala after 2 months = 3 star Scala after 6 months = 5 star

Show me a statically typed language on the JVM that trumps Scala -- it doesn't exist.

Show me an ecosystem in that statically JVM based language that trumps that of Scala (Akka, Play, Slick, sqltyped, Squeryl, Spray, Scalatra, Lift, Blue Eyes, Unfiltered, etc., etc.)

Yes, compile times are a hassle (for deployment that is, incremental compilation combined with sub projects are plenty fast, usually around 1-3 seconds, it's a non-issue).

Yes, IDE support is nowhere near that of Java's, but it has improved immensely during the past 2 years. Either IntelliJ or Eclipse + ScalaIDE do the trick, am happy on the latter here.

There are only two kinds of languages: the ones people complain about and the ones nobody uses \--Bjarne Stroustrup

<comment><USER16> I had the opposite experience. I went into scala very optimistic, and initially would have rated it 4 star to stick with your rating approach. But after a month it was down to 3, then another month it was down to 2 and we were investigating alternatives.

</comment></comment><comment><USER29> I'd say a lot of the critiques are fair but quite exaggerated. I work on a large Scala codebase and yes, the compile times for a fresh start across the codebase are very long, but TDD-type loops are very short, because you're generally waiting for two files (your test target and your test code). Still, the compiler performance in Scala is perhaps my chief criticism, though hardly a show-stopper. As codebases in any language grow, you tend to have increasing challenges in the time it takes to fire up your environment.

The critique about excessive and opaque operator use in libraries is fair, though I think it actually exposes an interesting philosophical issue. Scala is unabashedly written to be a flexible language. This is in opposition to Java, which was written to be a very strict language in terms of expressiveness on the part of the developer (it's perhaps the most strict of the languages I've worked with, hence it being my example). I personally think a lot of criticisms leveled against Java's verbosity and inflexibility are unfair, by virtue of the following: Many incredibly successful and complex open source projects are written in Java. While you could say this stems from Java's enormous popularity, one interesting property of huge Java open-source projects is that I can usually crack open the code and quickly get a sense of how I could contribute to the system without breaking it. While other languages often do a better job of giving me a sense of how the system works, I generally have much trouble with extensibility unless it's Java. This I believe is because Java was designed from the ground up with the goal of limiting individual developer expressivity in favor of imagining large development teams with limited cross communication.

So--I am far less anti-Java than most. But I am a big fan of Scala. Unlike Java, Scala was written to maximize developer expressivity. While writing Java can feel like putting together a legal contract, writing Scala can feel like creating a poem. I'm not making a value judgement in either direction there--I feel that poetry is a good metaphor, because things in Scala tend to fall apart in the reading department. One of the easiest things to do in poetry is to lose the reader--a great poet can put an incredibly complicated multilayered concept onto a small amount of paper--and require a graduate- level understanding from the reader to understand it. Similarly, one can very easily make Scala into an exercise in unpacking

So isn't that a bad thing? Why am I a Scala fan? Going back to my initial praise of Java--Java is so simple and predictable that it's really easy to see how the plumbing works. But because the plumbing must be laid out so meticulously and in every situation, it is often hard to see how things work at a high level. You can't see an architectural sketch in Java, you can only see endless classes in endlessly nested subdirectories. This is a very low level of abstraction, and helps the layperson (such as someone approaching a new open source project) build up an understanding from the base elements. But what's lacking is the high level abstraction.

Outside of programming languages, almost every knowledge discipline has a high level abstraction language--sometimes multiple languages. Usually the abstraction language is opaque to newcomers, and frustratingly so. Examples are the mathematical notations of various disciplines, the jargon-laden meta- language of historical theory/literary criticism, and what is popularly known as 'legalese'. But even less high falutin' fields have similar languages-- listening to sports fans talking about what's happening can be quite mystifying to me, given all of the shorthand they're using. Similarly people talking about pop culture in areas I'm not familiar with.

These ubiquitous high level languages usually share two important facets: first, in a few lines of text/speech, you can pack in many books' worth of concepts. Second, unless someone has read those books, they will have no idea what you're talking about (or in the case of pop culture jargon, having spent the requisite hundreds of hours watching movies). Scala is trying to provide a language that can express the low level plumbing as Java can, but also that can express the high level meta-language. In doing so, it opens itself to the same type of criticism that mathematical notation can receive--opacity.

The pitfall, then, of Scala library developers is to create a high level meta- language (a DSL), that doesn't have industry acceptance. This is tantamount to mathematicians who create their own notation to establish proofs--such proofs can be completely unreadable to their colleagues. But this isn't a criticism that should be leveled at the idea of notation period--it's a matter of people learning to accept useful obfuscation (where jargon can reduce textual size and increase understanding) and reject useless obfuscation (inventing your own dialect of shorthand and forcing your readers to learn non-transferrable knowledge to understand what you wrote).

Because they are working with such a flexible language, and one that is targeted at building high abstraction languages, Scala library developers need to think of their audience--terseness by itself is not useful, unless you're writing throwaway code. If you're going to unleash a DSL on your reader, make sure it's in a real dialogue with the reader's expected level of knowledge with regards to how such a DSL should be structured in terms of what the symbols should mean and how they fit together.

I don't know how the Scala story will end, but I do believe that it is one of the few languages that reaches for an expressivity goal that needs to be achieved by at least some future language. Its reaching opens it to much criticism, and rightfully so, but I appreciate it for its ambition.

<comment><USER30> Great comment. I agree with nearly everything you said, but where I end up is the polar opposite. I can't stand Scala for all the reasons you mentioned.

The poetry thing is really dead on -- when Larry Wall spoke of Perl -- he said he explicitly wanted you to be able to write poetry with it. This led to the write once, read never reputation of Perl... that Scala is quickly stealing.

Scala is on my "will not work with" list of languages/technologies -- which is generally limited to old languages/tools that I have experience with (like Progress 4GL, Mumps, etc), but don't want to touch. It is a maintainability blackhole and generally horrible (to me) to work with, despite being fairly comfortable with the core (1400 or so hours billed).

<comment><USER31> I've developed and maintained multiple large systems in a team using various languages. I would _much_ rather maintain a system written in Scala than either Java or various scripting languages we've used and the view is shared by the whole team. It's far less verbose than Java and very maintainable compared to other very large systems written in scripting languages.

<comment><USER30> We simply disagree on this. I would rather use almost anything else except the random DSL wasteland that is Scala. Even Ruby or Python (with the horrible GILs) is preferable.

The groups I worked with made different determinations than your team, but if you guys love it, enjoy. Seriously, if you find a technology your whole team loves, you are KILLING it.

Both companies I worked with have since dropped Scala (after literally hundreds of thousands of dollars spent on the attempts) entirely internally due to maintenance and talent acquisition issues.

<comment><USER32> _I would rather use almost anything else except the random DSL wasteland that is Scala_

In my experience very little Scala code uses DSLs. Learning Scala isn't that tricky for anyone who knows Java, which is a pretty big pool.

<comment><USER33> That was not my experience with Scala. Every library we used had its own DSL and that made the code really hard to read. Maybe things are different now, but I'll bet that was a lot of people's first experience with Scala. It's what turned me off to the language, even though I did like using the standard Scala library quite a bit.

Edit: It was two years ago so other than Lift and some SQL DSL I don't recall which libraries we were using. I do recall wishing I hadn't taken that job.

<comment><USER34> My "favorite" part of Scala was half a dosen DB libraries each re-implementing SQL as a DSL.

<comment><USER32> C# does that too. It's called LINQ and it's very popular.

<comment><USER34> Are there a number of slightly different and incomplete variants of LINQ, like there are SQL DSLs in Scala? Because if not, then LINQ is "the right way" of doing this kind of thing. And if I remember correctly, LINQ is also useful outside of the DB domain, for things like filtering arrays and so forth.

I once read an article about how Java programmers can hold a conversation on the topic of upsides and downsides of multiple dependency injection containers while C# programmers only have one available and have nothing to say on this topic. That article concluded that having one "good enough" solution can often be better than having multiple slightly different and incomplete ones, even if each has its own strenghts, and I'd say the same is true when it comes to the C# LINQ vs. Scala SQL DSLs.

<comment><USER32> C# has various options (see: [http://stackoverflow.com/questions/671231/linq- nhibernate-al...](http://stackoverflow.com/questions/671231/linq-nhibernate- alternatives-equivalents))

The Scala equivalent is called Slick, and it's the only SQL DSL that approaching anything near widespread use. I fail to see how incomplete projects on GitHub which happen to be written in Scala are relevent to this discussion.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER31> Overall this is a very weak and one-sided blog post. Even a simple search would have answered his questions about why Scala doesn't use Hindley Milner type inference:

[http://www.scala-lang.org/old/node/4654](http://www.scala- lang.org/old/node/4654)

How this post got voted up to the front page really makes me wonder. "Clojure programmer gives Scala 1 star", what next "Ruby programmer gives Python 1 star"?

</comment><comment><USER35> Scala can be summed up in one issue.

[http://play.lighthouseapp.com/projects/82401/tickets/98](http://play.lighthouseapp.com/projects/82401/tickets/98)

I loved Play 1.x(early adopter also) but I have since moved on. I gave Play 2 a solid chance. Scala programmers seem to turn everything into some kind of academic paper.

<comment><USER36> I've been a critic of Play 2 on a number of occasions on HN but I don't understand the complaint. What is causing you to create URLs with trailing slashes?

<comment><USER35> What is causing you to create URLs without trailing slashes? 99% of all web frameworks allow for optional trailing slash. Go to any website. A url with or without a trailing slash typically works, it either redirects to no trailing slash or just renders the same page.

<comment><USER36> What is causing me to create URLs without trailing slashes is the proper use of Play's route-to-URL mapping system. I don't emit trailing slashes because Play doesn't.

</comment></comment></comment></comment><comment><USER37> > The workflow I ended up with was to write a function without any type > annotations. Ignore all the red lines of the IDE's confusion. Compile the > code. In the output look for a warning about (Long => Int) return value > being ignored in a function returning Unit. Copy (Long => Int) into my code > as the return type annotation of my function. Compile again.

That sounds like the most stupid way you could do things.

</comment><comment><USER38> Question - the job/hiring post on hen for November has many positions for clojure and one definitively for Scala. Here, I see references to investment banks using scala.

Has scala become a readable alternative to java, while most of the future focus is on clojure? Does anyone know how real life performance compares between both.

From my viewpoint, scala is in use at several banks and Twitter - <USER2> doesn't really have a big name advocate behind it. From a startup standpoint, isn't talent/hiring an issue?

<comment><USER39> There are some big places using clojure - the Daily Mail uses clojure heavily for it's website, as do SoundCloud; also, like Scala, it's used internally at some financial institutions - CitiBank have some clojure, and we've been using clojure at IOOF (an Australian superannuation company).

Performance is probably the last thing you need to care about when choosing a programming language for most businesses - unless you are doing hard-core analytics or handling huge scale, you just won't hit the sort of performance problems that are solved by a faster programming language (as opposed to a faster algorithm or architecture).

It really frustrates me that people _still_ put such weight on low level performance. In 1997 I had people saying "don't use Java, it's performance is far worse than C++". It was mostly untrue for business problems then - <USER3> computers are many orders of magnitude faster now.

<comment><USER40> Some other examples are Prismatic, Runa (recently bought by Staples), Climate Corporation (recently bought by Monsanto), Twitter (via acquisition of Backtype), etc. And there are a number of other big name companies very quietly using it to just get stuff done.

</comment></comment></comment><comment><USER41> I think Scala is great as long as you stay on the road and not end up in the deep depths of academic hell (i.e. [http://blogs.atlassian.com/2013/01/covariance-and- contravari...](http://blogs.atlassian.com/2013/01/covariance-and- contravariance-in-scala/)).

I should say one thing however:

I'm using Scala because of Akka. An extremely powerful library that does a good job of hiding the complexities while still allowing you to be flexible.

<comment><USER42> That's a gratuitously category-theoretic explanation, all you need to explain covariance and contravariance is is-a.

An immutable List of Foos is a List of Bars if a Foo is a Bar. A function taking X and returning Y is a function taking A and returning B if A is a X and Y is a B.

It's just answering the question "Can I use type relationships to guarantee that I will have no run-time conversion failures?"

<comment><USER43> T is covariant (positive) if A ≤: B ⇒ T<A> ≤: T<B>. T is contravariant (negative) if A ≤: B ⇒ T<B> ≤: T<A> (i.e., the other way around). Pretty simple stuff.

<comment><USER13> It is easy to remember if you think of it:

\+ (covariant): the type can be cast to some _broader_ (more general) type

\- (contravariant): the type can be cast to some _narrower_ (more concrete) type

</comment></comment></comment></comment><comment><USER13> I agree partially with the critiques.

The things I don't like in Scala:

1\. Compile times. It _is_ a problem for big projects. SBT / FSC helps quite a lot, but IMHO it is still not enough. I hope they get them much better in Scala 2.11. Also performance and correctness of the IDE plugin typechecking could be better, so I don't have to compile that often.

2\. Lack of backwards binary compatibility. Source compatibility is ok, but selecting the right version of all the libraries is pretty painful, especially if the authors of the library didn't make the packages (yet) or they haven't been deployed to maven repo, etc.

3\. That some elegant code constructs come with sometimes huge runtime performance penalty. It got much better recently (e.g. for loops are as fast as while loops now in Scala 2.10), but I feel it could be better. Again - <USER4> Scala 2.11 addresses those concerns at least partially.

The things I don't agree with the OP:

1\. Documentation - it is awesome.

2\. Syntax flexibility - many times DSL is a better way of expressing things than just a bunch of methods, and easier to learn.

3\. Tooling - good enough now, and improving fast.

4\. Type inference - I consider it good enough, albeit not perfect. And types in method signatures add a lot to code readability.

There may be some languages that have better IDE support, faster compile times, better type inference, richer type system etc. But none of them supports full feature set of Scala, particularly all the available libraries. So IMHO taking every single feature out from Scala and comparing it let's say to Haskell or ML is ridiculous.

</comment><comment><USER44> Yegge said it best 5 years ago. [1]

"The... the the the... the language spec... oh, my god. I've gotta blog about this. It's, like, ninety percent [about the type system]. It's the biggest type system you've ever seen in your life, by 5x. Not by an order of magnitude, but man! There are type types, and type type types; there's complexity...

They have this concept called complexity complexity<T> Meaning it's not just complexity; it's not just complexity-complexity: it's parameterized complexity-complexity. (mild laughter) OK? Whoo! I mean, this thing has types on its types on its types. It's gnarly.

I've got this Ph.D. languages intern whose a big Haskell fan, and [surprisingly] a big Scheme fan, and an ML fan. [But especially Haskell.] He knows functional programming, he knows type systems. I mean, he's an expert.

He looked at Scala yesterday, and he told me: "I'm finding this rather intimidating.""

[1] [http://steve-yegge.blogspot.com/2008/06/rhinos-and- tigers.ht...](http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.html)

</comment><comment><USER45> I've been using Scala just to learn Play framework (I know I could use Java but I thought I'd be adventurous).

I think in truth, though, if there were a web framework in Clojure as well received as Play I would be bounding down that path instead. Clojure seems to be where a lot of the JVM interested is heading yet we're not there yet for some reason.

<comment><USER46> I've been wondering - having never used a web framework except for some RoR - what people miss in the idiomatic Clojure way of doing web (composing libraries like Ring, Compojure, Enlive etc). Care to share?

<comment><USER47> I was a full-time Rails developer until a crescendo of disillusionment finally cajoled me to learn Clojure.

I don't really know that I miss anything. The things I might've thought I'd miss are the things that ended up souring the taste of Rails.

Having to come up with my own abstractions or recreate familiar conventions or set up a database were areas where I had to cut my teeth, but I also had to cut my teeth on Rails when I was learning it.

Rather than missing anything from Rails, I find myself using Rails' conventions as a loose model and then simplifying it. For example, my "templates" are now just functions that render html. My "layouts" are just functions that get applied to templates. I don't need to read Rails' template rendering guide to come up with a hack. Instead, modifying my templating system is trivial and obvious.

<comment><USER48> Thank you for this comment. I'm starting a hobby webapp project and wanted to try Clojure but was probably going to choose RoR out of fear. Now I'll use Clojure :)

Would be interesting to see a blog post demo'ing your workflow.

<comment><USER49> Not the parent, but I went through a phase of blogging about Clojure earlier this year: [http://adambard.com/blog/Getting-started-with-Clojure-web- ap...](http://adambard.com/blog/Getting-started-with-Clojure-web-apps/)

</comment></comment></comment></comment></comment><comment><USER50> To be honest with you, I use Scala as a better Java. Which means I still code imperatively (and use null instead of None) but with less noise (semi colons etc).

But, esp when working with collections, I take advantage of Scala's features. It's not perfect, but it works wonderfully. I can always revisit/refactor my code again later.

<comment><USER51> Using null instead of None means you are more at risk of hitting a NPE.

Here are a couple examples:

myVar match {

      case Some(val) => doSomething(val)

      case None => handleNone()

}

myVar.getOrElse("else")

In both of these cases, we eliminated the possibility of a NPE through the use of a language feature. :)

(edited for formatting)

<comment><USER52> > Using null instead of None means you are more at risk of hitting a NPE.

I think he's aware of that - he said he's using Scala as a better Java, what would Java be without the odd NPE?

</comment></comment></comment><comment><USER53> I am seeing just too much criticism for Scala and the coherent theme seems to be - "I didn't take time to understand the language well and then my pride got hurt as I couldn't understand it's constructs. So Scala is shit and too complex."

I am not from CS background, but I took time to learn it and by far it's THE most natural and expressive language I have found AND I don't even know what functional programming and the theory is, all I know I learned through Scala.

Please guys, let's not project our laziness as a fault of Scala.

</comment><comment><USER54> The Scala code I write looks very similar to the Clojure code I write. But has the advantage of (optional) static type checks.

What I care about is that a language lets me express easily the concepts that are in my head. Scala does that and because of its type systems makes it even possible to document these concepts in a mechanically verifiable way (only up to a certain extent, of course).

</comment><comment><USER55> I feel you. I tried Scala out and after several days I just uninstalled everything from my computer which was related to Scala. The main reason is that it feels like some extremely baroque java without any sensible syntax. It looks like the C sytax but in fact it is not. Return types are sometimes explicit sometimes implicit. If you try to learn Scala you have to forget anything you know and learn the over-engineered ways of Scala. And in the end you don't get anything back which is not accessible in other languaes in a significantly easier way. You want functional style and easy concurrency? Go clojure. You want scalability for your webapp with 999999999 visitors per day? Go node. You want scientific calculations with good library support? Go python. You want a sensible type system and monads? Go Haskell. Scala just does not have much to offer in exchange for the terrible pile of contraptions it forces you to use.

</comment><comment><USER56> The section on HTTP headers and typing is a little concerning to me. I've been making rust-http recently and (before I was aware of Spray) I felt strongly about the typing. So, I'd like to discuss this. Am I wrong after all? Here clearly is someone that disagrees with me. I think I should probably write up a long blog post on the topic explaining my reasoning and so forth.

rust-http is, at present at least, rejecting the standard practice of stringly typed headers and is using strongly typed headers.

> ... and even types for every 'known' HTTP header.

> The known HTTP header part was particularly ridiculous. HTTP headers are > _defined_ as simple key/value pairs. You're supposed to be allowed to add > arbitrary headers. You're not supposed to be constrained by the framework > you're using not having any support for CORS yet.

He has taken a strong position against this strong typing; I take a similarly strong position _for_ such strong typing.

Yes, HTTP headers are defined as simple key/value pairs. But headers are _not_ text; they are _data_. XML is defined as text. Should we use regular expressions to work with it? (True, it also has the DOM defined. But HTTP headers _also_ have a grammar defined—it just happens to include the admissibility of extension headers.)

HTTP is a serialisation format for messages; messages made up of computer- readable data, not text.

I wrote a handful of paragraphs about this subject at [https://github.com/chris-morgan/rust-http/issues/1](https://github.com/chris- morgan/rust-http/issues/1) where using a map instead of typed headers was suggested.

As I also note there, I would not attempt such a scheme in a language like Python (my primary language for some years) because its type system is not well adjusted to something like this; I am certain it would cause many problems and feel it likely it would cause more than it solved. But in a language with a solid type system capable of expressing these things, taking advantage of it should lead to a faster, more correct program.

In the end, I believe strongly typed headers are a good thing to have (it will actually make most code distinctly nicer—e.g. ``response.headers.date = Some(now())`` instead of ``response.headers.set("Date", now().to_http_header())``). The implementation of the scheme in rust-http is certainly not perfect yet; I'm not happy with it at present; I'm expecting to turn the extension headers into a trait object, and I've even considered crazy ideas like allowing users of the library to make their own header collection (request.headers and response.headers) types—that would allow custom headers to be made first-class citizens but could lead to compatibility problems.

Still, I don't want to make something that I believe should be the best HTTP library around and find that people hate to use it. What do you think about this header matter?

<comment><USER57> But what practical problem is such a scheme actually solving? If I write

        response["headre"] = ...

I have a bug, sure, but an obvious bug that will be fixed very quickly. With this type system I am now limited in an annoying way. I don't get it.

<comment><USER58> > I have a bug, sure, but an obvious bug that will be fixed very quickly.

People say the same thing about null pointer exceptions, but null pointer exceptions are a huge problem in practice. Every bug is "obvious" in retrospect.

<comment><USER57> No, this is not the same as a null pointer. Null pointers are typically much more sneaky, this line means the header will not be written and the error is right in your face.

I do understand the desire to prevent these sorts of errors at the language level, but not at the cost of functionality. I don't agree with this one, but I do (for example) appreciate libraries such as the STL which (hopefully) prevent that pointer issue you brought up (and more). The STL doesn't (often) force me to work around silly limitations though.

Does this library provide for creating arbitrary headers in some other fashion? If not, why?

</comment></comment></comment></comment><comment><USER27> Method names like ~, %, %% or #> are terrible in Scala! This should be generally banned as bad practice. There are too many developers creating obscure and unreadable code with such method names.

I even thought to create readable adapters for common APIs like SBT API.

</comment><comment><USER59> If anybody really wants to learn Scala, I'd recommend starting with the video lectures on Coursera for the course Functional Programming in Scala.

</comment><comment><USER60> A disagreeing comment wrt OP. Hope it is useful to some.

On the library criticism ... Well, pick better libraries, use java libraries, or roll your own. You have twice the choice you have in java. Is that bad, or good?

Yes, there is immature stuff. Well for the lawyer rate you are charging, should be able to separate that from the good bunch?

The complexity - In my experience, learning curve is gradual in that you can pick new features when you need them. You can pretty much get by writing javesque scala with a bit of closures in the begining. Then take mixins, then take the hardcore stuff when you feel comfortable.

About the build system - here I was surprised. You seem pragmatic, why use it? To me SBT is totally useless because it solves nothing existing tools do not solve. The Scala support in Maven is perfect, and i feel so productive and mature in it these days, I would never trade unless there is a very strong selling point (meaning more free time for me to drink beer, whatever) If you don't like Maven, code in Ant. But using a build tool which is a general- purpose language? I agree with you. Baaaaad idea

</comment><comment><USER61> Having used Scala for over a year, I can say it is a mixed blessing for me.

On the one hand it's an improvement over the verbosity and rigidity of Java. And often it is fun to write in (lots of clever tricks you can use and feel good about... until you have to come back to the code several months later).

On the other hand, I absolutely hate to dig into Scala code written by others. To me it feels like C++ all over again. There are so many concepts in the language that more often than not you find your knowledge of the language lacking, and have to put the task at hand on hold to brush up on your Scala skills. If there are more than a couple of (Scala loving) codevelopers on the project, you end up spending more time learning about the language than actually using it.

So, to sum it up: I would use Scala if I absolutely had to use JVM and I had control over the the subset of the language used in the codebase. Otherwise, I'd pick something else. Thankfully, there are saner alternatives to JVM these days when it comes to high level/static typing/high performance (e.g. Go).

</comment><comment><USER28> Agreed, SBT plain sucks _without IDE support_ to guide you. If you have IDE support for your /project/*.scala SBT file(s) then the various symbols and conventions make sense as you can click through to _discover_ the library -- huge difference between that and blindly typing away in a text editor; the latter is a recipe for insanity ;-)

</comment><comment><USER34> They say that for a successful c++ project you need to first define which parts of the language you're not allowed to use. For Scala projects it's even more so. And you can only hope that all the libraries you'll be using provide some sane method names that map to all the insane operators they invented to do the same thing.

<comment><USER62> To this point, I've heard "Scala is the C++ of Java."

</comment></comment><comment><USER63> My problems with Scala:

1) src/main/scala/com/thingy/actualthingy _JUST_ to get to the root of your code. 2) Recompiling/restarting is slow because liftweb and other frameworks are overly complex. 3) I'm 90% sure it would be possible to create a PRY-like debugging tool that runs your code in interpreted mode and drops you into the REPL at a certain point in your code. And yet, it'll never get built because Scala hackers are stuck in the halcyon java days of 1998. 4) Variable names first, types second = okay, now you're just being different for the sake of being different.

That said, it seems like if you use scala as a more concise java with some handy functional syntax thrown in, you can make something that isn't terrible for future maintainers.

<comment><USER6> 1) You don't have to do that, Scala doesn't enforce the folder/package hierarchy that Java does. Moreover, you can use any folder hierarchy you want.

2) Compiling Scala is slower than Java (sometimes much slower) but that's not the frameworks' fault. scalac is just slow, though getting better.

3) This does exist. In fact, it's built into the language. You can also use "sbt console" to load a REPL with your entire project in the classpath.

4) As the other reply said, type annotations aren't required. In that light, Scala's syntax for type annotations makes sense.

</comment></comment><comment><USER64> I thought HyperTalk was killed by Apple, but a quick search reveals several open source implementations of the programming language. It has been the easiest programming language to learn in my experience.

</comment><comment><USER65> > This issue reached its pinnacle for us when we were unable to figure out how > to replicate the magic response composition syntax used by Spray to abstract > away the addition of CORS headers to HTTP responses.

I'd just put any kind of application, whether built in Scala, node.js or Go or ruby on rails behind a nginx proxy and use that for setting the headers. That simplifies a lot of things. I hope your HTTP headers aren't really so dynamic that you need to build software that changes them so much, especially not for a RESTful application.

<comment><USER66> Say you are building a redistributable app with Javascript clients. People will deploy in behind Ngnix, Apache, IISm ad sometimes with nothing at all.

The _last_ thing you want is to make the deployment harder.

</comment></comment><comment><USER67> Horribly misinformed. Author didn't learn basics of the language - "val" vs "def" is very fundamental - constant vs. function. Scala does not use Hindley- Milner.

Legit issues: compile time (of course), library docs (maybe), bad HTTP header API (maybe), tooling (maybe). I thought the automatically generated (doxygen style) library docs were fine when I was playing with Scala two years ago.

</comment><comment><USER68> Scala looks sexy, sort of like weird haircut.

But once haircut fascination is over - people expect you to do mundane tasks, like cook food or take out the garbage. Or they won't pay you.

And then you realize that when Scala cannot do what you want - you can always revert to Java.

And then you realize that you don't really need Scala-ing if you can do the same stuff in Java or any other strongly typed language.

<comment><USER10> >And then you realize that you don't really need Scala-ing if you can do the same stuff in Java or any other strongly typed language.

That's the turing completeness fallacy. Why not just write everything in C? And java's types are inadequate for doing really generic methods - how would you go about writing scalaz's "sequence" in java?

</comment></comment><comment><USER69> "My theory is that it was designed to experiment with advanced type and language features first, and only secondly became a language intended to be widely used." \- I have same feeling about F# sometimes - OCAML is cool but too academic to be approachable.

<comment><USER16> >OCAML is cool but too academic to be approachable.

Can you give an example of what you mean? I used ocaml for a few years, and never encountered anything I would consider academic at all, much less unapproachable.

</comment></comment><comment><USER70> This is my view on scala as well. I used it for one project and will not be using it again.

</comment><comment><USER71> It's a little late to talk about Scala like that. There are very nice improvements on each of those topics you complain about. Of course still there are many works to do but for now there is no other language with such potential IMO.

</comment><comment><USER72> So I am curious what npm gives you that sbt doesn't. I have heard it a few times how much better npm is but i haven't seen anything it does that sbt doesn't

</comment><comment><USER73> As someone looking into learning a different JVM language, and who has started reading Scala in Action, I find this article and thread very useful.

</comment><comment><USER74> If nothing, at least i completely agree with complete disregard to compatibility point. Be it Scala itself or driving frameworks like Play.

</comment><comment><USER75> _something weird with attaching anonymous functions to method calls_

that's still a thing? i thought i was just being dumb back in the day.

</comment><comment><USER76> Programming languages are very much a matter of de gustibus. So I respect the writers experiences. But I have a slightly different perspective.

Let me first say where I'm coming from. I like: a static typing. b support for FP and OO c targeted for JVM.

Compile times It is my experience that compile times are not that bad if you use the support by SBT for continuous compile-deploy-test. Have a look at Typesafe Activator to get a feel what they're moving towards.

Libraries and community I do agree that some frameworks, like Spray f.i., tend to overdo the concise DSL aspect. This seems to be especially prevalent with Scala developers coming from the academic world of monads. Or with a strong tendency to show of how clever they are to the detriment of usability. Scalaz had a strong similar tendency. I have noticed that frameworks like SBT and Scalaz are de-emphasising unpronouncable ungoogleable unintuitive operators. So far I have hope that the Scalaz community will veer away from this. To a certain degree every language community develops a culture about good vs bad code. Twitters Effective Scala guidelines are a wonderful contribution.

Magic syntax I've been using the Play framework for webapplications. And in my experience that is largely a pragmatic tool where I can just get things done. My main criticism would be that sometimes new features seem to be not very well tested. F.i. multi project support did not really work for quite a few versions. That shouldn't take up much time. I hope they address that.

Type inference Coming from Java I like Scalas type inference. Although the compiler feedback can sometimes still be challenging. There has been great work in compiler messages giving advice on how to fix mistakes. F.i. the well known mistake of forgetting the = between a function declaration and implementation. But there are still hairy situations. If you've ever had the infinite recursion type error (being addressed in newer version of the language) you know what I mean. Or using the json parser combinators in the Play framework with classes with one attribute f.i.

Other issues he mentions: \- build tools. This has significantly improved since Typesafe started. I'd say that before that Scala wasn't suitable for non academic use. There are still improvements to be made like speed, usability of SBT, maturity of the Eclipse based Scala IDE... \- repetition of case classes. I have no idea what is meant with that. I think that writing a model of your domain in scala is a truy joy compared to java. And pattern matching and standard marshalling/unmarshalling to json etc is great. \- the language being inaccessible and experimental. This is not my experience at all. Like any language it takes learning. But if you're looking for a language that supports both FP and OO I find it very coherent and well thought out. I'd say beautiful even. For me the coursera courses on FP with Scala and Reactive programming with Scala have been the critical power boosts in becoming proficient enough to make the transition from hobby interest language to professional everyday tool. \- 'if you want true strong type systems use Haskell'. To me the 'impurity' of FP in Scala is it's strong suit. On the one hand for getting stuff done and on the other for using the vast ecosystem of JVM libraries and frameworks. Also I think that the writer will encounter quite a few inscrutable operators and overwrought type systems (like his complaint about Spray) in the world of Haskell.

To finish up I'd like to state what I like about Scala: \- FP in the real world of web applications and mutable state. Accessibility to colleagues who come from OO & Java \- Well thought out coherent language. Especially in combination with the Coursera courses I have just become a better programmer and system engineer. \- Good interoperability with Java frameworks etc \- good support for horizontal scaling, near realtime processing, non-blocking processing etc ie reactive programming.

Some things I have mixed feelings about: \- reinventing the whole Java stack. It is true that f.i. non-blocking support has a pervasive 'disruptive' influence. But for me there's great value in mature well know libraries, server, frameworks that just work. \- sometimes there are very common use cases that need quite a bit of research. F.i. it's not easy to find out what the 'canonical' way of processing xml is. \- stability and documentation

MMDV (=My Mileage Did Vary)

</comment><comment><USER77> Just shut up and use Java. It's fine.

<comment><USER78> And with Groovy as a scripting layer, it's more than fine. Quite good in fact.

<comment><USER79> Is Grails as good as they say it is?

<comment><USER45> I think it may be but I came to the Java ecosystem to escape RoR.... it seems we should be able to do better than emulating Rails minus the existing gem community, no?

I have much more faith in the JVM but would like to see it provide a step _beyond_ Rails rather than catching up. Play is nice because it is trying to accomplish this with Akka, though yes I see there are other issues. As mentioned in another comment, I'm kindof just wishing there was a cool Clojure framework. Maybe I will try one even there is not so much of a consensus as there are around these other emerging JVM frameworks...

<comment><USER49> Clojure doesn't tend to do frameworks on the scale of Rails; all the components exist, but the price for your application only including the parts you use is that you're more or less expected to write the glue code between them.

Think Sinatra instead of Rails.

<comment><USER45> i suspected this may be more the case, thank you for confirming. and this has made me nervous, since i don't find sinatra to be all that powerful.

buuuut as retrogradeorbit points out.... the clojure macro system is powerful, so maybe it lends itself better to this type of setup

</comment></comment></comment></comment></comment></comment><comment><USER69> "serious JavaScript development" \- best oxymoron I have seen in a while!

</comment><comment><USER80> So, you switched to which language exactly? Sure we can follow a good example.

</comment><comment><USER81> This is wonderfully written, thank you.

</comment><comment><USER82> I think that many of these criticisms, while perhaps valid in some ways, are unfair. Why single out Scala, when other, more popular languages have these same issues? The intent of this post seems to be to discourage using Scala on any project again, but it is difficult for me to discern the proposed alternative. Is it Haskell? A fine language, but seems to lack the tools that even Scala has, and it's not on the JVM. Is it JavaScript? Java? I'm not sure which comparisons to make. So to address each point:

The compile times criticism is probably one of the more valid ones. Was incremental compilation enabled in Gradle, though? It was only specified that daemon mode was used.

The libraries and community criticism, I think, is completely unfair. There are lemons in every community. Part of getting to know an ecosystem is learning the parts you don't like. For example, I don't think that anyone should attack the entire Java ecosystem simply because Java EE with its EJBs exists, or because Struts exists, or WebSphere.

Is the magic syntax criticism specific to Spray and SBT? But I thought that Gradle was the build system, and that's in Groovy. I'm a bit confused, here. Again I think this is about picking libraries you find readable, and again I think it is not fair to judge an entire ecosystem because of one or two bad library choices.

The HTTP header criticism...is this about Spray again?

Not using Scala because it doesn't have Hindley-Milner type inference is not fair, either. This seems like an unusual standard for which to hold any language, really. Is it only ML languages like Haskell that have this?

Really I'm not sure why any or all of these would make Scala an inaccessible language, or even what inaccessible means in this context. Is it simply that Scala has too many language features? So should we all go back to BASIC? Or is Java the answer? But wait, Java is adding more language features, too! Where do we draw the line? In the Java world, there are so many libraries that provide the functionality that Scala has baked in. Are using third-party libraries such as Guava, Project Lombok, and LambdaJ really preferable to using Scala?

I definitely agree that you can make code unreadable by using too many language features or libraries, but it should be agreed upon what the best practices are for a project between its developers. For instance, on a Java project, everyone might be using JUnit and Mockito for unit testing. Then one day, a single developer decides he wants to introduce PowerMock or something, instead. His pairing partner could explain to him why this is a bad idea; or it could be rejected in a code review or similar. The same idea holds for Scala, I think. If not everyone understands something like implicit types, they should be avoided.

</comment><comment><USER83> There's a lot that could be criticized about Scala, but that article is a criticism of the author, for me who actually knows something about Scala.

It starts with a criticism of a build system that is most likely SBT. Now, for all its strengths, you could not pick an easier target than SBT if you wanted to bad mouth a piece of Scala software, but what we get is:

* It is slow to recompile the build definition (true, not the most complex build files I ever saw ever took anywhere near that time); * I didn't bother to learn the syntax (or what was going on).

Is that it? If all you have to complain about SBT is this, then you never actually made even a passing attempt to learn to use it. That doesn't make me much confident about the author...

Next, the author has been writing Scala code for the past _two weeks_. Scala is not, I argue, as complex as people make it to be, but it has enough _different_ concepts than what most other languages offer that you simply don't pick it up in two weeks, just like you didn't learn your first programming language in two weeks.

If you come from Java, two weeks of Scala let you use Scala like Java: you'll produce working software, though not in any idiomatic style. Well, we pick later on that the team is using Spray, and Spray is a _very_ idiomatic library. You do have to unlearn many habits to pick it up, and the author doesn't seem interested in unlearning anything he "knows".

He picks Scala because, hey, there were doing XSL and doing XML processing, so Scala must be good at it, right? Well, actually, no, but I can see why one would think that, and also why one would be disappointed that it actually isn't, but picking the wrong tool doesn't mean the tool is bad: it's just not the tool for that.

So we go to TDD, where he comes up on Scala awful compile times (which troubled him with SBT before). That is a problem that Scala community has faced, and it has produced solutions to that problem. Specifically, it has adopted SBT, a build tool which can compile incrementally (and automatically on change), and even execute just the tests that are affected by a change (automatically as well).

Of course, the author, having chosen Scala, decides to ignore the existing solutions and picks up Gradle, which supports none of this. Now, Gradle is a very nice build system, but, again, the author picks the wrong tool and proceeds to blame the wrong thing from it.

Next, the author proceeds to have problems with libraries -- problems somehow not shared with the rest of the community (see comments by other Scala users). He mentioned stability problems, and then mentions two pieces of software with excellent documentation, extremely stable, and supported across a broad range of versions of their dependencies.

Now, choosing Spray when you are not familiar with Scala was a terrible decision, and I can well see where the author had trouble using it -- while not agreeing there's any problem with Spray itself. Having trouble with Specs2, however, makes me seriously doubt his abilities -- if he truly had trouble with it.

Next he proceeds to some discussion of simplicity, and I'd grant that Scala is not simple. However, he ties that to a lack of regularity, which is interesting in that Scala is _highly_ regular, much more so than Ruby. It just allow different things than the languages he is used to, so it _looks different_.

I can buy "looks different" \-- yes, it does. But the author's inability to realize how regular it is just goes to show that he has a very, very poor knowledge of Scala. That's not a problem with Scala, it's just that he didn't learn Scala, and it keeps showing.

So, having not learned Scala, he tries to accomplish something that required a specific Scala knowledge he lacked and fails. And somehow that's Scala's fault and Spray's fault, not his.

Well, I admit it: if you don't learn Scala, it is very difficult to program in Scala. That's certainly not the case with PHP, for example, but I have certainly struggled with rather simple tasks in Ruby when trying to write code in Ruby without learning it. I just never blamed Ruby for it.

Next, "everything is a type". I disagree that this is in any way a problem -- if you are going to complain about that, how about just writing "Scala is a statically typed language" and leave it at that? We all knew that, didn't we?

So, having chosen a statically typed language, he dislikes the fact that it actually tries to use types? Weird, but at least he doesn't make it a problem of Scala itself.

On the other hand, it took me thirty seconds to find RawHeader, which allows arbitrary headers, which indeed would be a weird thing to be missing. It's right there, among the other headers. Among, say, Origin and either Access- Control-* headers, which happen to be the CORS headers, all of which appear in the API docs, so what gives?

Maybe they are new headers? Well, the CORS headers are new, if not _that_ new, but maybe the article refers to something that happened months ago. The raw header is there for quite a while, as you can see for yourself here: [https://github.com/spray/spray/blame/master/spray- http/src/m...](https://github.com/spray/spray/blame/master/spray- http/src/main/scala/spray/http/HttpHeader.scala)

At this point, I don't even know where the author is coming from, that he failed to spot this. It is certainly not Spray's fault, much less Scala's.

Next comes a rant on lack of H-M type inference. Well, we all would have liked to have more type inference (without making the compiler even slower!), but separate compilation, subtyping and full type inference is not a solved problem. Which doesn't mean we can't gripe about it.

But there's a damning comment among it: the error message he describes in his "workflow". Hey, Scala _infers_ the return type, so he doesn't need to add it, unless he's doing recursion of calling overloaded methods. If he were doing that, however, the error message would be different.

What the error message says, however, is that he is using _procedure_ syntax -- that is, a method returning void in C/Java parlance -- when he actually intended the method to return something. He doesn't need to add the type, he just needs to use the correct declaration:

def method() { body } // procedure (unit-returning method)

def method() = expr // function

He spent two weeks programming in Scala, then went on to write a blog about it, but he still hasn't figured out a simple detail like this, despite the compiler telling him what the problem is?

Yes, beginners might well struggle with this oddity, but _for two weeks_??? And despite having fixed it throughtout the program? Really?

Now, detour briefly through long vs int, which I actually agree with, but saying he was "reminded" of it shows a complete lack of familiarity with statically typed languages.

Again, fine that you don't like statically typed languages, though I think one ought to first _learn_ one of them before criticizing, but you could start and end your post with "I don't like statically typed languages".

Then there are other issues which he enumerates but don't describe, and which I can only disagree with. Horrible repetition required by case classes? Err, what repetition?

So, in the end, it seems that what the author really wanted to say is: I don't like statically typed languages, and I tried to use one for the wrong reasons, in the wrong way, without learning it, and failed. No need to blame Scala for his bad decisions.

</comment><comment><USER84> Because of Clojure's dynamic typing and idiomatic use of lots of nested expressions it turns out to be a read-only language for me.

Scala seems to have a huge image problem. I think part of the problem is that Odersky and crew have never written the treatise on how to use Scala's OO and FP effectively. I'm surprised that Typesafe didn't come up with their own web framework instead of using Play.

One lesson to be learned is that these days you need good IDE integration and fast compiles (incremental) for rapid development. But Scala IDE support has come a long ways in the past year or so. The Eclipse Scala worksheets is awesome. I like it better than a standard REPL. Intellij support is still going strong too.

</comment><comment><USER22> As a java Dev I have been watching Scala to see what people make of it. It seems like Scala is generally perceived as an academic exercise.

We all want more powerful tools and infinite expression but at what point are we bikeshedding languages instead of building transparently clear solutions?

Scala seems to be solving problems i dont have.

<comment><USER85> There's a lot of "seems" going around from people who haven't used the language, or dynamic-typing folk who obviously aren't going to pick a language that bets the farm on static types.

As a long-time Java dev myself, Scala is solving problems you don't even realise you have, because you don't know to look for them.

Powerful types, immutable state and FP make a world of difference for writing clear solutions, with better abstractions, less code, less bugs and less bullshit than the horrendous status quo of corporate Java development.

<comment><USER86> > less code, less bugs and less bullshit than the horrendous status quo of > corporate Java development.

It may take some getting used to syntax and design wise, but being able to code things up in 1/10 the size of other languages completely blows away the disadvantages of Scala.

</comment></comment></comment><comment><USER87> In every critique of scala, there is this: [http://i.imgur.com/KrNcIGt.jpg](http://i.imgur.com/KrNcIGt.jpg)</comment>


The Case of the Missing Stars: Why a Startup Community Can Thrive Nonetheless - <AUTHOR> http://blog.fairsoftware.net/2009/11/15/the-case-of-the-missing-stars-why-a-startup-community-can-thrive-nonetheless/ <comment><USER2> Is it just me or does the article just leave me hanging around? Apparently the title is non descriptive of the article. Nevertheless. Here is what i think.

I belive (rather solidly and logicly) that the ONLY thing behind a succesful startup are:

1\. A good aesthetic design 2\. Hardworking management team 3\. A good backing community 4\. Proper massive SOCIAL publicity. 5\. Be original, innovative and DIFFERENT

SOcial Publicity is what counts the most. If your startup gets coverage, it will be a hit!

</comment><comment><AUTHOR> Read til the end, the conclusion is not what you think.</comment>


Why our economy may be headed for a decade of depression - <AUTHOR> https://nymag.com/intelligencer/2020/05/why-the-economy-is-headed-for-a-post-coronavirus-depression-nouriel-roubini.html <comment> kube-system > Because tomorrow, every piece of consumer electronics, even your lowly > coffee machine or microwave or toaster, is going to have a 5G chip. That's > what the internet of things is about. If the Chinese can listen to you > through your smartphone, they can listen to you through your toaster. Once > we declare that 5G is going to allow China to listen to our communication, > we will also have to ban all household electronics made in China.

This is a ridiculous conclusion. Even if we make the generous assumption that people want internet connected toasters, we're likely not getting rid of WiFi. And even if we did ban hypothetical 5G toasters, manufacturers in China wouldn't shut down their factories, they would simply make different toasters.

It is hard to take this article seriously as legitimate analysis after reading things like this.

<comment><USER2> The article just want you to believe that 'The Chinese' would want to put a microphone with 5G into your toaster.

So that they could listen to YOU through the said toaster, because whatever shit you said near the toaster is obviously very important to the Chinese.

Is there a more moronic idea? If someone were to listen to you, wouldn't it be easier to say... do it through the phone?

<comment><USER3> Putting a microphone in the kitchen is probably one of the best ways to spy on people in their homes.

The kitchen is a natural gathering place, and spot for conversations.

And if I thought someone was spying on me, I would check the inside of my toaster last.

<comment><USER4> > And if I thought someone was spying on me, I would check the inside of my > toaster last.

I assume that organizations that spy for a living learn from their previous mistakes and the natural selection effect means that the obvious places to plant bugs are skipped.

</comment></comment></comment></comment><comment><USER5> I'm trying to decide where the line between sound economic advice and scaremongering sits. I think it may be around "You're going to start having food riots soon enough."

At least I hope that's scaremongering. Given that everyone is doing their best to return to normal, I feel like running out of unemployment may not be as big of an issue as stated.

<comment><USER6> Wait what? Unemployment payments are the only things that are preventing a full scale depression and hardship for millions. These people have lost their jobs, have no savings or assets, nothing. How are they going to get food? Pay rent?

The quick action by Congress in boosting unemployment payments has been the only thing keeping the economy from going belly up. If that stops, we're in for a lot of hurt.

<comment><USER5> He argues that that's going to happen in July. I just can't see the States letting that happening. Here in Canada they are continually expanding out benefits, and I think the States will have to follow that as well. I can't see the tap being just turned off.

<comment><USER7> There are enough people completely divorced from reality in congress and in and around the presidency that it will potentially get incredibly hairy. I can absolutely see it getting to the absolute brink before they suddenly realize "oh shit this is bad" and pass an emergency "freedom payment" which again will be a one time thing and not be completely enough.

My pessimism says we're also going to be dancing from one stimulus to another without addressing the long term

<comment> kube-system The federal stimulus never was nor was intended to be a long term solution to anything.

Social safety nets in the US are mostly handled at the state level, and that doesn't look like it's showing any signs of changing.

<comment><USER7> what happens when the states run out of money though, that is ultimately the problem. how long are the states going to be able to keep up without federal intervention?

</comment></comment></comment></comment></comment></comment><comment><USER8> Think of all predictions as set of possible outcomes. Yes, there is a possible decade long depression outcome. Based on my reading its W recovery staggered growth, with US pulling back all its supply chains to North America and Export-Oriented economies holding the bag.

These economic and global dislocations resulting in events we have not seen Post-WW2.

In spite of all these, US/North America is where you would rather be than say, Europe, Africa or even Asia.

<comment><USER9> > In spite of all these, US/North America is where you would rather be than > say, Europe, Africa or even Asia.

Why?

<comment><USER10> Lower population density and land that's only been tapped for a few centuries instead of millennia. When the famines and natural disasters start, it's going to hit the old world a lot harder than the new.

<comment><USER9> I thought the parent to my comment was more an assertion around economic woes, but I'll bite.

I'm interpreting your response as an assertion around the USA doing better in the case of major climate shift. I don't perceive the US to be making significant effort towards more sustainable agriculture (compared to say the Netherlands) or keeping pace in proportion of energy generated from renewables or implementing meaningful social policy to address the disproportionate impact a climate crisis has on the poor.

The US has a lot to recommend it, but I find your argument to be a bit lacking in convincing me it'll have and easier time in the coming decades.

</comment></comment></comment></comment><comment><USER11> He is making lots of wild predictions about technology and automation.

5G in toasters? Come on. Is 5G really such a ground breaking technology that will change everything?

Automating car manufacturing? Tesla tried and it failed them - [https://www.theverge.com/2018/4/13/17234296/tesla- model-3-ro...](https://www.theverge.com/2018/4/13/17234296/tesla- model-3-robots-production-hell-elon-musk) No way Hyundai can do it tomorrow.

Replacing janitors with Roombas?? What the hell is he talking about.

Lots of promises about AI, but so far, it has underdelivered.

<comment><USER12> > _Is 5G really such a ground breaking technology that will change > everything?_

If it enables cheap enough connectivity - i.e. being able to place a 5G chip with a prepaid SIM card in a low-cost device - then absolutely, companies will jump at the opportunity to do everything from inventing bullshit "smart" "value-add" features, to selling surveillance to marketers.

</comment></comment><comment><USER13> Predicting the future is inherently stupid. Trying to show what will happen in our complex world using models is the stuff of Science Fiction.

Going back to the article and economics, if you follow David Graber (Debt The First 5,000 Years and Bullshit Jobs), he talks in his books about how every great civilization needs to have debt resets. Going back to the Babylonians, the Sumerians, and tons of others, there were always leaders or kings or emperors who would rise to power on the promise of debt relief. Israel had the year of Jubilee, where ever 50 years debts would be forgiven and slaves set free.

Continue inflationary debt is never sustainable. At some point, the world bank will lose its influence, smaller autocratic States will pull out of the "debt" they "owe" to their "liberators" and larger States will no longer be able to extract resources without force, that they're going to have a harder time paying for.

Debt reset needs to happen. Ever American student loan, loans with ballooning interest, medical debt, debt that's normally written off, debt that's never written off ... at some point we need less tracking and a bigger reset for each human being to start fresh.

<comment><USER14> Student loan debt is interesting because it could swing an election. All it needs is a candidate offering to write it off and a large enough portion of the population that stands to gain. I'll be surprised if it doesn't happen in the next decade or two.

<comment><USER15> I doubt it. Less than 15% of adults have student loan debt, and only a small portion of those are past due. Plus young people don't vote. The only thing that might happen, is what has happened which is to delay payments or maybe interest, but politically, student loan borrowers are not a sympathetic group to other voters.

[https://www.investopedia.com/student-loan- debt-2019-statisti...](https://www.investopedia.com/student-loan- debt-2019-statistics-and-outlook-4772007)

<comment><USER16> Any solution to student loan debt that doesn't fix the problem of how we wound up in the situation shouldn't (and probably won't) get widespread support for at least another 5 years or so.

Even as someone who's still paying off student loans, it's hard to want blanket forgiveness unless there is a system put in place to help minimize the number of people taking out loans for degrees that have a low chance of being able to make enough to make the cost worth it.

IOW, if a degreeholder in Underwater basket weaving on average makes only 5k/year more than someone who doesn't, we probably should limit the number of loans given to people pursuing those degrees.

Yes, this means many universities will have to trim down or eliminate programs. Perhaps it doesn't make sense for more than one or two colleges in a state (especially in smaller states) to have underwater basket weaving degrees.

There's also the psychological aspect to keep in mind; I recall my time in college and the first few years of what I was doing with my career, versus many of the people I know who are now complaining about student loans.

I graduated close enough to the 2008 crash that I couldn't get a job in my field after college. Building my career was years of long hours, cost me my marriage, and left me without a social life. Most of my associates who now complain about their student loans constantly were waiting for the next job to 'drop in their lap' (I even helped one get a job. They eventually got fired because they were incapable of even showing up to work less than an hour late for 6 months straight. No, they didn't think to save any of the extra money they made.)

That really there is the biggest rift: What's the solution that doesn't make people who sacrificed other parts of themselves to pay their bills feel like they got ripped off for doing the right thing?

<comment><USER17> I agree, it is completely unfair to give one group of people tens of thousands of dollars. If they are going to do that, then they should give everyone the same amount of money, even if you repaid your loans, even if you didn't take out loans!

On the one hand I worry about the moral hazard, the devaluing of the currency, and the debt being passed to future generations. On the other hand I recognize that it is almost criminal how we pressured 18 year olds into this situation.

</comment></comment></comment></comment></comment><comment><USER18> Some interesting points but some of them are not internally consistent:

Author claims that the stock market is up because people are sitting at home day-trading driving up prices. Then a few paragraphs later claims that cash is king and people are unlikely to spend.

Author claims that 2009 Fed spending made sense because it was an aggregate demand issue. That was not very clear then as it was unclear that many of the mortgage-backed securities actually had a positive value. Coronavirus in comparison is much more clearly a demand issue (people are effectively being ordered not to go out and spend).

<comment><USER19> sorry but lmao at people who think small daytrading drives these markets.

The author has zero credibility. Never listen to this dangerous moron ever again. He doesn't deserve a conversation thread.

</comment></comment><comment><USER20> the headline is very optimistic for what the article contains

</comment><comment><USER21> I'd take what Roubini says with a grain of salt. Economists have predicted 10 of the last 7 recessions, and a broken clock is right twice daily.

In recent history, he was a bit late to the coronavirus party, not really being on-board until late February. Preppers were all over it in January.

<comment><USER22> Preppers also predicted 10 of the last 1 world debacles too, so that's not very predictive either (year 2000 crisis, nuclear war, etc). I'm no better myself.

However, in 2008 there was a giant amount of poor mortgage debt, it was a real thing. We've had near 0% interest rates in much of the western world, more in europe, wasteful debt increases and tax cuts in the us that didn't go to long term useful infrastructure. And our economy hasn't been growing that much. China has a giant debt bomb, how will that work out?

<comment><USER21> Never mind China's debt bomb. Their demographic bomb is bigger. It's going to look like Japan in 20 years. Between that, the possibility of parts splitting off, and the possibility of the fall of the Communist part, The "China will overtake the US" narrative is premature. If Xi can hold it together, maybe it will, but that's not a given.

<comment><USER22> I forgot about the age issue and also the too many males, too few females in China. The Communist part is looking pretty strong right now. I wonder, is there any reason to hope that China will eventually democratize? I see nothing like the demographic trends that is so clear. China has a lot of room to grow their economy and military before the demographic issues hit. Look at Japan, very powerful in both dimensions.

</comment></comment></comment></comment><comment><USER23> Stop it my SPY puts already expired worthless.

<comment><USER24> wallstreetbets in my HN? obligatory SPY 6/11 285c

</comment></comment><comment><USER25> It sounds a lot like the jackpot, as William Gibson calls it in _Peripheral_ and _Agency_.

</comment><comment><USER26> Can anyone explain why banning credit/usury wouldn't help in the longer term?

<comment><USER27> What, and force people reconcile with the real cost of owning material goods and receiving services? Sir, this is America.

<comment><USER26> I've also heard _private debt jubilee_ put forward as a solution. Don't know which (if either) is preferable.

</comment></comment></comment><comment><USER28> Given who's in charge of the CDC + Senate I can't say I'm holding my breath.

</comment><comment><USER29> Important to understand with all the US-China stuff - working class people in both countries _should_ mutually benefit from higher productivity, the open development and sharing of technology, from trade, etc. The only thing driving a rift and opening up a "cold war" is that US and Chinese _capitalists_ can never get along because they are competing for the same pool of profits. Everyone else has pretty mutually beneficial material interests.

So when you read about "the Chinese" (who in China?) listening to you through your toaster, there's really no reason to care or pay attention to that absurdly nationalist sentence, just as there's no reason for anyone in China specifically to listen, unless you're the owner of a significant portion of a technology company and are hiding that company's tech knowledge from the rest of the world in order to profit from it. And that's against all of the rest of our interests.

<comment> chroem- A lot of people in this country have lost their jobs due to outsourcing.

<comment><USER29> Their jobs were most often outsourced by US companies looking to get higher profits from cheaper labor. It would be a lot more effective to solve this by enforcing equivalent, high working standards across the world, rather than blaming Chinese people for desperately needing a job like everyone else. But then profits would be lower, oh no.

<comment><USER30> Not only would profits be lower (disincentive for companies), Chinese [or other off-shore] employment prospects would be worse (disincentive for them to comply).

Trade makes people better off in general, but it doesn't make every person better off.

<comment><USER29> I don't understand, disincentive for who, to comply with what?

<comment><USER30> If China would make themselves less competitive "by enforcing equivalent, high working standards across the world", they have clear disincentives to enforce compliance.

<comment><USER29> Oh, yes. That's been used to drive down the standard of living in the US (including within it) forever. That's why competition is bad for labor. The only real escape from the market's race to the bottom is a democratically planned economy IMO.

<comment><USER30> Competition is both good and bad for labor. It's bad for labor-as-suppliers. It's good for labor-as-consumers.</comment></comment></comment></comment></comment></comment></comment></comment>


900Mhz radio for iPad w/OSS ground station for DIYDrones (funding drive) - <AUTHOR> http://www.fightingwalrus.com

<comment><AUTHOR> I have know these guys for a few years. I met them as part of a UAV challenge DARPA was putting on. They already have a working prototype and are in the official Apple accessory program! The radio is going for $99 bucks as part of the fundraising campaign on Indiegogo.

We will be hacking on the ground station at the NSMeetup hack-o-thon March 30th at Sincerely in SF. <http://www.nsmeetup.com/events/103975442/></comment>


Show HN: Machine-learning used to suggest extra destinations to fly - <AUTHOR> https://www.producthunt.com/tech/questorganizer <comment><AUTHOR> Hello Hacker News, My flight search engine is featured on Product Hunt today. I'm gathering users feedback to know what to improve. Let me know what you think about it?</comment>