7 ms·

I think with the slowing progress of single threaded performance modern languages require three essential features if they want to be "main branches" of the lan

• tachyonbeam 7y ago
  Why managed memory? The consensus seems to be that this gets in the way of predictable performance. GC is also non-trivial to parallelize.
  • kris-s 7y ago
    Developer convenience. If the language gives you an out to manage it yourself for performance: that's cool too. I agree with the claim in the essay that there will always be a need for full throttle performance, which rules out a GC or ARC.
  • wbl 7y ago
    Where is this consensus stated? The JVM seems to do quite well.
    • tachyonbeam 7y ago
      People typically don't use Java for performance-sensitive real-time-ish applications. Most modern games are written in C++ still. Operating system kernels are written in C. When I think Java, what comes to my mind is something like LibreOffice.
      • kerng 7y ago
        I think real-time does not mean what you think it means. It doesn't have to do with speed per se.
      • ahartmetz 7y ago
        The runtime of all webthings in written in C++ (and Rust, which is kind of its spiritual successor).
        • wbl 7y ago
          Did you forget Tomcat?
      • coldtea 7y ago
        >People typically don't use Java for performance-sensitive real-time-ish applications. Most modern games are written in C++ still. Operating system kernels are written in C. Those are 1/100th or less of the type of code people write everyday, in startups, enterprise, cloud apps, even regular desktop and mobile apps... >When I think Java, what comes to my mind is something like LibreOffice. That's written in C++
        • abc_lisper 7y ago
          Ouch! Rich Hickey, inventor of clojure came to same conclusion using lisps. He rewrote a system in lisp that was written in c++ before by him. He claimed that system written in lisp had far less concurrency issues, and was faster! He was a c++ advocate before that.
        • overgard 7y ago
          C & C++ are #2 and #4 on the Tiobe index fwiw. It’s not like real-time is a niche.
          • coldtea 7y ago
            Real time is indeed a niche (though a big one), but also it's hardly the reason C and C++ are #2 and #4 on Tiobe.
            • overgard 7y ago
              Video games are like a 43 billion dollar industry, and that's just a small slice of software that has real time requirements. Real time is very much a mainstream need. Hacker news just tends to be a bit of a bubble because people focus so much on web development and business logic here.
              • coldtea 7y ago
                >Video games are like a 43 billion dollar industry, and that's just a small slice of software that has real time requirements. But still a tiny slither on what most programmers do. Most programmers (the overwhelming majority) do neither video games nor real time.
      • zmmmmm 7y ago
        You put "real time" in there but that's an extreme edge case. Modern GC in the JVM is now able to guarantee around 10 millisecond maximum pauses. > When I think Java, what comes to my mind is something like LibreOffice. You should probably revise that thinking, since it is not written (at least in substantial ways) in Java. Moreover, desktop applications are probably not really the main use case for it (or any language other than web technologies) these days. Java running on server processes or any long-lived computation sits in the top tier of performance. Not as fast as C/C++ but in the same ball-park.
        • overgard 7y ago
          10 ms is huge for a lot of things. Games, music software, video software, 10ms is a very visible hitch.
          • jzoch 7y ago
            Note, new gc's in the most recent JDK's guarantee 10ms pauses on multi-terabyte heaps. For most cases it is far far far far far far less.
          • nostrademons 7y ago
            Even for webapps. V8's garbage collector was a huge problem when trying to get smooth animations on mobile phones.
      • p_l 7y ago
        "real time" has nothing to do with raw speed, and even with C/C++ requires custom allocators to get around normal memory code being unpredictable. Real time requires predictability, something that was solved in GCs by mid-1990s and had workarounds (which are required in C/C++ as well, and widely used by games etc.) by 1980s - when real-time GC'ed programs started to be used. Including hard-realtime in telephone switches.
        • phkahler 7y ago
          On smaller real time systems, we simply dont do dynamic memory allocation at all. Everything is global/static, or on the stack. Malloc can never fail if it's not called.
  • chrisseaton 7y ago
    One advantage of managed memory is that it can be moved, which makes allocation extremely fast.
    • tachyonbeam 7y ago
      I'm playing the devil's advocate a bit. I come from a compiler background. If your language has strong memory guarantees, a good compiler might even be able to eliminate temporary allocations completely in some cases, which is pretty neat (ie: make you think you're heap allocating something, when in reality it's on the stack, or in registers).
      • chrisseaton 7y ago
        But that also requires managed memory. If your model is to call an opaque function `malloc` then the compiler can't reason about it to scalar replace it.
• dstroot 7y ago
  Enter Golang...
  • kris-s 7y ago
    Yes, I'd put a wager that Go will have a long lifespan. I think there will eventually be a few copycat Go-style languages with some bits and bobs from other languages (immutability, exceptions, etc) but the bones will be the same.
• AlchemistCamp 7y ago
  It's exactly these, with the emphasis on easy, that pushed me towards Elixir three years ago. The dev ergonomics are nearly as nice as Ruby's, it's got a great MVC framework and you also get points 1 and 2. That said, I'm also seeing Rust really start to boom and it trades managed memory for very powerful tools for managing it manually.
• varelse 7y ago
  Going out on a ledge, 100 years is a really long time technologically speaking... As such, I don't think we'll literally program computers in 100 years so much as think about problems whilst connected to some sort of cybernetic system. The now obsolete act of programming itself will be abstracted away in the same way a language like Python abstracts way assembler, cache, and memory management today. 50 years ago code was still being submitted with punch cards. In 1971, my father got a 110 baud model 33-ASR teletype that drastically simplified coding and provided paper tape for offline storage. Compare and contrast with today. In such a system your wetware and the hardware will collaborate in the same way that groups of people brainstorm ideas, resulting in code that just seems to write itself driven by one's thoughts. What AI will have become by then will be more then capable of running such a program through bajillions of chaos monkey simulated scenarios instead of a hand-crafted set of unit tests. As to what that language actually is, just what kris-s said: easy parallelism, easy networking, and easy access to storage in a way that the HW itself does all the management implicitly and emergently. But I doubt humans will write this code, I think the compiler guys will finally win this by building something like the above, where hand-coding such a widget would be insanely tedious for mostly meager performance gains (unless you're an infinitely patient machine that can go arbitrarily parallel). The current DL ASIC war combined with the framework compiler arms race just beginning now ought to give us an early preview of what's to come.
  • overgard 7y ago
    Lisp is like 50 years old and it’s only really been this last decade that a lot of its features have made it into the mainstream. Plus I doubt thought is really precise enough. Most people need to write their thoughts down or speak them out loud to really clarify their own thinking.
  • rabidrat 7y ago
    > In 1971, my father got a 110 baud model 33-ASR teletype We still use UNIX/C (1970) and the command-line is still very much a teletype.