Live data from Hacker News

Brand new Scala-lang.org

scala-lang.org

61–70 of 131 posts

Re: Brand new Scala-lang.org

#61
post #28
post #2

Nice to see the language page be as easy on the eyes as the language itself. There's almost no excuse not to use Scala if you're deploying on the JVM. On a related note, does anyone else see the Scala logo and confuse it for a symbol representing databases or hard disks? It just doesn't click with me

"There's almost no excuse not to use Scala if you're deploying on the JVM. " There is one incredibly good reason - possibly the most important reason. How easy is it to find a Scala developer if you need to expand your team compared to a Java developer? I'd put it the other way around: what excuse do you have for spending more per developer? (There are some excuses here, but they're far from clear cut.) In addition,…

It really depends on what kinds of developers you need.

On the problem domain I'm working on, the concern of the programming language used by candidates is the least of my worries when looking for people. And yes, the people we are looking for are more expensive than average. But that's not because they can work with Scala.

Re: Brand new Scala-lang.org

#62
post #43

Earlier quoted context omitted.

I guess it depends on your team. We didn't have much trouble with Java guys picking up Scala very quickly. Scala performance is on par with Java if you keep your wits about you, but you do have to be mindful of the code you write. Scala collections (esp. maps, doubly so for immutable.Map, but also mutable.Map) are (currently) slower than the standard Java collections, but it's easy to use an implicit conversion wrapp…

If map performance is really an issue for you, you should look into using the parallel collections. For maps with less than 10k entries, I'm unable to see any difference between the immutable/mutable and ju.HashMap collections. For maps with >100k entries, it makes sense to farm out your iterating to multiple threads.

Put and lookup are much slower vs ju.HashMap. For most use cases where the system is already multithreaded the parallel collections don't gain us anything.

If you have a large read-only map being read by multiple threads (doing random lookups) ju.HashMap leaves both mutable.Map and immutable.Map very far behind. Scala is great, but the Map performance lags.

I'm not the only one who has noticed. Try googling "Scala map performance vs Java"

Re: Brand new Scala-lang.org

#63
post #59

The new homepage gives Scala a very classy feel! Nice!! This comes as a (personal) advise to all my fellow startups here. Dear dudes and dudettes, I've been a long and hard fan of the 'Get shit done' mentality and I still am. From my past experience running Rails and Scala, I'm going to tell you what exactly you should do for your startup: 1) If you KNOW FOR SURE your startup will face a lot of page views, requests e…

This is very helpful. Thank you for taking the time to write this.

Re: Brand new Scala-lang.org

#64
post #16

I recently installed Scala. I'm a PHP Dev, who plays around with Clojure on the side, but wants to be converted into the static typing camp. I also wanted to keep things functional (hence my love of Clojure, and my PHP code keeps things as immutable as possible), but also have a language that is usable if I were to go and get another programming job. Scala seemed a perfect fit. Until I looked at job boards for Brisba…

Play version 2.x is not heavy, being pretty modular and elegant. Give it a try.

On the job boards problem - the funny thing in this industry is that you're more likely to find jobs because you use a certain language that's not as popular as Java or PHP.

It's a supply and demand issue. Yes, there are many jobs for Java and PHP. But there are also many PHP and Java developers. And as a general rule of thumb, for finding good jobs smart developers focus on skill-sets that are much narrow and harder to practice than usage of a programming language.

Focus on scalability issues, on design, on social skills, on data analysis - people that are good at such things are worth their weight in gold.

Re: Brand new Scala-lang.org

#65
post #28

Earlier quoted context omitted.

"There's almost no excuse not to use Scala if you're deploying on the JVM. " There is one incredibly good reason - possibly the most important reason. How easy is it to find a Scala developer if you need to expand your team compared to a Java developer? I'd put it the other way around: what excuse do you have for spending more per developer? (There are some excuses here, but they're far from clear cut.) In addition,…

