Typesafe raises $14M to commercialize Scala | Hacker News Reader

Typesafe raises $14M to commercialize Scala

techcrunch.com

157 pointsmrspeaker101 comments

Congratulations to the Typesafe team. As a regular user of Scala, it is very welcome news to see the commercial arm succeed.

It's interesting to watch hybrid open-source/commercial enterprises develop. Getting the revenue stream right is tricky. I could really see the Typesafe Console growing to offer a whole host of monitoring around distributed computing. If Typesafe provided a wrapper around Hadoop that would be a welcome addition.

Glad to see this. As a longtime Java developer I've found Scala has made coding for the JVM fun again.

Feel the same way. It's hard to go back to Java after Scala and, depressingly, at work I have to :( How do I convince my colleagues to embrace the possibility?

Best bet is to write something awesome with it, and mention by the way that it's written in Scala

I'd rather have Typesafe reimplemented Hadoop using Scala (Akka) and wrap it in Hadoop API, than having Hadoop wrapped in Scala API. There are so many things wrong with Hadoop implementation internally, that a complete rewrite would make it good. ;)

The coverage at GigaOm provides a bit more substance.

http://gigaom.com/cloud/typesafe-gets-14m-to-push-scala-as-a...

And there's the Typsafe blog from the source:

http://blog.typesafe.com

In the meantime, in the alternative universe I wish I were living in, the same thing happens to the company behind the widely used Clojure programming language...

The commercial entity behind Clojure, Clojure/core is not modeled in the same way as TypeSafe. Instead, its main focus (at the moment at least) is providing training[1]. The truly commercial entity in the Rich Hickey universe is Datomic and as a result also works under a different model than Typesafe.[2]

[1]: http://roadshow.clojure.com/

[2]: http://www.datomic.com/

I think Rich knows that you can't sell a technology or language, you have to sell a product. That's why he did Datomic.

That said, I write Scala at my current job and am super excited that Typesafe got this funding. Please, Typesafe, follow Rich's lead. Make a real product backed by a technology, not a bunch of libraries! I want you to be around for years to come.

p.s. we're hiring. You don't even have to be super smart, just be passionate. owreese AT gmail DOT com

Typesafe has a product; the Typesafe Stack. It's not just "a bunch of libraries". Add to this the Typesafe Console that you get as part of it (http://console-demo.typesafe.com/) and I think you have a pretty nice and complete product.

    Make a real product backed by a technology

Correct me if I'm wrong, but I believe that they tried that with "Cloud Akka". I do not know the details as to why, but I believe that tech is now open source.

> That's why he did Datomic.

That's definitely one reason. I'm willing to bet the other reason is that he believes that the world needs Datomic. Because it really, really does. His talks make it clear that he deeply understands that.

The world needs another piece of closed source, proprietary infrastructure written in an obscure language?

My number one rule for infrastructure software: never, ever build your business on closed source software. Doesn't matter if it's free, or costs tens of thousands of dollars per month to operate, or is written by a superhuman like developer. You will be hurt Every. Single. Time. if you do.

> another piece of closed source, proprietary infrastructure

No, the world needs a modernized view of the relational database model.

> an obscure language

The APIs are Java-first, Clojure-second. The implementation is a mix of the two. Java isn't that obscure...

> never, ever build your business on closed source software.

I agree with that. Ask any one of my new coworkers how they feel about this company's dependency on Oracle and they'll tell you that they learned that lesson.

I'm not proposing that you take a dependency on Datomic for your startup. I'm saying that there are a lot of enterprises who have no choice, but to take dependencies on things they don't understand because they aren't software companies. Microsoft's entire enterprise business depends on people who want to outsource infrastructure to somebody else, and those customers pay enough money to secure the future and direction of that infrastructure. Rich Hickey & co can capitalize on that group of people. He gets to help them and they'll pay him for it. Along the way, database systems will adopt the improvements and new ideas that Datomic is leading the way with.

The company/startup behind Light Table is trying pretty hard to make Clojure more popular by providing sorely needed tools for it.

This will probably improve Clojure adoption in the long run. It's much easier to go from learning 1 to 2 functional programming languages than it is to go from 0 to 1.

