A Year Of Scala | Hacker News Reader

A Year Of Scala

blog.joa-ebert.com

53 pointsDanielRibeiro45 comments

As someone who has spend a fair amount of time with Haskell, Scheme, Common Lisp etc, can someone give me some insight into what's really exciting about Scala? There seem to be a lot of people I respect using it, but most of the articles I've read are of the form "coming from Java, Scala is awesome!" which I haven't found particularly enticing. Every time I look at examples I don't really see anything that sticks out as particularly interesting. I really want to get excited about Scala, and would really appreciate any insight that would help me with this.

Being able to do all your cool stuff in the usually boring enterprise world is the interesting part. If you don't need to integrate with container dit or java product dat there is no real need for scala.

Just the pleasures of a powerful type system, inference, pattern matching, higher order functions... The usual good stuff, but on the JVM. I was paid to learn and program in it for a good five months earlier this year (everything ended up getting ported to python later...) and yes, it basically boils down to "coming from Java, Scala is awesome". If you have to build on top of the JVM and the Java ecosystem of libraries, it is a fine choice.

Which do you prefer? Python or Scala?

I enjoyed writing Scala more than I enjoy writing Python, but there are a few undeniable advantages that Python holds over Scala. The motivation to port from Scala to Python was to avoid the lengthy build process that had been slowing down development to a crawl. There may have been other ways to alleviate this, but by the time the port was completed, it took a good 15 - 20 minutes to get the build machine to compile and package the entire project so it could be deployed to production. At this time rapid fixes were critical.

Also, the team as a whole prefers Python to Scala... I took pleasure in learning how to express my code in increasingly functional and compact ways, but my coworkers found struggling with the type system to be too much of a headache. In particular, there are rough edges when you are integrating Scala code with Scala types and data structures with Java code with Java types and data structures. In any case it will be easier to find programmers who write in Python than those who might write Scala.

Scala gave me more personal pleasure to write in, but Python isn't bad either. I miss the type system and the many classes of errors it could help prevent at compile time, but I appreciate being able to change Python code and put it to the test immediately. The loss of expressiveness is probably made up in part by being forced to write code that is more easily read. I still hope I will be able to find a job writing in a functional language in the future...

JRebel lets you change a running Scala program without having to restart the appserver and integrates well with IDEs. I find it's easily worth its price in the amount of productivity it adds when doing Scala web development.

Great response. How many LOC was your project that you got that amount of slowdown? Would you say it was the primary reason even over some developers struggling with the type system?

I'm a huge Scala fan but even after a year of hobby programming here and there I feel like a beginner...

I could pull up the LOC, but it honestly wasn't the Scala compilation that was the true issue. The true issue was that the project was built with maven and it had a tremendously large number of dependencies. If all the Scala in the project had been converted to Java, the build still would have been monstrously slow. So the port was more of an escape from the JVM than an escape from Scala - and yes, the build times were the primary reason for the port. As for the type system... not a single other person left on the team misses Scala but me. (The primary Scala evangelist had been let go for unrelated reasons)

It's all the interesting stuff that you get with Haskell/Scheme/Lips/etc combined with the practicality of running on the JVM with easy Java integration. Practicality being the key word.

That description actually sounds a lot more like Clojure to me.

Well with Clojure you get something that's more Lispy. With scala you get basically a mashup of Java + ML.

I don't think Clojure has much at all to do with Haskell other than the pure functional aspect. One is a dynamic lispy language, the other has a very rigid type system (note I said rigid, not cumbersome) that's pretty much the antithesis of a lisp...

Clojure's STM is based pretty heavily on Haskell's.

Yes, they're both pure functional so you need an STM to do anything...

I can't tell if this is a troll or just a misunderstanding, but it's wrong on two counts: Clojure is not purely functional, and side-effects are done more often with monads than STM in Haskell.

are you sure I have the misunderstanding? Which Monad do you think people use for side effects in haskell? Do you think STM in Haskell is not handled by the STM monad?

Great article. I've been learning Scala for a while now as time allows, and have had similar experiences - the syntax is tricky at first, and much of the community focuses on CS esoterica that isn't familiar to me, but the major concepts are quite familiar, coming from Python, Scheme and JavaScript. I'm still looking forward to my moment of epiphany when I realize I've become vaguely competent with Scala.

Scala is the C++ of the JVM based languages.

I disagree completely. C was a well designed language that was later added onto haphazardly and you ended up with C++.

The Scala language designers took a long time examining the shortcomings of java and other languages and ended up improving them, and at the same time coming up witha much smaller language specification.

If anything, Java was the C++ and Scala is the C.

Please point out the "shortcomings" of Java. It has done quite well and provably "scales" from programming in the small to enterprise level. Even the required detour of multi-core resulted in the industry's gold standard of memory models: JMM.

"Much smaller language specification" is a red herring. The issue is (practical) comprehension.

"C was a well designed language that was later added onto haphazardly and you ended up with C++."

