Live data from Hacker News

Language War - Scala versus Python

blog.zlemma.com

11–20 of 52 posts

Re: Language War - Scala versus Python

#11

No discussion of run-time characteristics? I realize for a some start-ups this is not the most important metric, but these guys sound like they might be compute bound. And faster language can mean cheaper/less hardware. Scala vs Python: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... Also since he mentioned Haskell at first, Haskell vs Scala: is also interesting: http://benchmarksgame.alioth.debian.or…

Thanks! Great articles. We are not compute-bound for the near-term, so it's not our most important consideration. As the business evolves, we will embark on a fresh language war where compute performance is likely to be a key factor.

Re: Language War - Scala versus Python

#12
> Typecheck in Python

People actually use it? It seems abandoned and the link to homepage broken: https://pypi.python.org/pypi/typecheck. I'm asking because I'd really like the idea of starting a project the dynamic typing way and then bolting on a (semi)-static type system on top once more new programmers join the game, preferably being able to completely disable it on production machines for best performance.

Re: Language War - Scala versus Python

#14
> Besides, dynamic typing scares the hell out of me

Funny. I feel exactly the opposite. Static typing is false security.

I program in JS. My coworkers in Java. They have so many bugs that make it to prod because they assume that just because it compiles it must therefore be safe.

Re: Language War - Scala versus Python

#15
post #6

The article's basis of the comparison for building an entire business seems to be very shallow. Surely other considerations are more important, such as, - encapsulation/domain partitioning - messaging - libraries and library maturity - native code interoperability (likely critical for this application) - concurrency - performance - JVM platform - etc. Maybe, as a result of this type of analysis, Python-like language…

This kind of comparison reminds me about something similar about Git vs Mercurial: http://importantshock.wordpress.com/2008/08/07/git-vs-mercur... It looks more like an emotional kind of story than one about practical decisions.

Indeed! At the early stages of a startup, most decisions (including technical ones) have a strong emotional/instinctive flavor. When I worked at large corporations, the decisions were almost always devoid of emotions.

Re: Language War - Scala versus Python

#16
I think you shouldn't have let people talk you out of using Haskell. It's a very nice language and has some advantages for this sort of project (at least based on your cursory description).

However, its advantages are really not the important part. Rather, I just wish you wouldn't dismiss it immediately as a crazy choice. It's no more crazy than any other less-popular language. It has a reputation for being impractical, but this reputation is rather unfair especially in the light of recent very practical developments like simpler concurrency, an improved IO manager, very good web frameworks and a fair about of strong libraries both for very specific domains and general productivity.

The main disadvantage is that many people find it hard to learn. However, this is a function (heh) of functional programming rather than the language itself. It's actually a simpler language than Scala in many ways because it tries to do one thing well--for example, it has no sub-typing, so you do not have to ever worry about covariance and contravariance.

Now, my point here is not that you should always use Haskell, just that you should seriously consider it. Too many people dismiss it out of hand almost as a joke when it is anything but.

Re: Language War - Scala versus Python

#17

> Besides, dynamic typing scares the hell out of me Funny. I feel exactly the opposite. Static typing is false security. I program in JS. My coworkers in Java. They have so many bugs that make it to prod because they assume that just because it compiles it must therefore be safe.

Are there no tests beyond simple compilation?

Re: Language War - Scala versus Python

#18

> Besides, dynamic typing scares the hell out of me Funny. I feel exactly the opposite. Static typing is false security. I program in JS. My coworkers in Java. They have so many bugs that make it to prod because they assume that just because it compiles it must therefore be safe.

I must admit that JS scares me more than anything else. Would love to hear about defenses you employ in JS.

Re: Language War - Scala versus Python

#19

> Besides, dynamic typing scares the hell out of me Funny. I feel exactly the opposite. Static typing is false security. I program in JS. My coworkers in Java. They have so many bugs that make it to prod because they assume that just because it compiles it must therefore be safe.

I prefer static typing because those assurances reduce the number of things I have to manage--they mean I must keep less state in my head. I do not assume that it guarantees things that it does not.

Attributing your coworkers' "if it builds, it works" assumptions to static typing strikes me as incorrect. Static typing, at least in Java, ensures only a (relatively) small set of conditions are true; I don't think you can really blame that for increased/additional assumptions on the part of sub-par programmers.

Re: Language War - Scala versus Python

#20
post #5

"And who the hell does Scala? (Actually, Twitter does!)" Foursquare also uses Scala, as does LinkedIn. Here's a page of organizations using it: http://www.scala-lang.org/node/1658

This was done a few years ago. I'd love to hear what people have to say about Scala now that code bases have grown. Anyone working with a couple hundred thousand lines of Scala? For instance, I know compilation performance was always frustrating for developers. What's it like for teams of people dealing with a large code base?

We are working with Scala at that scale at Foursquare, and compilation times are definitely a headache. What helps is ensuring your dependencies are acyclic so you're able to do smaller incremental compiles when you make changes. To get us on the path of a DAG-ified codebase, we've been using a build tool developed by Twitter called "pants":

https://github.com/twitter/commons

which has some similarities to Google's Blaze build tool.

Post reply on HN