I'd imagine that's the idea behind Datomic, though less direct: create product, get funded/income, make both Datomic and Clojure better in the process.

5th search result for Closure in Google:

http://freegeek.in/blog/2011/06/10-clojure-one-liners/

Tell me that is not Perl all over again.

Clojure is on the opposite end of the spectrum from Perl.

You mean Clojure is unsuitable for writing quick scripts that get things done with the minimum of fuss?

The Perl one-liners that actually resemble line-noise get far more done than any of the examples given above. Perl one-liners that do the same as the above examples are actually quite legible.

They look fine to me and it also look good written in Perl :)

  use List::Util qw(sum max min);

  # 1
  map { $_ * 2 } 1..10;

  # 2
  sum 1..1000;

  # 3
  my @wordlist = ("scala", "akka", "play framework", "sbt", "typesafe");
  my $tweet = "This is an example tweet talking about scala and sbt.";
  grep { $tweet =~ m/\b$_\b/ } @wordlist;

  # 4
  my $file_text = do { local $/ = undef; open my $fh, '<', 'data.txt'; <$fh> };
  chomp( my @file_lines = do { open my $fh, '<', 'data.txt'; <$fh> } );

  # 5
  say "Happy Birthday " . ($_ == 3 ? "dear Barry" : "to You") for 1..4;

  # 6
  my ($passed, $failed) = do { 
    my @p; \@p, [map { $_ > 60 ? push(@p, $_) && () : $_ } (49,58,76,82,88,90)]
  };

  # 8
  min(14, 35, -7, 46, 98);
  max(14, 35, -7, 46, 98);

  my $file_text = do { local $/ = undef; open my $fh, '<', 'data.txt'; <$fh> };

I have absolutely no idea what this line does. local? undef? '<'?, <$fh>? This is how you read a file in Perl?

> This is how you read a file in Perl?

Nope. I use Path::Class from CPAN...

  use Path::Class 'file';
  my $file_text = file('data.txt')->slurp;

I have absolutely no idea what this line does.

If you don't know Perl, why should you expect to? I didn't know that #(...) represented a lambda in Scala until a moment ago.

'Knowing Perl' is a rather hard thing to do when the list of completely ad-hoc implicit variables and hidden context-sensitive surprises is seemingly endless.

Your grasp of English seems to include subject-verb number agreement, and I suspect you can handle pronouns. You'd do just fine with Perl.

Yes, lots of tutorials explain it badly, and yes, lots of people say "Why should a programming language take cues from natural language?", but implicit variables and context are concepts that primary school children have mastered. They're not that difficult.

Yeah, that was not my point. These aren't but idiosyncrasies of Perl's design, and to model itself on constructs which evolved without direction and which take years to master, just to save a keystroke or two once in a blue moon, is a rather questionable road to take.

Seriously, in what other language don't you ever finish discovering what's on the default namespace, what side-effects any given statement, or hell, expression has, or which syntactic forms are supported, and on and on?

Well, PHP, but we know what the connotations of that are.

And by the way, I'm doing rather 'fine' in Perl, if not for the ever-present worrying about type mismatches (particularly arrays), the frustration of how dirty many operations are (unless you are using a recent version, regex substitution must mutate a variable), the laboriousness of the stock error handling mechanisms (make your own stack trace!) and so on.

It represents a lambda in Clojure.

You're right. I typed Clojure the first time, then for some reason uncorrected it.

It's not Perl all over again. Have you even _read_ those one-liners?

Those are neither line-noise, nor fickle one-line imperative solutions.

On the contrary, they are elegant and easy to read --you just have to understand the basics of functional programming, map, reduce, filter and the like (which, in themselves are trivial concepts).

Stuff like those in the article:

(pmap process-line lines)

(dotimes [n 4] (println "Happy Birthday " (if (= n 2) "dear Rich" "to You")))

(reduce max [14 35 -7 46 98])

(def file-text (slurp "data.txt"))

