One thing that always really bugged me about the "the language will figure it out" philosophy is the complete disregard towards carbon footprint.

Like yeah, you can make an interpreted dynamic language that's pretty neat, but you can also make something like go, swift, or Julia that jits and also captures 90% of that ease of use while significantly reducing your hosting costs/energy consumption.

Going forward I think static compiler inference will be the future of language design. Either for safety like in rust or for convenience like in swift.

And we can already see pitfalls in the interpreted world of python where the wrong implementation, like using a loop instead of numpy, can lead to devastating performance impacts. Looking forward, something like this seems as outdated as having to manage your 640k of executable space in DOS: an unreasonable design constraint caused by the legacy implications of the day.

My prediction is 10 years from now we'll look at interpreters and language VMs as relics from a simpler time when clockrates were always increasing and energy was cheap.

I'm actually pretty amazed at what the Javascript VM people have done in the past decade. It's way more than I ever expected.

As far as the carbon footprint, well, yeah, it depends. At Google I remember a friend talking about how he cringed whenever he added more code to the pipeline that ingests the entire internet. He said that he wondered how much extra carbon was release into the atmosphere just because of his stupid code.

As for numpy, we are seeing that loops are stupid and Iverson and APL were right. :-)

> At Google I remember a friend talking about how he cringed whenever he added more code to the pipeline that ingests the entire internet. He said that he wondered how much extra carbon was release into the atmosphere just because of his stupid code.

I wish companies were under more financial pressure to actually track and mitigate this. (hint hint, carbon taxes)

If you run your data centers where electricity is cheap, you're using electricity but not emitting very much carbon dioxide.

>My prediction is 10 years from now we'll look at interpreters and language VMs as relics from a simpler time when clockrates were always increasing and energy was cheap.

Funnily enough someone said that exact same thing 10 years ago in that thread:

>* Functional programming / dynamic languages will go out of fashion. People still using them will be judged as incompetent programmers by the people who moved on to the new fashionable programming paradigm(s). At the same time, huge corporations will embrace functional programming / dynamic languages and third world universities will start focusing on them in their courses.

Wrong then wrong now.

> Wrong then wrong now.

While pithy, that's not actually an interesting rebuttal.

You should elaborate, especially since "huge corporations", namely Apple, Google, and Mozilla (I guess?), are the ones pushing Swift, Go, and Rust, respectively.

Huge corporations always push for languages which are brain dead and make developers be as fungible as possible. Unfortunately not all software has been invented yet and writing in such a language is a nightmare.

So what happens is that people gravitate towards languages which are pleasant enough to work on to try new ideas in.

The progressing of bash -> awk -> perl -> python happened for a reason. Hell we're even seeing people use lisp like languages unironically for the first time in decades.

Enabling developers of different talents and backgrounds to be productive and contribute successfully, and to scale up in number of separate teams, is a hard problem and doesn't deserve the kind of dismissiveness you give it here.

More powerful languages enable talented developers to be more productive individually, but it's hard to teach all the other developers about the new and interesting abstractions that the powerful languages enable, and it's impossible to hire for them directly. This limits velocity.

And it's not just huge corporations, it's any company which is trying to scale from 10 to 100 developers; where you're hiring continuously, where there are too many other developers to efficiently rely on ambient learning.

Maybe the progression is actually bash -> awk -> perl -> python -> raku ? One can wish :-)

Not so sure our energy problems are going to come to a head in the form of all-out energy poverty. More likely I think: the convenience of energy being instantly available at all the right times and places will diminish.

Cloud spot pricing is I think one example where things that can be batched and deferred will be cheap even in a energy-decline future.

This is assuming we don’t sink so far as to lose our productive capacity for energy infrastructure altogether. Depends how bull/bear you are about the whole thing I suppose. In that scenario, there’s also gonna be no market to sell whatever you’re coding to.

I think the new languages are about developer productivity, but in a different way. It allows you to make more robust software via a better typing system, or more robust multithreading via rust's borrow system. In the past, our machines couldn't handle such strict languages as well because they have a high compile time cost.

In overall total effort needed to make something robust, something like rust will beat something like ruby, because the dynamic language-ists compensate via a larger test suite.

Most setups and most hardware isn’t efficient enough for language to really matter. So the solution to carbon footprint isn’t to stop using python, it’s to stop burning coal.

