Live data from Hacker News

Why we love Scala at Coursera

tech.coursera.org

41–50 of 184 posts

Re: Why we love Scala at Coursera

#41
post #29
post #25

the whole "live reload" capability of play is a gimmick because in real life making a code change in a medium to large project is like watching grass grow - every change you make takes minutes to compile and reload.

How large? We have well over 100k lines of code (Scala), and it's not a serious issue. The sbt 0.13 incremental compiler is much better than 0.12's. Also, using sbt multi-projects helps quite a bit (even when running all at once).

much smaller - around 25k+. i gave up after becoming frustrated by the atrociously compile times. haven't used sbt .13 though but i don't expect it to solve miracles given how inherently complex the scala compiler code is. according to paul phillips, core scala committer, there are large portions of the compiler code that nobody touches because nobody understands it. and as per him this along with bunch of other limitations guarantees that you won't see huge gains in compile times unless they rewrite the whole compiler...

Re: Why we love Scala at Coursera

#42

This is a thing about Scala which gives me pause: it looks like gazing into the guts of the compiler puts one on a course towards a nervous breakdown. http://www.youtube.com/watch?v=TS1lpKBMkgg

I asked someone in the know, and apparently Paul Phillips is always like that. He has an interesting background -- was a pro poker player for a while.

Also happened to be the guy who wrote the most Scala code on the planet, and he quit Typesafe last year.

Re: Why we love Scala at Coursera

#43
post #31

Earlier quoted context omitted.

"Combining for-comprehensions with composable futures makes asynchronous concurrency look like straightforward synchronous code." I would really enjoy seeing this in Java.

Just curious, but have you used Java8 much? Or barring that, something like quasar? Qasar in particular is about writing async code as if it were sync code...

Java's future API is inadequate - you can only block on a future or poll it, not ask to be notified when it completes, so you end up needing a thread for each future which loses a lot of the benefits.

I haven't used Qasar specifically but I did use other java extensions that add some scala features for a while (Lombok and the Checkers Framework). The thing is, once you're using those you're effectively using a different language ("extended java") with its own bugs - and the community for that language is much smaller than that for scala.

Re: Why we love Scala at Coursera

#44
post #27

It's good to see Scala getting some love after all those "i hate scala" rants (many of which seemed to be written by people who haven't spent much time with the language). We're using it at work for essentially all new development. Although I have complaints, I can't think of another language or environment that I've used that's been so satisfying and free from overall irritation. In practice, we don't get code that'…

We've had the same experience with Scala. It's the most enjoyable language I've ever coded in. We switched away from Java for most new development a while back already. The anti-Scala rants are just confusing to us. Most of the people complaining just seem to be random non-Scala developers recycling other peoples' criticisms.

Re: Why we love Scala at Coursera

#45
From an experience standpoint, isn't the fact that you'd have to teach people a new language coming in the door detrimental to the use of that language?

Comparing a company that takes in people that have been coding Ruby/Python/Java/whatever for 5+ years, versus one that takes in people that don't have Scala experience but teaches them on the job, wouldn't the former move faster and generally have more experience, making it better to hire from a large pool of experienced people (in a popular language) than a small pool (in a more niche language)?

This, of course, assumes (rightfully, I think) that the "carryover" effects of programming experience aren't substantial enough to claim that 1 month of Scala experience is better than 3 years of Ruby experience, and nor is the "advantage" that Scala gives over these more popular languages (real or imagined).

I love Coursera and all, but I'm curious what people think about this.

Re: Why we love Scala at Coursera

#46

It would be interesting to read a similar article from a company that uses python as their core programming language (Dropbox for instance) to contrast it with this one. Python might not be as popular as Java but I was under the impression that it offered a rich enough platform/ecosystem to accommodate for a wide spectrum of software projects. Concerning the issue of type checking, I understand that it's great to hav…

"pretty sure unit-tests and a bit more care" - it's better to focus on unit-testing behaviour and care about things that need human's input though.

"where type checking is required" - it's better to single out cases where it is not required, this is how it's done in C# for example - quite useful for integration with other ecosystems.

Re: Why we love Scala at Coursera

#47
post #25

the whole "live reload" capability of play is a gimmick because in real life making a code change in a medium to large project is like watching grass grow - every change you make takes minutes to compile and reload.

If @1 second recompile entails watching grass grow, you have some serious miracle grow on hand ;-)

SBT sub projects are the ticket to sane Scala development. If you just lump everything under a single project, sure, then it's grass growing time o_O

Modularize your code and then play> ~run (i.e. incremental compilation) and relax -- the "Scala is slow" mantra is so 2011.

Re: Why we love Scala at Coursera

#48
post #8

What is the point of articles like this? I'm not trying to be snarky; I really am trying to understand why a company would go out of its way to advertise the technology its using. Sometimes we see blog posts from devs at companies (often pretty senior) who write things like "We went with Clojure, and we've been really happy." That's clearly a geek-to-geek thing. But what is this? I mean, it's also geek-to-geek, but i…

The point is to attract new developers who may be interested in Scala to Coursera as well as showing their expertise in the language. I definitely think this works, but it's a very obvious strategy as many others have called out. I think a better tactical recruiting strategy would be to open source some Scala based projects. If you look at Coursera's GitHub repository[1], they aren't giving anything back compared to a company like Mesosphere[2] that offers multiple open-source Scala projects. As a developer, I want to work where people are building cool things, not where a team is married to a language or platform.

[1] - https://github.com/coursera

[2] - https://github.com/mesosphere

Re: Why we love Scala at Coursera

#49
post #45

From an experience standpoint, isn't the fact that you'd have to teach people a new language coming in the door detrimental to the use of that language? Comparing a company that takes in people that have been coding Ruby/Python/Java/whatever for 5+ years, versus one that takes in people that don't have Scala experience but teaches them on the job, wouldn't the former move faster and generally have more experience, ma…

I think you're right in the short term, but long term you may be more productive with Scala. -Devil's Advocate.

Re: Why we love Scala at Coursera

#50
post #25

the whole "live reload" capability of play is a gimmick because in real life making a code change in a medium to large project is like watching grass grow - every change you make takes minutes to compile and reload.

The Scala compiler is slow. However with some care over code organisation you can limit what needs to be recompiled in most cases. Read and heed this blog post: http://www.chrisstucchio.com/blog/2014/bondage_and_disciplin...
Post reply on HN