(partition-by #(> % 60) [49 58 76 82 88 90])

(clojure.xml/parse "http://search.twitter.com/search.atom?&q=clojure)

are so easy and clutter-free that what I cannot even begin to comprehend how someone would accuse them of the bad readability that characterises the "Perl one-liner".

To be fair, comparing something like this:

    (partition-by #(> % 60) [49 58 76 82 88 90])

to so-called line noise code seems reasonable enough. As with Perl, if you immediately know what all the punctuation means and what the underlying structure of the language is, it’s concise, but if you don’t, it’s quite a mess of random-looking symbols.

For comparison, here’s a Haskell version, which in this case has a more intuitive syntax, IMHO:

    filter (>60) [49, 58, 76, 82, 88, 90]

And here’s a version in Scala, with a more explicit function value:

    List(49, 58, 76, 82, 88, 90).filter(n => n > 60)

Really? There's only two bits of punctuation there, and they don't take much to explain: #(...) is an anonymous function; % is the argument to that function. (I'm not counting > because ... it's just the greater-than sign.)

The Haskell version doesn't actually do the same thing. The Haskell returns [76, 82, 88, 90]; the Clojure returns ((49 58) (76 82 88 90))---it groups the input according to the result of the function, it doesn't just filter it.

It’s not an ideal example of partition-by anyway, because this particular input has all the values where the predicate returns true together. As you have shown, the result in this case is just to divide the list into the values that match the predicate and those that don’t. This is actually what the “partition” function does in some languages, including Haskell and Scala. However, in general, partition-by in Clojure does more than that and is more like a kind of split algorithm, which this example didn’t demonstrate.

In any case, my point here was about syntax, so I used a standard and easily recognisable function in the other languages instead of getting bogged down in trying to reproduce the exact same behaviour. Apologies if this wasn’t clear.

I know this is a discussion on syntax but I can't help pointing out that the semantics of paritition-by and filter are very different.

True enough, but I figured filter was widely known and partition-by was perhaps a little esoteric. The syntactic argument would be exactly the same if you used an equivalent of partition-by in the other languages.

>(partition-by #(> % 60) [49 58 76 82 88 90])

Yeah, a less noisy way to do it in Clojure would be

(partition-by (partial < 60) [49 58 76 82 88 90])

You are right.

in Perl:

grep { $_ > 60 } ( 49, 58, 76, 82, 88, 90)

Scala : List(49, 58, 76, 82, 88, 90).filter( _ > 60 )

I still hate the square brackets and the slashes.

Sorry, hate is such a strong word.

I mean that I still find the language's typographic irregularities hopelessly distracting to the point where I won't touch it with a bargepole.

They compare to perl one liners more than they do to Lisp one-liners due to their greater syntactic cruft.

I initially disliked the square brakets as well, but I got over it quickly because of the utter happiness I get from writing Clojure code in general.

FYI, the square brackets are not an arbitrary deviation from lisp syntax. Square brackets are Clojure's vector syntax, the use of square brackets in function and macro definitions reflects the fact that they are actually vectors.

Not sure what you meant with your objection to slashes though.

I feel someone should mention this here: Less than a month from now Martin Odersky himself will begin teaching a free online course "Functional Programming Principles in Scala".

https://www.coursera.org/course/progfun

Well, as someone in the last two weeks who:

a) already is using Scala

b) already is using Akka, and

c) wanted a monitoring tool for both (which is part of the "Typespace Stack")

and contacted Typesafe about their subscription, I can tell you that none of this matters for people on HN, product-wise. Their "console" is an obscene amount of money per node per year. Yes, PER NODE.

With just a few nodes, it's literally cheaper to just build it yourself, even if you had to hire a Scala contractor to do it.

So forget scaling linearly up with Typesafe's actual product – you can't afford it.

That said, Scala and Akka are awesome and at least they'll continue to be developed for awhile now.

Play! 2 is cool as well, but being limited to one Play! app per JVM is something we couldn't live with, so we've moved on to Socco.

What is Socco? Google didn't turn up anything.

I'm guessing: https://github.com/mashupbots/socko

Yup, that's the one.

Any particular reason for Socko instead of Spray? (http://spray.cc)

This is great news for the Typesafe Stack. While Scala is bigger then just Typesafe I am glad to see some real support behind the awesome set of libraries they put out.

That is good but I have used Scala before and would not recommend it for an enterprise project. It was rather convoluted and had lots of concepts that just would not make sense to the java programmers in our company.

There would be teams that could have used it and thrived but overall the complexity of the language seemed to outweigh any reasons I could give to use it.

I wish them the best but I think they will have a hard time getting Scala into the enterprise. For smaller companies it probably would make sense.

Ah well not trying to be a downer. :)

Complexity of Scala has been debated many times. Just because a language adds some new concepts and is different than other mainstream languages, is not enough to call it "complex".

Before you answer question about whether Scala is complex, try to answer the following questions first:

Is JEE complex? Is Spring Framework complex? Is Maven complex? Are webservices complex? Is C# complex?

They are, they introduce new concepts and in many ways they have much more rough edges than Scala (remember JEE 2.1?). Somehow all of them have been widely used in enterprise software development in many successful projects.

I'm surprised by how much flexibility Scala offers with so few simple concepts. Ok, you have to take some time to learn them. But this is the same as learning just any new API.

> Complexity of Scala has been debated many times. Just because a language adds some new concepts and is different than other mainstream languages, is not enough to call it "complex".

It seems to me that the JVM community has moved on from Scala and is actively looking for a language that offers most of the benefits that Scala offers without the downsides.

Kotlin (from JetBrains) and Ceylon (from RedHat) seem to be the first two languages with a really interesting take on this problem. Gosu and Fantom are similar attempts, although I think these two already failed to gain traction.

To be honest, by the time they are ready for production, Java 8 will provide the most of the features they are promising. So for developers who only want to have lambdas and slightly better libraries (like ability to call filter on a collection), there is no need to move. Just wait for Java 8.

On the other hand, for programmers doing some more serious stuff than just moving data from database to the website, they offer too little to be attractive, and they actually haven't solved any problem that Scala hasn't solved (Ceylon's generics reification - a good joke, man). They are nowhere near Scala in expressiveness and flexibility and being only slightly better than Java is not enough for power-coders. There were some languages targeted as "better Java", e.g. Nice long time ago and they also failed.

From the alternative languages for JVM, currently only Clojure and Scala (and probably Groovy too) got some serious usage in industry. All others are still in kindergarden.

Just because something is complex doesn't mean it is bad, but something being really really complex (or feature rich), doesn't mean it is good either.

Now I might be mistaken, but Scala is one of rare languages that actually has compiler commands that disable parts of it syntax (or there was a plan to do so). To me that yells - Too complex. I'm quite sure it is powerful. But it doesn't look like something I'd enjoy using.

My main gripes about Scala is that the trait system is way less elegant than the Smalltalk variant [1], there seems to be a hundred different ways to do a thing (as opposed to a more unified way of doing things) and the overall "automagical" implicit. Not to mention the overall verbosity and ways the different features mesh together.

[1]http://www.cs.cmu.edu/~aldrich/courses/819/Scha03aTraits.pdf

As far as I know they haven't implemented disabling parts of the syntax in the compiler, yet. There were plans to do it, due to the fact, that for application coding there, the most controversial features are not used very often, and because of the posts like yours, that Scala is too complex. However, these features are essential for library / framework type of code. Scala collections library could not be that easy to use, powerful and clean if these powerful features like implicits were not in the language. Things like Squeryl could not be implemented, without adding special support in language (like in C#). Scala is pretty simple - just a few, very generic, powerful features, instead of thousands of special cases and compiler quirks.

As for verbosity: I coded a lot in Python, in Perl and then in Scala, and found Scala code to be sometimes even shorter. Note Scala is statically typed, it is harder for statically typed language to be terse. It does pretty well in this area, for a statically typed language.

As for doing things in different ways: in Python they say there should be one obvious way to do it. But it really isn't. Lots of things in Python could be done in different ways. This is inherent to programming, and it is a good thing, making programming more art than craft.

Let's take a look at it from a different angle.

Say, I have a group of developers who have been trained to use Java (both best-practices, idioms, tools, etc).

Let's say that JEE 6 shows up (no, I don't remember JEE 2.1, what is that? is that thing even exist?).

JEE 5/6 introduces a few things on top of my head (please pardon me of the syntaxes):

1) Dependency Injection via annotation (CDI in JEE6, EntityManager in JEE5)