Someone had this argument (can't find the link) - for every ace Java developer out there you have hundreds of companies with a relevant position to compete over her / him. For a Scala developer position, you are competing with less companies, so you might as well be able to fill the Scala developer position faster than the Java one. Regarding speed, I don't mind about the runtime speed as much as compile speed, runti…

I've heard that argument here: http://2013.flatmap.no/simen.html

Re: Brand new Scala-lang.org

#66
post #49

Earlier quoted context omitted.

Do companies actually restrict themselves to people who already have experience in a certain language when hiring? I've never encountered this practice. It is fairly hard to find a good developer, but once you find one you can tell him or her to write Scala or Java or OCaml or whatever you like.

Recruiter here, and unfortunately many companies still won't look at people without having specific language experience (and often a specific amount of language experience). I find this has traditionally been more true in the Java world, where I've had clients ask for x years of Java and > n years of a specific framework. I spent most of my 15 years working almost exclusively with Java shops that were often this spec…

I'm not a recruiter per se, but I have been recruiting.

On the question "do Python shops hire non-Python programmers because they have to?", from my experience the answer is Yes, but the reasons are twofold.

On one hand, yes, it is harder to find Python developers and it makes no sense for a company to restrict itself to such a limited pool.

On the other hand it is also a matter of culture - companies that use less popular technologies often do so for good reasons. Such companies are often looking for good developers in general. In my interviews the least of my concerns is the programming language the candidate used, when most people fail to satisfy me on questions like "describe the perils associated with concurrency and parallelism".

The companies focusing on Java that you speak of, on the other hand, have no need for good developers as they focus on quantity, not quality. For them it is far more valuable to hire replaceable resources.

Re: Brand new Scala-lang.org

#67
post #59

The new homepage gives Scala a very classy feel! Nice!! This comes as a (personal) advise to all my fellow startups here. Dear dudes and dudettes, I've been a long and hard fan of the 'Get shit done' mentality and I still am. From my past experience running Rails and Scala, I'm going to tell you what exactly you should do for your startup: 1) If you KNOW FOR SURE your startup will face a lot of page views, requests e…

Great write up!

One small picky thing:

> Scala: def test = {"hello world"}

Can be actually

   def test = "hello world"
:)

p.s. you can play with Scala code live in the browser here:

http://scalatutorials.com/tour/ (work in progress)

Re: Brand new Scala-lang.org

#68
post #48

Earlier quoted context omitted.

> There's almost no excuse not to use Scala if you're deploying on the JVM - Poor tool support (refactoring regularly broken on both IDEA and Eclipse). - Terrible backward compatibility story (want to use CoolLibrary v1.0, which was compiled with Scala 2.9 and you're using Scala 2.10? You're out of luck, you need the library to be compiled with the same version of the compiler). - Very slow compilations, and getting…

We used Scala in production at my previous job. It was great for the most part, but upgrading from 2.9 to 2.10 was a massive, massive pain. I think I spent nearly a week on the refactor. We didn't even have that much code (relatively speaking); the majority of the time was spent on finding substitutes for the libraries which were irreparably broken, and rewriting client code against the new API. That's pretty damning…

Version compatibility is definitely a pain point, but as painful as that is I'd still pick that over using regular Java.

Re: Brand new Scala-lang.org

#69

Earlier quoted context omitted.

> How easy is it to find a Scala developer if you need to expand your team compared to a Java developer? How easy is it to find a GOOD developer? Much easier with Scala. It's not like wading through hundreds of Java resumes and interviewing them is free. > In addition, Scala tends to run slower than Java which can have a further cost if you're scaling to many servers. This depends on so much different factors in both…

Yes, Android's Garbage Collector is a one legged mule. Slow, crippled and needy. Scala, on the other hand, generates a ton of little objects. I'm a full time Scala dev but if I were doing Android I'd probably for the foreseeable future work in... dare I say it? Java.

Scala creates a ton of little objects? Are you aware that primitive types are only converted to objects in Scala, if they are used as objects?

Re: Brand new Scala-lang.org

#70
post #2

Nice to see the language page be as easy on the eyes as the language itself. There's almost no excuse not to use Scala if you're deploying on the JVM. On a related note, does anyone else see the Scala logo and confuse it for a symbol representing databases or hard disks? It just doesn't click with me

" There's almost no excuse not to use Scala if you're deploying on the JVM. " There's a good reason, actually - library maturity, especially when trying to get data in and out. Try and do some inner joins with typesafe slick and you'll know what I mean when you see the SQL it generates. Or try and use Play Framework's json de/serialization, and be prepared to punch your monitor in the face. I think these critical lib…

I built ScalaQuery 0.10 against Scala 2.10.2, not touching Slick until the library matures.

Think Scala Pickling by Sara Miller at TypeSafe looks excellent for serialization needs.

Post reply on HN