I know. I didn't imply no other languages allowed this (especially for "high level" data structures such as list). I was just replying to gp that indeed, the article is about scalable infrastructures/systems rather scalable languages.

On the other hand Scala goes quite far in that approach; Ruby and Scala are also often compared for the ability to define embedded DSLs. In Ruby it is handled with meta-programming whereas Scala has made the choice of offering language-level DSLs (that make use of Scala syntax smartly), thus offering the typing system for the definition and usage of DSLs. People coming from Ruby especially enjoy a strong typing system that helps them and doesn't get in their ways.

Here's something I read tonight on IRC, and I read it quite often :)...
<against_logging> i learned ruby for nothing, i found scala

Now, Ruby is nice -- but just like a lot of people didn't care much before Rails came, right now a lot of people are dismissing Scala because "we don't need another language". Scala is not just another language, really. It finally provides an "enterprise-friendly" functional language: enterprise-friendly, because a lot of companies are sold with Java and the JVM, it's easy to let Scala in. But it gives the power of ML and functional languages, all the libraries written for Java, and the lightweight syntax of Ruby or Python (with a much better performance).

Finally, Scala matters because this is the Free alternative to F#, which is basically Ocaml for .NET. OCaml is Free (even if the policy is a bit restrictive with contributions), but it isn't part of a larger platform such as the JVM or the CLR. In the upcoming years, functional languages will get a boost because they handle multithreading better (they make it more practical to use immutable data) and because finally people understand that a typing system makes complex programs easier to re-use and maintain. Scala is very much the contender for the Free Software community -- and it's not only more innovative than F# (which is very similar to Ocaml, which is awesome but has been around for a while), but also in my opinion offers developers from the world of Java & dynamic languages with a stairway to functional programming: they can learn step by step.

A language scales if the language itself (not the "runtime" or whatever) can grow with user constructs to suit the ever-changing needs. For instance, in Python, if you write
l = [a]

you will end up with a Python built-in list. Squared-brackets are part of the language syntax and will always refer to Python builtin lists.

In Scala, which is meant to be a scalable language (as the name implies: SCAlable LAnguage), if you write
val l = a :: Nil

you will end-up with a Scala list only because the ::' "keyword" (which in fact isn't) is in the scope, but you could specify another class if you'd like. Use another implementation, yours if you'd like.

All of Scala is made this way and that's why the *language itself* is scalable.

Now, the article talks about scalable architectures, not scalable languages -- they use Scala because they like it :). Yet since Scala compiles to Java bytecode, it offers all the JVM's scability features (clustering with terracotta, ...) and it's a great language to write scalable software in :).

I read between the lines that you call C or C++ solid-code, and if I'm not mistaken, you will find that the kids are doing Scala because the code is more solid. Scala benefits from a typing system close to OCaml's which makes Scala code very, very solid -- especially if you keep away Java specifics (such as nullable objects) in your code and take special care when interacting with Java libs that may do so.

If I'm mistaken and you're not talking about C/C++, I hope you are not talking about dynamic languages which offer no guarantee whatsoever; you know as a developer I enjoy actually spending my time on working on the business side of my application -- and how to make it scalable, rather than working on low-level specifics and on testing if every pointer is null before dereferencing them. A type system that does this for me (which Scala or ML's parametrized type Option allows) is a bliss.

Now, I'm not enumerate every language under the sun to see what code you call solid, I guess your answer would be that the code is solid whatever the language it's written in. In the end, it all comes down to binary instructions, right? The question is: how many guarantees do the tools give you? In the case of Scala's compiler, it gives you a lot AND offers you a very enjoyable, lightweight yet powerful syntax.

What? Scala is Java mixed with OCaml -- you get an extremly powerful typing system, but it feels like a "dynamic language" such as Python or Ruby. With the performance of Java. Under the hood, it's a brand-new language, very different from all those: it merges functional and object-oriented programming. Yet, for the regular programmer, it feels like Ruby... until he gets used to more powerful features and learns how to designs more complex libraries as embedded DSLs. All that while running on the JVM and thus giving free access to all Java/JVM libs out there with no overhead. The really odd part is that not more people are using Scala as a replacement as most languages -- except C for device level and Erlang for distributed stuff.

My only experiences with HP are good. That is, calculators from HP48GX to the HP49 line ;). Best calculators ever :P.

The scandals that happened (pretexting, spying and whatnots) have little to do with the engineers. However you're right, HP and Compaq (now merged, that can be only worse) always tried to make their memory incompatible, and their hardware seem pretty cheap (then again, nowadays most hardware is). The problem with HP is that they lack a vision, they don't "Invent". Mainly because it's a management/marketing driven company. So I wouldn't mind having HP "on my side" the day they ditch all the white-collars and have a CEO with a vision. HP's CEOs, including the current one, really suck.

On the other hand, HP is the largest technology vendor in terms of sales (before Dell), and thus probably first Windows vendor. They could hurt Microsoft badly if they made the move :).