Introduction: annotate the instance property you'd like to inject and GlassFish will magically give the class to you.

Example:

@Inject

AccountService accountService;

2) JAX-RS

Introduction: A class, that works like servlet, but without doGet() or doPost(), instead you have methods that maps to the request-path based on the annotation.

Example:

@Path("/account/{id}")

public Account get(@PathParam("id") final long id)

3) Transaction (in EJB3 which appears in JEE5)

Introduction: Sprinkle annotation in your class or method, you get transaction magically.

Example:

@TransactionAttribute(REQUIRED)

public class AccountRepository

@TransactionAttribute(REQUIRED)

public Account updateAccount(final Account toUpdate) {...}

So I'm not sure how complex all of these to grok, granted if you need to do something out of the ballpark, you may have to learn a bit more of each individual component but to get started and be productive seems quite easy for me.

Now let's compare that with picking up Scala from zero (given that you know Java already) and get comfortable and productive with Scala, its tools, and its libraries to build web-application with the similar setting of that in JEE (web-service, REST, persistence/db/orm/transaction layer, unit-test, integration-test, etc).

No cheating though: no calling/utilizing JEE. Has to use all-things Scala libraries.

"So I'm not sure how complex all of these to grok, granted if you need to do something out of the ballpark, you may have to learn a bit more of each individual component but to get started and be productive seems quite easy for me."

