3 ms·

> C++ is universally regarded as a language for large system development. Actually, C++ is a terrible language for large system development. Far worse than Rub

> C++ is universally regarded as a language for large system development. Actually, C++ is a terrible language for large system development. Far worse than Ruby. Then again, I'm not entirely convinced that Ruby is a great language for large system development, either: monkeypatching in a 50-developer project = teh evil. Of course, you can at least solve the worst problems with Ruby with coding standards. C++ problems are more fundamental. > My heresy is that static type checking is white elephant. I've been doing this kind of work for going on 15 years now, and I can count on 1 hand the number of head-scratching bugs I've had due to type safety, and that includes 100kloc+ components built entirely around void* closures. The things that really fuck you in large systems are object lifecycle and concurrency. If you use a powerful static type system (i.e. neither Java's nor C#'s) intelligently, you can sidestep whole categories of problems simply with proper type declarations -- for example, by using different types for escaped and unescaped string data from users. In any case, the real reason that enterprises are more comfortable with Java and .Net than dynamic languages for major projects isn't speed, it's that the deployment and monitoring infrastructure is mature and well-understood. Obviously, many enormous websites have been deployed on dynamic languages, but enterprises have a much higher comfort level with the tools available for Java and .Net than the tools for doing this with Ruby, et alia. That's why you see a lot more enterprise traction for solutions like JRuby -- problem solved, as far as they're concerned.

tptacek 18y ago
So, the answer to our problems is neither C++, nor Java, nor C#, but rather an unnammed (let me guess: Haskell) statically typed language that no large system has ever been built in.
- wanorris 18y ago
  Actually, I think Scala and F# are good incremental solutions that can use existing infrastructure and approaches to scaling. The risks of moving to a language that can perform better static checks but retain the rest of an existing deployment stack are actually quite low. They also have the advantage of interoperating with dynamic languages such as JRuby, IronPython, and others to allow you to deploy a mixed static/dynamic solution and optimize for which language style is the best fit for particular parts of the solution.
  - tptacek 18y ago
    And the largest system built in Scala would be...?
    - wanorris 18y ago
      Congratulations on spotting a single keyword and otherwise failing to read the entire post! Throwing your fucking "credentials" around and writing your own assembler out of Ruby or whatever doesn't excuse you from exercising some basic fucking reading comprehension. The largest system built in Scala is probably pretty small at this point. But like I said if you had bothered to read the fucking post, the risks of moving to a new language when you can keep the rest of a deployment stack are relatively small. You're compiling to the same bytecode, running on the same VM, running on the same server, and so forth. Your IT department or hosting provider doesn't even need to know you switched languages. Please, do me a favor. If you're going to respond to this and tell me that Ruby is the most proven language ever and you can't trust Scala to display hello world, could you try to read the post this time and make at least a passing attempt to respond to the substance of it?
      - tptacek 18y ago
        Wow, that struck a nerve, didn't it?
        wanorris 18y ago
        Thanks for making it clear that you have nothing to contribute to the substance of the matter except for snide remarks.
        tptacek 18y ago
        You went from reasonable-but-wrong to very-angry in the span of just one comment. Why are you taking this personally? I'm sorry, but the fact that neither Scala nor F# have ever been successfully used in a well-known large-scale project is a substantive argument. Address it! I'm not a fan of C++ either, but guess what? It has a better track record than Scala. The idea that I'm going to pick Scala over Java "because they run on the same VM" is as silly as the idea of me trying to sell management on building their next product in ObjC, because, after all, they're both generating the same native X86 code. Of course, the real costs and risks have to do with training, maintenance, community, and support, which is why we still use Java. I'm not sure if you noticed like 4 comments above, but I'm a systems programmer; I have no idea why you think I care that something runs on the JVM. I do, however, sell to enterprises. The VM they care about isn't the JVM: it's VMWare ESX. You could write your app in SNOBOL and they won't care as long as they can plug it into their clusters.

tptacek 18y ago

So, the answer to our problems is neither C++, nor Java, nor C#, but rather an unnammed (let me guess: Haskell) statically typed language that no large system has ever been built in.

wanorris 18y ago
Actually, I think Scala and F# are good incremental solutions that can use existing infrastructure and approaches to scaling. The risks of moving to a language that can perform better static checks but retain the rest of an existing deployment stack are actually quite low. They also have the advantage of interoperating with dynamic languages such as JRuby, IronPython, and others to allow you to deploy a mixed static/dynamic solution and optimize for which language style is the best fit for particular parts of the solution.
- tptacek 18y ago
  And the largest system built in Scala would be...?
  - wanorris 18y ago
    Congratulations on spotting a single keyword and otherwise failing to read the entire post! Throwing your fucking "credentials" around and writing your own assembler out of Ruby or whatever doesn't excuse you from exercising some basic fucking reading comprehension. The largest system built in Scala is probably pretty small at this point. But like I said if you had bothered to read the fucking post, the risks of moving to a new language when you can keep the rest of a deployment stack are relatively small. You're compiling to the same bytecode, running on the same VM, running on the same server, and so forth. Your IT department or hosting provider doesn't even need to know you switched languages. Please, do me a favor. If you're going to respond to this and tell me that Ruby is the most proven language ever and you can't trust Scala to display hello world, could you try to read the post this time and make at least a passing attempt to respond to the substance of it?
    - tptacek 18y ago
      Wow, that struck a nerve, didn't it?
      - wanorris 18y ago
        Thanks for making it clear that you have nothing to contribute to the substance of the matter except for snide remarks.
        tptacek 18y ago
        You went from reasonable-but-wrong to very-angry in the span of just one comment. Why are you taking this personally? I'm sorry, but the fact that neither Scala nor F# have ever been successfully used in a well-known large-scale project is a substantive argument. Address it! I'm not a fan of C++ either, but guess what? It has a better track record than Scala. The idea that I'm going to pick Scala over Java "because they run on the same VM" is as silly as the idea of me trying to sell management on building their next product in ObjC, because, after all, they're both generating the same native X86 code. Of course, the real costs and risks have to do with training, maintenance, community, and support, which is why we still use Java. I'm not sure if you noticed like 4 comments above, but I'm a systems programmer; I have no idea why you think I care that something runs on the JVM. I do, however, sell to enterprises. The VM they care about isn't the JVM: it's VMWare ESX. You could write your app in SNOBOL and they won't care as long as they can plug it into their clusters.