http://www.amazon.com/Design-Evolution-C-Bjarne-Stroustrup/d...

I've read that book. (Have you?) Nothing "haphazard" about C++.

I consider verbosity and lack of closures to be shortcomings of Java. Apparently, so did the author of the article here.

Its perfectly fine to note that Java can be verbose and that it does not fully support closures. It is perfectly fine to consider these "shortcomings".

However, in context of OP's comment above, the strong suggestion made was that shorcoming == poorly designed.

And that is a completely wrong assessment of Java and its designers. It is an exceptionally well thought out system and language. Again, the proof is in the pudding. Google and Oracle are not fighting over scala ...

If issues such as verbosity and whether or not to have closures are not part of the language design process, then what is?

That is a non sequitur.

A language designer must make choices. 2 choices have been identified as "shortcomings" (in the sense of this thread). Empirical evidence suggests that they indeed picked a very productive sweet spot.

As an aside, the current disfavor of "crowds" for Java is all together too familiar to the past fervor of "crowds" for Java. You may wish to reflect on that.

"Empirical evidence suggests that they indeed picked a very productive sweet spot."

You seem to be arguing that popularity and quality are synonymous. I do not think that is a very useful way to evaluate programming languages.

Do you have actual data showing productivity gains for using Java over Scala or other languages that run on the JVM? How about Java and non-JVM languages? Even anecdotal evidence? You are advocating for empirical evidence, but are not providing much in this discussion that I can see.

"You seem to be arguing that popularity and quality are synonymous. I do not think that is a very useful way to evaluate programming languages."

No. And yes, of course. (Java is not exactly "popular" these days.)

"Do you have actual data showing productivity gains for using Java over Scala or other languages that run on the JVM?"

Do you have actual data from a study that shows such studies are worth their virtual ink? Cite it, please. Lets pretend we have an actual market economy in this country: How many businesses have shot themselves in the foot with Java? How many have bet the farm (IBM, Oracle, even Google has hedged on this tech) on Java? Are they all idiots who do not appreciate the grave "shortcomings" of Java and its impact on the "productivity" of their workers ants? Are you kidding me?

"You are advocating for empirical evidence, but are not providing much in this discussion that I can see."

One needs to point out the overwhelming presence of Java in OSS? Well, consider it pointed out. Pretty darn good showing for a language with such serious "shortcomings".

Anecdotal? Have been programming since 16. That was 30 years ago. Have done/seen enough to have a reasonably informed opinion regarding languages. Everyone of them has its set of issues. Java included. But it is actually one of the most productive languages I have worked with to date.

>but it is actually one of the most productive languages I have worked with to date.

Because of the language design, or because of the libraries and the jvm (GC, the fact that it's bytecode, etc)?

Do you think Scala would make you less productive?

They're not fighting over Java, they're fighting over the JVM. Java isn't worth fighting over.

The fact remains that the JVM was designed for Java and mirrors its semantics.

The "shortcoming" of Java is due to none other than the JVM:

http://java.sun.com/developer/technicalArticles/DynTypeLang/...

Shortcomings: Generics. Lack of closures. Please tell me how those are not shortcomings.

>Even the required detour of multi-core resulted in the industry's gold standard of memory models: JMM.

Which has absolutely zero to do with java the language. Did you forget what we were talking about in your second sentence?

We were discussing the "mistakes" made by the Java design team. JMM is one of their products. It is relevant to mention this fact as it supports the claim that the responsible parties have generally been also quite brilliant folks.

I did a few spare time projects with Scala, but does (did) anyone use it for commercial applications? If so, what kind?

I decided to implement (nearly) all of foursquare.com in scala.

Do you have any problems with GC pauses?

Yes, on occasion. We've combatted this in a couple of different ways:

1) Rewriting code to make fewer memory allocations or, in some cases, allocate memory for shorter periods of time (so it doesn't get promoted to a longer lived heap)

2) Garden variety GC tuning. Tune the various heap sizes, and GC algorithms used.

Aren't parts of Twitter in Scala now?

Yes. And lots of it is open source: https://github.com/twitter

This article demonstrates the beauty of taking away cruft until you only have the essential stuff left. I like Scala's succinct way of anonymous function notation.

http://www.boost.org/doc/libs/1_45_0/libs/graph/doc/using_pr...

"I was tired of writing code like this over and over again."

This is getting tiring:

   public class MyGraphThingee extends Graph<Foo, Bar>

Doesn’t this issue mostly go away when using a decent editor? I also found out that while I don’t particularly enjoy writing boilerplate code, it gives me a second to rest my brain, relax, think about the context etc. I think I like the resulting "rhythm changes".

Judging by the upvotes, the comment was misread. The point was that it is trivial to extend the generalization to avoid verbose references and type names.

Does Java have typedefs nowadays?

No. Don't need them.

https://gist.github.com/755824

are you some kind of java troll?

Reply on news.ycombinator.com