It is so easy only if you don't try to write some serious production level stuff using it. You must be insane to start a project in JEE knowing only some basic tutorials and without deep understanding how the full stack works. I worked for a company that do JEE trainings. It was near impossible to teach a team using full JEE stack in 5 days (7 hour / day) - no, actually each single component is like 1-2 days of training, given that everything is preconfigured and ready to go. And after training they usually ask for consulting, because they still have some technical problems with it.

This is similar to Scala. You have to probably have someone on the team with deep understanding, but most of the coders just need to know how to do basic things in it.

We used Scala for a project in the company, and the only concern then was poor tooling (that was 2 years ago - it is much much better now), not the language itself. Most programmers just jumped right into it as a Java with slightly simplified syntax - "oh, I don't need to know when to use Integer and int, cool!".

// Errata: I meant EJB 2.1, not JEE 2.1, sorry for the mistake.

Actually... I've had previous positive experience dealing with some parts of JEE and some parts of Spring from almost zero (just knowledge on Servlet and JSP) to production level (JAX-RS, JAX-WS, JPA/Spring-Data/Spring-Transaction, Spring-Portlet-MVC, Spring-Core). They just seem to ... "work out of the box".

Had two production issues in a year and they are all JPA.

From all of the modules, JPA seems to be the more complex piece of the puzzle with EJB/JMS probably trailing. (Granted we did not have to use JMS yet).

While I do understand your side of the story (you may be aiming for JEE full-stack from JSP, JSF, Servlet, JPA, EJB and tons of its quirk, JMS, transaction, etc), if you focus to the essential: JEE 6 web-profile, it is much easier compare to starting with Scala from zero to knowing best-practices and idioms of the language.

Agreed, but before JEE 6 web profile, essentially all before JEE 5 was much much harder to work with. Deploying a basic demo EJB 2 app on some ancient JBoss took our team of "enterprise developers" about two weeks. I'm just saying Scala is nothing exceptionally more complex than many other things that are or were used by so called "enterprise developers".

BTW: on the last training in databases I led we used Scala as a language in which some sample programs were created. The group was not specifically prepared for that. Actually they were even not all Java developers. They had no problems in understanding Scala code and modifying it for the purpose of the excercises.

This really just amounts to vague hand-waving that language complexity somehow impacts productivity. Do you have any evidence to back up this fear? C# seems to have done reasonably well in the enterprise, and it has much greater complexity than Java. It doesn't have all the flexibility of Scala but for common use cases I think they are actually pretty comparable. Same goes with F#, which is not tailored to everyone's needs but is there out of the box in Visual Studio (it is an ML-based language). I've never seen it be an actual issue for people who are not experienced with e.g. functional programming, to perform maintenance on a program written with a lot of FP constructs. They may need a little guidance at first but every developer I've worked with loves this kind of stuff when they first see it. Bad code can be written in any language and it usually isn't clever people pushing the boundaries who write it.