The sad thing about Python is that it shouldn't need to be interpreted. People don't use it for that reason. Remove one or two obscure meta-programming features that nobody uses (or shouldn't be using) and you could in principle remove GIL and make it JIT just as good as Javascript.

JS really shows what's possible in this field with some benchmarks even outperforming c++. This space of expressive yet fast languages is a gap that remains to be filled and will probably be by 2030, sadly it's a bit of a chicken-and-egg situation because you don't only need a good syntax to become popular, also a healthy ecosystem around it. What we will see is probably not any new language but rather that existing languages from both sides of the spectrum converge more towards the middle ground.

Energy is gonna keep on getting cheaper.

I mean, JavaScript and Python have definitely become much more popular for many more things than they were in 2010.

I doubt Swift replaced much besides other compiled languages, and Kotlin just compiles to Java anyway. Dart's VM idea was dropped so its small usage is largely compiling to JS still.

I would say that the overall idea of performance being traded for programmer time is definitely happening despite the emergence of Rust.

> Dart's VM idea was dropped so its small usage is largely compiling to JS still.

Are you sure about this? I was under the impression that today's Flutter development is highly dependent on the niceties the Dart VM provides, and newer Dart releases improved upon them.

In terms of language design, it seems like swift and julia are the most forward looking.

I personally don't think swift will ever escape the Mac ecosystem, just like Objective-C never did, but something with the same DNA will.

In the same way that Objective-C and Ruby both implement the philosophy of Smalltalk, I think that philosophy has yet to be fleshed out in a simple syntax that is natively jit'ed/compiled.

The same goes for julia as an answer to R/pandas.

Those are both typically faster than Ruby, tho. Ruby (especially pre-1.9) probably does represent the mainstream peak for tolerance of slowness.

> I would say that the overall idea of performance being traded for programmer time is definitely happening despite the emergence of Rust.

In some sense Rust is in that same vain - reducing certain errors and the need for tools like Coverity, which in turn makes programmers more efficient.

JS and Python are not to Ruby what Ruby is to Java, though.

In my opinion, Electron is the fulfillment of that prediction.

JavaScript is quite a bit faster than Ruby in most cases.

Electron isn’t just JavaScript, else I would have said JavaScript. Electron is front and center in the movement to shorten development time by consuming more PC resources at runtime. I feel that’s the spirit of the prediction.

I think Electron's advantage is to shorten training time, not development time.

I don't agree. I've implemented GUIs with raw Xlib, Tcl/Tk, Qt, GTK, MFC, SDL, XUL, and DHTML. Of all of these, DHTML is the most productive for me, and by a significant margin. The Tcl/Tk topic in Dercuano goes into those experiences in more detail, if you're interested.

Training for what or for who?

Training for developers, presumably, especially web developers who want to build native apps. If retraining was free, Electron would have approximately no market.

Who? Whom do you think I'm talking about?

Well I as an innocent bystander have no idea what you mean either, unfortunately.

I'm also an innocent bystander!

ryacko is perfectly clearly stating that Electron reduces the amount of training that developers need. This is different from making them develop faster. It just makes them more replaceable.

I have no idea how to parse twobat's question. The "or" is especially confusing. I'm not surprised that ryacko is baffled by it.

Training is an abstract term these days. Could've meant training an algorithm, or training a person, depending on context.

Hence the training for "what" or for "who" not being immediately parseable.

Until @ryacko said "Whom do you think I'm talking about?", I wasn't sure either.

Electron gives you a UI and some standard library stuff. That's pretty obviously a totally separate issue from training an algorithm... I think? Am I missing something?

I still think asking "what or who?" with no other elaboration is really confusing. It's such a vague question that you have to guess how to answer, and it's super easy to answer it in a way that doesn't satisfy what the asker actually meant to ask.

Because it's not Moore's Law that matters here, but rather the subset that is the performance of single cores. And that subset stalled out pretty badly.

We're adding more and more cores, but more cores don't help you write a program in easy mode. Easy mode doesn't multithread.

It's also been quite a decade of growth for old stodgy languages. In 2010, it seemed like C++, Java, and Javascript were never going to change, but they've all significantly cleaned up their acts.

I think the prediction still had a kernel of truth to it though - every edge that chip manufacturers and JIT developers can give us has been burned away on slower and slower client-side rendering frameworks.

And PHP. PVP 5.3 was the newest version in 2010 and as the years wore on many thought HipHop by Facebook would start to take over for serious PHP applications. PHP 7 completely changed the course of the PHP community and took the air out of HHVM’s sails.

Did PHP 7 introduce optimizations similar to HipHop?

I was always curious what happened to HipHop. Didn’t it become a part of Facebook’s custom flavor of PHP? (Forgot it’s name)

HipHop was a cross-compiler which facebook abandoned for HHVM, a rewrite of the PHP engine with faster internals. It always had compatibility issues, but the improved performance made it interesting (afaik nobody outside facebook really got that much into Hack the language). PHP7 was a rewrite of the internal data structures which put it on close enough performance footing. Because HHVM was never a drop-in replacement for PHP and moved further away over time the community ended up sticking with PHP7 and now pretty much only facebook uses HHVM, with the big players that moved to HHVM all transitioning back to PHP7.

Hack, right? I'm curious as well.

Rust and Dart hasn’t seen that much “uptake” by the broader market, it’s hyped by geeks but that’s about it. Swift is becoming popular because if you want to develop for iOS, you don’t have a choice. Kotlin is getting some uptake.

Rust has seen lots of quiet uptake. What you don't see is hiring for people for Rust because most organizations don't experience a whole-sale shift to Rust, and you just retrain people on the inside.

I'd wager there are lots of people like me - writing small tools at work in Rust, but the employer would never hire for Rust.

I think we'll see broader market adoption in the next 2-5yrs though, in terms of people actually hiring Rust developers. There's still a little maturing to do in a couple areas to clean up some papercuts.

Disclaimer: I really like Rust am a little biased.

Any citations?

So, for the uptake, you can see a large list of companies here: https://www.rust-lang.org/production/users

The not hiring but using bit is based on not seeing Rust jobs despite companies actively using Rust, and many anecdotes of "I wasn't hired for rust, but we use it" over in reddit on r/rust when people ask how to get a rust job.

I was thinking that exact same thing. Rails was hitting its peak in 2010, and the idea that programmer time is more valuable than CPU time suggested dynamic languages were the future.

I mean, that’s not entirely wrong — Besides JS, Python is arguably the most dominant language across all domains. Python is also faster than Ruby, though, and 3.x added static-like features to the language. It doesn’t seem like there’s much appetite for languages any slower than what we have now.

I don’t think one can say that python is faster than ruby: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I think the perception is there because of python’s scientific and ML libraries that have a lot of c bindings, perhaps?

Both are drastically faster than they were a decade ago, so 2010-era python or ruby are still the high-water mark.

afaict until the 25 Dec 2019 ruby 2.7.0 release you probably could "say that python is faster than ruby".

fwiw

    ruby 2.6.3p62
    ruby 2.7.0p0

    binarytrees-5 220.557 elapsed secs
    binarytrees-5 124.421

    binarytrees-2 178.751 
    binarytrees-2 149.458

    binarytrees-3 176.672
    binarytrees-3 150.645

    binarytrees-4 136.930 
    binarytrees-4 113.516 

    binarytrees-1 176.208 
    binarytrees-1 149.078 

    fannkuchredux-1 1702.734 
    fannkuchredux-1 1738.016

    fannkuchredux-2 2129.404 
    fannkuchredux-2 1153.396 

    fasta-3 132.449 
    fasta-3 81.565 

    fasta-6 105.649 
    fasta-6 54.305 

    fasta-2 236.321 
    fasta-2 180.647 

    fasta-5 181.954 
    fasta-5 146.962 

    fasta-4 178.753 
    fasta-4 144.130 

    knucleotide-7 702.380 
    knucleotide-7 361.174 

    knucleotide-2 412.034 
    knucleotide-2 365.819 

    knucleotide-1 678.888 
    knucleotide-1 378.368 

    knucleotide-3 426.748 
    knucleotide-3 385.934 

    mandelbrot-4 886.246
    mandelbrot-4 1202.783 

    mandelbrot-2 1770.692
    mandelbrot-2 1329.560

    mandelbrot-3 1689.111
    mandelbrot-3 2090.329

    mandelbrot-5 1789.859
    mandelbrot-5 2119.157

    nbody-2 423.428
    nbody-2 376.758

    pidigits-1 60.476
    pidigits-1 30.232

    pidigits-5 6.446
    pidigits-5, 4.790

    pidigits-2 18.670
    pidigits-2 11.841

    regexredux-3 17.774
    regexredux-3 9.431

    regexredux-9 71.050
    regexredux-9 40.018

    regexredux-2 55.729
    regexredux-2 33.070

    revcomp-2 66.741
    revcomp-2 32.203

    revcomp-5 44.957
    revcomp-5 21.445

    revcomp-3 89.536
    revcomp-3 39.507

    revcomp-4 107.196
    revcomp-4 43.994

    spectralnorm-5 1059.201
    spectralnorm-5 587.204

    spectralnorm-1 318.088
    spectralnorm-1 291.167

    spectralnorm-4 271.367
    spectralnorm-4 209.650

Ruby pulled ahead of Python in speed in version 1.9 and has stayed ahead (most of the time, in most tests) since.

> most of the time, in most tests

That isn't something which can be checked, just stuff someone said.

I wasn't trying to assert that ruby is faster, just trying to correct the notion that python is an inherently faster language than ruby.

If I look at a composite benchmark like debian's and don't see one leading by an order of magnitude, I file that away as "probably about the same speed, depends on your use case"

> Swift, Rust, Kotlin, and Dart

and golang (Go)