Slashdot Mirror

I started using Scala in 2011. The tooling was very rough at first, but I really liked the language as an alternative to Java. Since then I've adopted a progressively more functional style in Scala, and found it to be a very natural way to think about code. Some of my code is multi-threaded, and using immutable data structures, I find I spend a lot less time worrying about locking. And the tooling is now fairly reasonable in my opinion. Scala's interoperability with Java was a big selling point in the early days, but the Scala ecosystem is now getting to the point where it stands on its own rather well.

A really great development in the Scala world is Scala.js, which transpiles Scala to JavaScript. I despise JavaScript for any development larger than a page of code, so Scala.js was a welcome relief. If you work on large JavaScript apps, do yourself a favor and check out Scala.js. I look forward to the day when WebAssembly matures enough to be a target for Scala compilation. Hopefully then JavaScript will fade away, and someday it will just seem like a bad dream.

Wait, what? if lambdas are shit programming why did almost every language add them as a features in the last 5-10 years? including c++.

I think you have mostly missed my point, Scala has research oriented roots, and it you're not ok with that, fine. But if it makes you a more efficient programmer, it might just be worth the effort of picking up.

Also, this is what I mean by pattern matching:
http://docs.scala-lang.org/tut...
https://doc.rust-lang.org/book...
https://developer.apple.com/li...

The answer is the Option type. It's been around for ages, and it's easy to implement yourself in languages that do not support it natively. Scala even comes with a number of handy methods that make working with Java-style (i.e., nullable) data types a bit easier.

The issue isn't that nulls don't serve a purpose. You're right, they do. The issue is that it is very difficult to know statically (i.e., before your program runs) whether you've handled them all correctly or not. Option make this handling a part of the type system, thus if you fail to check for null, your program will not compile. That's a good thing.

Same with Java and Scala. A strongly functional language that allows you to keep using the thousands of Java libraries out there.

Java is moving into archaic irrelevance faster than ever. That is, the language itself.

The JVM, however, is now more useful and relevant than it ever was. It used to be naught but an implementation detail. Now, rather, it's central to an entire ecosystem of languages that will inevitably send Java the way of C: used only when the greatest speed is necessary.

Scala is basically a next-generation Java. Java with functional programming, or really, vice versa. JRuby make Ruby actually scalable, given the presence of native threads and interoperability with existing enterprise libraries that commonly only ship in the form of Java or C# libraries. Clojure enables LISPers of yore and Schemers of new import explore functional programming as it used to be, without having to drop the wealth of Java libraries available. Ceylon, Groovy, Jython, and dozen of others are paving a way to give the JVM much more to do after Java becomes obsolete.

Java will never die - it'll just become like COBOL, Fortran, and C before it: used in enterprise software, operating systems, and outdated educational assessments.

I am surprised that Scala isn't mentioned.

It is strongly typed, object-functional and compatible with java.

Swift syntax is basically a cut and paste from Scala, which benefits from being more mature (and having access to all the Java libraries)
Scala is also much faster than erlang, while also supporting the actor based model.

http://www.scala-lang.org/

I've been programming in Java since it first came out, and I never had any particular problems with it, other than the fact that it's rather verbose. I've been thinking there must be a way to accomplish the same thing without so much boilerplate code. Then I discovered Scala (which runs on the JVM and can easily integrate with existing Java libraries). Mind you there are some things about Scala that are kinda weird, like so much optional syntax and type inferencing makes it sometimes hard to read. But I've been finding it a joy for new code I write, almost Java-like but much less verbose, plus you get the functional programming capabilities that Java lacks. Some of the library code that's out there is hard to understand because of the nature of the syntax, but after you study it a bit, it's not too bad.