You don't typically see F# adoption in the enterprise either -- it's in use in specific business domains like finance, but rarely for writing general-purpose line of business apps.

Really, the "unsuitability" of Scala for the enterprise says as much about the common problems with enterprise development (What, expect developers to learn something new?) as it does about Scala.

I say that as someone who currently does C# work in an enterprise environment in which there is a ban on using "var" to declare variables with type inference.

Apparently

    Dictionary<string,List<string>> dictionary = new Dictionary<string,List<string>>();

makes it really clear what the variable type is, but

    var dictionary = new Dictionary<string,List<string>>();

makes people's brains hurt.

Sigh.

I was in fact just being honest. It is not vague hand waving. I showed many peers what Scala had to offer and it was just not a good fit. Everyone of them thought it was complex. I am not alone in that.

Scala is just a large leap from Java. It just is. I thought it was ok but the reality was it would hurt productivity. I would say the same thing about Clojure. I like clojure a lot but it would be hard to recommend to a large established biz.

I think the bigger hurdle to Scala adoption isn't language complexity, but tooling. It's not as mature as Java tooling, and compilation is dreadfully slow. Typesafe is actually putting some effort in improving Scala tooling, so hopefully the additional funding will help them move the ball faster in that area.

Yes! Exactly. This is the problem, not Scala being complex. Fortunately they are improving fast. FSC support in Idea is pretty good. If you have a decent processor, compilation is no longer an issue.

Scala is really very easy to start for someone who knows mainstream languages like C++ or Java or C# - you just start writing in it like in a better Java, then slowly learn new concepts... For me it took two weeks to feel comfortable with it. Actually much faster than with Python.

Yeah, this is ultimately what prevents me from contemplating using Scala in a broader context. I will admit I haven't tried for a while, but every time I've tried out the Scala eclipse plugin it's been incredibly flaky. For the top tier of developers this doesn't matter too much (they can either handle flakiness or do without an IDE at all) but companies specifically do not want to build their systems dependent on constantly having top tier developers to do every little change they need.

You can contrast with Groovy which while still not perfect, has an awesome eclipse plugin and SpringSource offers a whole customised eclipse version for working with their stuff.

Works just fine for us, even our college sophomore intern had no trouble figuring it out.

"I think I've figured Scala out." http://news.ycombinator.com/item?id=3781276

Guardian, Facebook and Twitter are pretty much enterprise to me.

Such a sad and unfortunately typical attitude of enterprise java developers. No wonder anyone with with any interest in programming avoids java like the plague.

The core problem isn't "java", it's "enterprise".

And seemingly it's the default attitude of people who perpetuate the use of things like Spring as part of their core stack.

don't forgot to add Hibernate to that for everyone still living in 2004

You are 100% correct.

When you give developers a new set of tools they are inevitably going to use them. Some will understand and use them well. The overwhelming majority won't. And in an enterprise environment where you have a higher turnover of developers and tight deadlines it will be the equivalent of a ticking time bomb.

And because the framework is centered around Play which has/had a good reputation it won't invoke that suspicious, foreign language feeling in developers that it probably should.

I very much suspect that the future of Scala is going to rest in the hands of Guillaume Bort's ability to wrap any of the nastiness.

>it won't invoke that suspicious, foreign language feeling in developers that it probably should.

The "foreign language feeling" is a good thing in a developer? Who would have thought...

Talk about narrow horizons...

Reminds me of the Blues Brothers joke: "We play both kinds of music at this bar, country AND western".

Great news! There's more details on the company's blog, too: http://blog.typesafe.com/typesafe-announces-14m-series-b-fin...

"The company was actually founded by the creators of the Scale and Akka programming languages. The Typesafe Stack, which is compatible with Java, combines the Akka middleware framework"

So, TechCrunch, is Akka a programming language or a middleware framework? High-quality reporting as usual from TC.

I'm really rooting for wider adoption of Scala. I think the language hits a real sweet spot and I've been trying to transition to more scala for my android development. It's frustrating when I'm told by colleagues at work that they're basically not interested in doing projects in scala because "our clients sometimes need to be able to understand the code" or whatever other lame excuses.

Heh. Clearly the investors didn't do their due diligence, otherwise they would have known that Scala isn't type safe.

So I get downvoted for pointing out the hubris of naming your company TypeSafe when your language isn't?

I'm guessing you got downvoted because it's a silly point to make. Companies have stupid names all the time. No investor is going to care about that.

There are stupid names and there are misleading names.

There are nitpickers and Nitpickers with a capital N.

I didn't downvote but it's probably because details are needed for the assertion.

This has come up plenty of times on Hacker News with plenty of examples. modersky generally just writes it off as being "harmful" to the community and other nonsense to avoid the issue. Harmful to his valuation is more like it.

Static (and even dynamic) type safety is always a shade of gray vs. a black and white thing. A language that is 100% type safe is a language that doesn't do very much (...or requires a theorem prover). Scala is very pragmatic in that regard.

I'm not sure what world you're living in, but Haskell and ML seem to offer some measure of type safety and are also quite practical. Sure there is unsafePerformIO. But the problem is with Scala you don't even need to use unsafe language features to get an unexpected class cast exception. Given that you worked on Scala I'm rather surprised you don't know about this already.

Could you be more specific? Is the compiler promising more than it can deliver, or are you saying the compiler could check something but simply doesn't?

You can have 100% type safety in a straight jacket, but scala pushes what it tries to type check to an extreme limit; "safe" but then also not as conservative as Haskell or ML. I see scala as the c++ of statically typed languages, filling that niche where you need more from your managed language and are willing to take a leap, but this is controversial and a personal opinion.

Do you have an example of code that will throw an unexpected ClassCastException?

I never, ever had a ClassCastException in Scala that I wasn't warned about by the compiler. Maybe in theory you are right. But what counts is practice.

Scala is type-safe, but type-safe with escape hatches (which every good language has sometimes, when the programmer knows the truth of theorems the type-checker can't prove). It also has an undecidable type system, but then, so does half of everything nowadays.

It isn't even about "escape hatches". There are programs that can be written without any special language features that will cause class cast exceptions. Please do your research.

Perhaps there are, but in over 20000 lines of Scala code I haven't encountered any. So this is a non-issue in practice.

Could you show one?

Dear Typesafe

We are glad you got funded and wish you all the best

Signed: Oracle's legal department

Scala's on top of Java and the JVM; not a reimplementation of it. Oracle appears to be okay with this, and sometimes encourages it.

(Not to imply I'm condoning Oracle's attempted legal smashing of Dalvik)

I'm sure an Oracle acquisition is one of Typesafe's exit strategies.

> Scala's on top of Java and the JVM; not a reimplementation of it. Oracle appears to be okay with this, and sometimes encourages it.

Oracle could change their mind at any time. Some people at Sun appeared to be Ok with Android and sometimes even encouraged it.

What could Oracle do if they changed their mind? Serious inquiry, IANAL, etc etc... I like to avoid speculating about the intersection of tech and legal issues, but is Scala in a very different place than other languages targeting the JVM? Are there any actual legal issues with writing a compiler that emits Java bytecode? This has been going on for a while, maybe as long as Java's been around. There's even some mention of it in the intro to the JVM spec.

http://en.wikipedia.org/wiki/List_of_JVM_languages

http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-1.htm...

Dear Typesafe

Congratulations! Now, please do something about your language's godawful syntax and semantics.

Signed: a frustrated Lisp programmer.

> Signed: a frustrated Lisp programmer.

thanks for the laugh :)

This makes me happy and relaxed. Personally I would really like for Typesafe to be successful with their Scala products and consulting. It would only make Scala prevail and have more support for people like me (who have Scala in their development stack). Contrats!

I anticipate lots of companies commercializing various FP-ish PLs blossoming in next 1-2 years.

Any one know what the Series B valued Typesafe at?

Reply on news.ycombinator.com