For those of us old enough to remember, Java is, in fact, the new COBOL. COBOL, like Java, was the language of choice for software engineers of a bygone era (the 1970's), and suffered from a similar verbosity, clumsy syntax, and prevalence of boiler-plate code (substitute copylibs for jars and you are halfway there). I wrote COBOL for a living for decades and never, ever, coded most of the mandatory code sections.

When I was engaged in my first enterprise level Java project (a JBoss app), I was amazed at the similarities between the two languages. Despite the fact that the syntax and structure are completely different we have the same slavish devotion to form and "correctness". Of course, most people alive and writing code now are completely unaware of this, having never encountered COBOL in an enterprise environment.

Not saying this is a bad thing. Just saying. COBOL was also more or less controlled by one company, and that company was IBM due to the IBM's complete dominance of the mainframe market.

I've been programming in Java since it first came out, and I never had any particular problems with it, other than the fact that it's rather verbose. I've been thinking there must be a way to accomplish the same thing without so much boilerplate code. Then I discovered Scala (which runs on the JVM and can easily integrate with existing Java libraries).

Mind you there are some things about Scala that are kinda weird, like so much optional syntax and type inferencing makes it sometimes hard to read. But I've been finding it a joy for new code I write, almost Java-like but much less verbose, plus you get the functional programming capabilities that Java lacks. Some of the library code that's out there is hard to understand because of the nature of the syntax, but after you study it a bit, it's not too bad.

Then you're poorly informed.

Just write a program to execute at toplevel of a .scala file (instead of inside a main class, as usual), and run it as script with "scala filename.scala", or add a "#! /usr/bin/env scala\n!#" at the beginning - it had this ability since ever.

It also has plenty of niceties for using as scripting shell, like this.

Scala 2.11 also adds support for using Scala interpreter through standard Java Scripting Engine interface.

If you are a software developer, and don't find use for arbitrarily large number of cores... Time to get up to date!

That's why I'm so excited by the new breed of languages like Scala.

Sure, there's no silver bullet to automagically solve all parallel programming problems, but languages like Scala have features like Parallel Collections libraries, functional programming and Parallel Domain Specific Languages that can abstract enough of the problems of parallel programming away that journeyman programmers have a decent chance of being able to work effectively with multiple cores.

I'm somewhat disappointed by the adoption curve. The reluctance to move toward an actual solution to the problem is somewhat surprising.

This is also the real reason behind NoSQL databases... the need to scale horizontally instead of vertically is the primary driver, not a disdain for SQL.

If you are a software developer, and don't find use for arbitrarily large number of cores... Time to get up to date!

That's why I'm so excited by the new breed of languages like Scala.

Sure, there's no silver bullet to automagically solve all parallel programming problems, but languages like Scala have features like Parallel Collections libraries, functional programming and Parallel Domain Specific Languages that can abstract enough of the problems of parallel programming away that journeyman programmers have a decent chance of being able to work effectively with multiple cores.

I'm somewhat disappointed by the adoption curve. The reluctance to move toward an actual solution to the problem is somewhat surprising.

This is also the real reason behind NoSQL databases... the need to scale horizontally instead of vertically is the primary driver, not a disdain for SQL.

If you are a software developer, and don't find use for arbitrarily large number of cores... Time to get up to date!

That's why I'm so excited by the new breed of languages like Scala.

Sure, there's no silver bullet to automagically solve all parallel programming problems, but languages like Scala have features like Parallel Collections libraries, functional programming and Parallel Domain Specific Languages that can abstract enough of the problems of parallel programming away that journeyman programmers have a decent chance of being able to work effectively with multiple cores.

I'm somewhat disappointed by the adoption curve. The reluctance to move toward an actual solution to the problem is somewhat surprising.

This is also the real reason behind NoSQL databases... the need to scale horizontally instead of vertically is the primary driver, not a disdain for SQL.

Thankfully there is scala ( http://www.scala-lang.org/ ) on the JVM to advance language functionality while Java is not. I would say C# and scala are more feature similar than C# is to Java anymore, especially if Macros end up coming out of the Roslyn project.

Too old? No, you're just unlucky where you are just now.

Learn how to do Test Driven Development. Chose a cross-platform language/environment (even the venerable Java) and learn how to work in vertical slices, implementing features at a time.

Get good and criticising your own work, and improving it. Read and re-evaluate. Look at other peoples' stuff and evaluate their advice.

Learn something cool and cutting edge like scala which will be like a breath of fresh air compared with VB.NET (and it runs on the JVM).

Get out there and look at new and varied languages. Read lambda-the-ultimate. Do some scheme, do some FORTH, look at D. Look back at C and assembly language/

There's so much cool stuff out there, and it will inspire you.

Ditch the Microsoft ecosystem stuff and get ahead of 90% of people in the job market.

Then decide whether it's time to throw in the towel.

I have two suggestions that are close to staying with Java:

(1) Check out Spring (http://www.springsource.org/); Spring has a bunch of goodies that make developing web apps easier, and the guys from spring (Adrian Colyer, Richard MacDougall) are thinking really hard about scalable web services. This is a foundation that will let you write in Java but still be prepared for the future.

(2) Even better, don't go with Java, but leverage some of what you learned and pick up Scala. See http://www.scala-lang.org/, or pick up Martin Odersky's book. Think of Scala as what Java would be if someone who appreciated terse, expressive syntax and great convention redesigned Java. Odersky wrote a reference JVM implementation while at Sun, and Scala compiles into Java bytecode and can directly use Scala libraries. (My first Scala project, for example, I used unboundid's LDAP libs directly in my Scala code.) Odersky along with some other luminaries (Viktor Klang, Paul Phillips, etc) have formed Typesafe, and are producing Scala the language + Akka (an actor framework) + Play (a web framework). Outside of play, many people are huge fans of Lift, and it does have some magic that no other framework has.

Remember how you said "modern" web application? Well, Scala supports functional programming, and you can fix functional and imperative code in the same application, which means you can support massively scalable sites by writing clean, idempotent code where needed.

If all this sounds bad, then I'd recommend Django+Python, as it is, imo, the best way for a relative web novice to produce decent code, and the amount you can do with a few hours reading docs and then digging in is shocking.

Java was one of the first languages with a large standard API. It has nice documentation, but the language is barely better than C/C++. An ecosystem has developed around Java bytecode, however: languages like JRuby and JPython can run like Java and interface with Java code. There's also "groovy", a "modern" language built entirely around Java bytecode.

When talking about JVM language ecosystem, the two names that should always be named are Clojure - a modern Lisp dialect with emphasis on concurrency, and Scala - the king of the modern "kitchen sink" approach of programming language design.

although multicores are good, there just aren't that many decent parallel programmers out there. I (and a few others) find parallel programming easy

That's why languages like Scala are so appealing.

Sure, there's no silver bullet to automagically solve all parallel programming problems, but languages like Scala have features like Parallel Collections libraries, functional programming and Parallel Domain Specific Languages that can abstract enough of the problems of parallel programming away that journeyman programmers have a decent chance of being able to work effectively with multiple cores.

although multicores are good, there just aren't that many decent parallel programmers out there. I (and a few others) find parallel programming easy

That's why languages like Scala are so appealing.

Sure, there's no silver bullet to automagically solve all parallel programming problems, but languages like Scala have features like Parallel Collections libraries, functional programming and Parallel Domain Specific Languages that can abstract enough of the problems of parallel programming away that journeyman programmers have a decent chance of being able to work effectively with multiple cores.

although multicores are good, there just aren't that many decent parallel programmers out there. I (and a few others) find parallel programming easy

That's why languages like Scala are so appealing.

Sure, there's no silver bullet to automagically solve all parallel programming problems, but languages like Scala have features like Parallel Collections libraries, functional programming and Parallel Domain Specific Languages that can abstract enough of the problems of parallel programming away that journeyman programmers have a decent chance of being able to work effectively with multiple cores.

I agree, but in such cases, isn't the solution to make current "fun" languages more "enterprisey" by improving the back-end toolchain?

I have found a very good mix of fun and "enterprisey" in Scala. Runs on the JVM, excellent Java interoperability, statically type-checked with some level of type inference and a very dynamic feel.

It's nice that they finally got the standard done. But there's so much junk in there. The C++ committee was dominated by people who wanted to do cool things with templates.

Some years ago, someone figured out that it was possible to abuse the C++ template system into doing arbitrary computations at compile time. This developed a fan club. That fan club has dominated the C++ standards committee, because nobody else cared. So now we have a standard for C++ which supports template-based programming a little better.

Not really. The standard provides improved support for generic programming: things like move contructors which, once in use by the STL, will make all your code a little faster, things like auto typing that make using STL and other templated libraries easier, things like lambdas that make using functional programming with STL algorithms a little easier etc. Generic programming is not template meta-programming, and it is one of the great things about C++ and it's libraries, as I thinkt think any serious C++ user will agree.

And the parts of the new standard that are likely to have the most impact have nothing to do with templates: like the fact it finally provides a standard way of doing concurrency.

Current thinking seems to be that, while template programming is too hard for ordinary programmers, the templates will be written by l33t programmers and then be used by the lower classes. Unfortunately, if anything goes wrong, the end user has to look at the innards of the template to find the problem.

This is something that the new "concepts" are supposed to fix (by providing more informative errors that do not involve template innards, at the price of a little extra work for the library developer). Unfortunately concepts did not make it into this standard. I agree that full-fledged template-meta-programming is a pain to use, but I do not think any of the STL libraries go that far... you have to look around in boost to find extreme implementations of that concept, like boost::matrix, which I would not recommend to the faint of heart.

Note what isn't in the new C++. There's no more memory safety than in the old one. (Fans will say that it's safer if you only use the new features. Now try to call some library that doesn't use them.) So the buffer overflow attacks and crashes will continue.

C++ is the only language to offer hiding without memory safety. Hard-compiled languages from Pascal through Go have hiding with safety, as do all the major scripting languages. C has neither hiding nor safety; the pointer manipulations are right there in the source. There have been safe, hard-compiled languages without garbage collection, most notably Ada and the Modula family. Safety and speed are not incompatible.

If by "safety" you just mean array bounds checks, you can enable bound checks for vector in C++ with a compile-time switch, or implement your own vector subclass that does checks. This may have some performance impact for certain workloads. But that's not the same as real memory safety. I don't think anyone has yet solved the problem of designing a memory safe language without garbage collection. Oh, and according to this benchmark https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf, Go is about as slow as Java, and is 3x slower than C++.

The word reference doesn't always mean exactly the same thing as pointer (See C++). I imagine Hoare did not mean "null pointer" when he said "null reference".

In the context of ALGOL, it does mean the same thing. And it's precisely what Hoare meant. For an example of how null references are handled properly, see type "option" in ML, "Option" in Scala, or Maybe in Haskell.

The point is that the value domain of the type should not by default have some special magic value for which most operations are suddenly invalid (and will fail at runtime!). It's defeating the purpose of type checking. The proper way to do so is to force programmer to 1) explicitly mark all places where nulls may occur, and 2) check for null before trying to do anything with nullable value. This is best done on type system value, where for every type T, you have a distinct type that represents "T or null".

Note that this all has little to do with physical representation. For pointers/references, it's logical to represent a nullable pointer in the same way as a non-nullable one, and treat all-bits-zero as null. For something like nullable int, you'd need a separate flag to indicate null. But this is something that the compiler should take care of, not the programmer. The point is that type system should not let you do crazy stuff without explicit unsafe casts.

Google has released a research paper (PDF) that suggests C++ is the best-performing language on the market.

No, they didn't. They compared four languages (C++, Go, Java and Scala) using a single algorithm, and two implementations (initial and improved) per language. Out of those, the optimized C++ turned out to be the fastest and the least memory hungry, whereas the improved Scala version used the least source code, and the improved Go version compiled the fastest.

None of this allows generalization to "best-performing programming language on the market".

It's not for everyone, though. They write, '...it also required the most extensive tuning efforts, many of which were done at a level of sophistication that would not be available to the average programmer.'

This is a very important point. If you are Google, you probably have developers who can do this kind of tuning, and you will probably benefit from it (the developer effort is expensive, but inefficient software may well be more expensive at Google's scale).

In general, though, what you want to consider is not only the best performance that has been produced by the world on a single problem, but also the performance on different problems, the variation in performance between implementations, the average performance, and the development time.

In 2000, Erann Gatt (now Ron Garret) published a paper (PDF) that showed the results of comparing 16 implementations written by 14 programmers, in C or C++ (lumped together), Java, and Common Lisp or Scheme (lumped together). These results show that the fastest programs were written in C or C++, Lisp produced the fastest programs on average, and offered the least variation in performance. Lisp also offered the shortest development time on average.

Of course, this is old data. If anyone has performed a similar study more recently, or including different problems to be solved rather than a single one, I would be very interested.

Meanwhile, the Computer Language Benchmarks Game compares many language implementations across several different tasks, with multiple programs for each task, and shows that the results differ depending on exactly how you measure.

Apparently, if you want the fastest programs, you should go with C, C++, Ada, ATS (Fortran, Common Lisp, and Python also produced fast programs, but weren't as good on average). If you want short programs (which may be expected to correlate with short development time), you might want to go with Ruby, Python, Perl, Lua, or JavaScript. If you want short development time, but also reasonable performance, then Go, Scala, or Haskell may be good choices (or you could go the time-tested route of writing what you can in rapid development languages, and the parts that need to be fast in high-performance languages).

The Scala community has tried to move the problem into a more practical realm by adding things like parallel collections, DSL's to abstract out the problem for specific applications and the Akka Project for simpler concurrency.

Most of the parallel programming discussion I've seen is very complicated and not likely to appeal to those who have to do practical day-to-day business projects. By pushing the abstractions up a level, I think the Scala folks have made parallel programming more accessible for the average developer.

Ref: Parallel Collections video.

The Scala community has tried to move the problem into a more practical realm by adding things like parallel collections, DSL's to abstract out the problem for specific applications and the Akka Project for simpler concurrency.

Most of the parallel programming discussion I've seen is very complicated and not likely to appeal to those who have to do practical day-to-day business projects. By pushing the abstractions up a level, I think the Scala folks have made parallel programming more accessible for the average developer.

Ref: Parallel Collections video.

The Scala community has tried to move the problem into a more practical realm by adding things like parallel collections, DSL's to abstract out the problem for specific applications and the Akka Project for simpler concurrency.

Most of the parallel programming discussion I've seen is very complicated and not likely to appeal to those who have to do practical day-to-day business projects. By pushing the abstractions up a level, I think the Scala folks have made parallel programming more accessible for the average developer.

Ref: Parallel Collections video.

What do you guys think of this? In Scala, things like throws are annotations (at least so I read here). In Ceylon, things like shared are annotations. In Java, though, they're "reserved words".

The Scala and Ceylon approach seems, at first glance, a consistent one, in the sense that those things are information about the code, which qualify to be called "meta-programming". What I mean is: if you strip all classes of those "private", "final" and "throws", they'd still do the same thing. Thus, it seems to fit the "meta-information" concept.

Just for fun, the last few weeks I've been toying with the syntax of a programming laguage in which all these things are meta-information. The programmer can, in fact, create his/her own annotations which and be directly used in the code, without a marker operator (such as Java's @) to make the task of the parser simpler. It would, in turn, make the language appear extensible.

In order to do this, the reserved word private, for instance, is removed from the list of the language's reserved words, and implemented as an annotation. That annotation is part of a library distributed with the compiler, pretty much like distributing the java.lang package along with the javac compiler, and making all of its classes usable without import statements. I borrowed the idea from the Scala "syntactic sugar" for operators. Scala folks cleverly say that this: 1+1 is syntactic sugar for this: 1.+(1).

My idea is to allow the programmer to use a simple syntax when applying an annotation on an artifac (a class, an interface) that looks, when reading the code, like it is part of the language. private final class MyClass would become an abbreviated form of this: @private(value=true) @final(value=true) class MyClass. In the Celyon slides, doc is an annotation, by is an annotation, and so on. So I think they beat me to it.

I'm far from pretending to be an expert in programming language or compiler design, nor have experience with a huge span of languages. But I believe the compiler should work for the programmer, and make his life easier, and not the other way around.

Agreed. In fact Scala has introduced Parallel Collections with version 2.8 that allow looping methods on parallel collections that spread the work of the iterations across multiple processors and handle the partitioning of the work automatically. Very cool stuff.

Agreed. In fact Scala has introduced Parallel Collections with version 2.8 that allow looping methods on parallel collections that spread the work of the iterations across multiple processors and handle the partitioning of the work automatically. Very cool stuff.

NOOOOO!

"To handle the peak rates of Tweeting, 5000 per minute during the Obama Inauguration, Robey Pointer at Twitter has moved their main message queue from Ruby to Scala for improved performance. He explains the concepts behind the Twitter Kestrel project on his live journal and the more concise 1500 lines of Scala code can be seen as open source project here."

http://www.scala-lang.org/node/1008

http://blog.twitter.com/2009/01/building-on-open-source.html

No, it's not because of too much FP. It's because Scala has some really weird stuff in it, such as implicit parameters (where values are conjured out of thin air if not explicitly provided).

Or, say, implicit type conversions for the left side operand of "." (receiver) - so in "a.b", if the type of "a" doesn't have member "b" in it, the compiler will look for all accessible conversions from "a" to something else which does have "b".

This kind of stuff means that you can be looking at one simple line of code, which actually does a lot more than you think it does due to all the implicit stuff happening behind the scenes. What's worse is that the above is possible even when you have just wrote that line.

Just take this call it Java 9 or some such, and fire the remaining Java compiler people. Keep the VM people. There, solved it for you Oracle.

It's too bad that some of the most promising new languages (Scala, Clojure) are JDK based.

Scala runs on the .NET platform too. http://www.scala-lang.org/node/168

No thanks Microsoft, I already have Scala.

Actors are a really good framework (with a few different implementations) for easy parallelization. Scala has an implementation of Actors as part of the standard library, so they really are first-class citizens.

You can use Scala, which, as a language, is far superior to anything iPhone (and pretty much every other platform) offers in terms of expressiveness. I don't know about other languages targeting JVM, but I wouldn't be surprised if some of those were available, too.

And, of course, there's the NDK.

Java is legacy by now. It would be better left alone.

If you want more advanced features and a more complete thought out language, switch to Scala.

http://www.scala-lang.org/

I firmly belive that Scala will take over from java in the next years.
More info: http://www.infoq.com/news/2009/07/scala-replace-java

>>I think Java would be pretty good if it adopted public: and private: from C - also var from javascript, for declarations where you don't want to type out ArrayList myList = new ArrayList();. Just a few tweaks here and there would make Java so much more legible, and cut down on the typing a lot.

Check out Scala, a JVM language. Scala not only reduces declaration cruft, but it introduces a variables vs values (final variables) distinction that decreases the possibility of modifying what should be a one-time calculated value.

val age:Int=22
var numPrimesFound:Int=0

There other other sources than The Register, including posts by Twitter devs linked from the Scala language site.

You can import class files compiled from other languages such as Scala, Jython, etc.

http://blog.headius.com/2009/08/return-of-ruboto.html
http://www.scala-lang.org/node/160

With Java's built in support for dynamic languages, and a little more time, you'll able to compile any language of your choosing into a .class that can be used in Android.

I can't give opinions on all of these (and some are still in development at this time anyway), but here's a list of some languages with paralellism designed in:

• Erlang -- Very popular message passing/actor model based language.
• Scala -- A functional language with actor model concurrency for the JVM.
• Oz -- An exceptionally multiparadigm language.
• Occam-pi -- The modern version of the old occam for transputers; CSP style concurrency (I believe).
• Chapel -- Cray's parallel programming language for supercompters. Cray's entry into DARPA's HPCS programming language competition.
• X10
• Fortress -- Sun's language for serious scientific computing. It was Sun's entry into DARPA's HPCS programming language competition, but lost and is now open sourced.
• Eiffel SCOOP -- An effort to take a CSP model and make it elegantly compatible with object oriented programming

Note there is nothing inherently functional about pattern matching.
It's just a feature that happens to be popular in the ML/Haskell world.

Yes, I know. But so long as we stick to strict definitions, any language with first-class function values is functional, and sometimes this results in some unconventional classification.

So, in practice, when people talk about FP languages, they really mean a certain set of features, and first-class functions are only one part of that. Pattern matching had historically been another distinctive feature of the same class of languages.

The equivalent with OO is a visitor. It tends to be more verbose due to lack of functional glue. But with anonymous classes or functions, it's not much more verbose anymore (and at least the parsing is clear to a human).

Even with lambdas, visitors are still very verbose compared to pattern matching if only because you have to write the visiting code.

By the way, there's nothing precluding one from doing proper pattern matching with an OO type system, without any need for hacks such as visitors. Scala does just that.

What about OpenJDK or Scala?

Oddly yes, it is easy to program with, at least going by my experience with HyperTalk (HyperCard scripting language) 20 years ago.

I’m a decent programmer, and was then too, but actually the English-like scripting language was a joy to use—at least for the things I used HyperCard for.

I’m quite willing to believe that this thing can make programming easy for ‘non-programmers’ for certain kinds of problems. It’s not going to be the next Java, but then we already have the next Java.

So I'm going to trot out a different perspective; enough others will thrash through the personalities under discussion here. In my view, Mono is essentially irrelevant. Some folks will use it to bridge apps around platforms, instead of Qt or a handful of other approaches. Yawn. Internally, Microsoft has done some pretty neat things with their various implementations of the CLR (the VM underlying C#). This is unsurprising, as they're well capable of hiring some pretty bright folks. But I doubt that any of that will ever really inform the broader computing community.

In contrast, the JVM seems to be undergoing a renaissance. There's tons of programming language work on the JVM these days: Scala, JRuby, Clojure, Jython, etc. Each of these are bringing their own communities and problem domains to the JVM, and have already broken new ground in language implementation and design. As for new frameworks, there's scalable computing work going on under the Hadoop project (Google filesystem, Bigtable, and map-reduce for-the-rest-of-us) and the really interesting related framework Cascading. With the JVM as an interoperability platform, these languages and various new frameworks all get to be combined together in fascinating new ways.

Do you have any references for your claim that Scala generics aren't implemented via type erasure? Because I have provided some links discussing that in the post you've replied to, and they agree with my point of view (that type erasure is there).

Actually, let me just use the primary source. See Scala Language Reference, 3.7 "Type Erasure", and all references to it in the same document. In particular:

Example 8.3.2
Consider the program fragment:

val x: Any
x match {
case y: List[String] => ...
}

Scala does not maintain information about type arguments at run-time, so there is no way to check that x is a list of strings. Instead, the Scala compiler will erase (paragraph 3.7) the pattern to List[_]; that is, it will only test whether the top-level runtime-class of the value x conforms to List, and the pattern match will succeed if it does. This might lead to a class cast exception later on, in the case where the list x contains elements other than strings. The Scala compiler will flag this potential loss of type safety with an "unchecked" warning message.

The code snippets on the website http://www.scala-lang.org/ are intriguing. It's certainly a terse language. That's both good and bad.

Terse is mostly good, as long as it doesn't come at the cost of readability (see Perl for an example of that). Scala, while being about as terse as Ruby, doesn't seem to be quite as readable, unfortunately. But maybe the code snippets I've looked at aren't the best examples.

My point is that Scala is most certainly not re-inventing Perl.

True, it also doesn't appear to be a reimplementation of anything. It's somewhat related to Java (Scala programs execute with the JVM).

The code snippets on the website http://www.scala-lang.org/ are intriguing. It's certainly a terse language. That's both good and bad.

not rto be forgotten in the language department:Scala and Groovy

The ability to cleanly interface with raw pointers etc also sounds like it could be useful for systems-type programming, e.g. doing ioctls! - though I have no idea how good Java is at this these days.

Java type system is really lacking there - as a strictly verifiable language with no possibility to opt out, it doesn't have pointers or anything like that. Another minor issue is the lack of unsigned integer types (C# has those), but this is more an annoyance, as it just requires extra casting back & forth to achieve the same things.

When doing low-level interop in C#, you normally just have to redeclare the C function signature in C#, and that's it; e.g.:

static class NativeMethods {
    [DllImport("libc", CallingConvention = CallingConvention.Cdecl)]
    static extern long write(int fd, void* buf, ulong count);
}

A similar thing is available for Java, but it's a non-free third-party product; and, of course, type system mismatch is still an issue, so you have to jump through some hoops to get correct declarations for more tricky C signatures. On the other hand, the only thing that C# can't properly map are C variadic functions such as printf - you can write an separate overload for every combination of variadic argument count & types that you'll need, but you can't write a single generic overload that would just work.

Speaking of system programming, Mono specifically has some nice stuff available out of the box on Unix-likes.

The reason I like Python particularly is that it has generally provided me with a good balance of non-verbose syntax, functional features and nice libraries - C# sounds like it offers similar benefits the same, only probably a bit more strict and with better performance given a decent JIT.

If you like the high-level features specifically, have a look at Scala, too. It builds on JVM (they made a CLR version, too, but that one is hopelessly outdated now) and lets you interop with Java libraries, but otherwise it's a very neat modern language with all the same benefits as C#, and plenty more - functional-style pattern matching, traits, mixins... If C# is one step further than Java, than Scala is one step further than C#. The only annoyance with Scala is that they use crippled Java generics (for the sake of interop).

The only real problem with Scala is that it doesn't have any corporation backing it. As such, it's not a language widely used in production (though it's definitely feasible to use it so), and its tooling, while mostly good enough, is lacking features when compared to both major Java IDEs (Eclipse, NetBeans...), or Microsoft's .NET offerings such as Visual Studio.

However, if we are talking specifically of FOSS environment (i.e. non-Windows), then existing Scala tools are quire comparable in stability and features to e.g. MonoDevelop.