But the thing that really irks me is Douglas in the video said very vague assertions, which is fine for click-bait, but the author of this article is make a ton of assumptions of what those “bad foundations” are.
I am not a Douglas Crockford stan.. but a good place to start if you want to see the world from his perspective is his programming language “E”.
Another thing to pick apart, in the video he said “it may be the best language right now to do what it does, but we should do better.” That would imply we’re including all the modern languages in there.
Now for my take:
When we’re talking about application development, raw performance is the last characteristic that is interesting to me.
And the things that are holding us back from writing massive understandable applications isn’t just stronger core data structures and destructors, these are baby steps. We need to go beyond programming based on procedures and data structures.
raw performance is the last characteristic that is interesting to me.
Using a lang like Rust means I never have to encounter a case where the language does not meet requirements due to performance (unless it’s need to drop down to optimize assembly or something and I just don’t think I’ll ever really need that). Even though I don’t “need” the performance most of the time, it is nice knowing that it’s there if a problem comes up. With Ruby if you hit an issue it’s “write a C extension” but then I write Ruby because I don’t want to write C.
The other thing I think about is expressivity. If a language does not have semantics that allow me to express my low level performance requirements to the machine (so it can be optimized), what other kinds of things are hard to express?
We spent decades trying to decouple logic “compute” from memory only to come full circle as it turns out the two are deeply intertwined.
I don’t organize my tech choices by the 1% bottleneck in my system, I guess the difference between us is I don’t mind writing a C/Zig/Rust extension if 99% of my code can stay in ruby. I think we could find new ways to solve the 2-language problem, but I don’t believe its as simple to solve people think. You cannot build rails in rust, and rails is still more boilerplate & restrictive than I’d prefer, the system I want doesn’t exist yet but I know it wouldn’t be able to be written in rust.
I guess what I was trying to express is that the two language problem isn’t about performance but rather expression (for me).
I love that I have the capability to express to my computer “I want exclusive access to this input” (via a mutable reference) or that I can express “this function does not mutate its input” or “this function should not allocate”.
I am a ruby core contributor and maintain syntax suggest. After about a year of writing rust code I ran into an internal mutation bug in syntax suggest (written in Ruby) that cost me a few hours of my life. In Rust it would be impossible (and the default) to prevent that kind of logic bug because the code wouldn’t have even compiled. Yes, that is the same limitation that allows for not needing a GC, but it also has benefits beyond performance.
Im not advocating everyone using it for everything, but I’m saying you cannot avoid thinking about memory (in GC languages). It’s just a question of how much do you have to think about it and when.
Im not advocating everyone using it for everything, but I’m saying you cannot avoid thinking about memory (in GC languages). It’s just a question of how much do you have to think about it and when.
There’s an inescapable tradeoff in languages that are “smart” at some level where most of the time it figures out the optimizations on its own and it’s fine, but every once and a while it’s not quite performing as well as it could, and then you have to understand the underlying system to trick it into actually doing the optimization it needs. In Go, it typically takes the form of the developer knowing that something can be stack allocated and then jumping through some hoops to tell the compiler not to use heap allocation. In Rust, I think a more common gyration is when you know something could be done SIMD but have to make sure the compiler understands that by writing the loops out in a certain way. Databases keep you from having to write manual loops over your data, but you have to tell them the indices ahead of time and even change how you write a query to keep it on the indexed path. Lots of systems end up having this property.
Are we sure that we can’t have both, though? For example, Common Lisp allows incremental typing which acts as hints to the compiler, and the mature compilers will use them to generate very efficient machine code if they can. The v8 VM and Hotspot JIT for the JVM both come from work on heavily optimizing Smalltalk and Self (see Strongtalk).
I do think we can have both, I like the approach I see from Red with Red and Red/System.
I’ve been imagining in my own language a high level DSL to generate C code to interface into, but with analysis done to generate safe C and make it highly interoperable.. maybe a pipe dream, but I do think there’s a lot of unexplored space here.
Using a lang like Rust means I never have to encounter a case where the language does not meet requirements due to performance (unless it’s need to drop down to optimize assembly or something and I just don’t think I’ll ever really need that)
C is faster than rust though, just so everyone knows
I don’t think that’s necessarily the case. Why do you think that C is faster?
It’s a very broad topic with a lot of nuances but let me share a few short points.
On one hand Rust design enables fearless concurrency. Clear ownership makes it easier to write concurrent code and avoid costly synchronization primitives. Stricter aliasing rules give more optimization opportunities (modulo compiler backend bugs).
On the other hand, there are programs which are easy to express in C but writing them in Rust is painful (see Learn Rust With Entirely Too Many Linked Lists). The cost of array bounds checking is probably non-zero as well (although I haven’t seen a good analysis on this topic).
Marketing language like “fearless concurrency” tells us nothing about what Rust design enables or is good for. I’ve never been scared of concurrency, just annoyed by it. What practices or features does Rust afford the programmer that improves their experience writing concurrent code? This is something I haven’t yet heard.
On one hand Rust design enables fearless concurrency. Clear ownership makes it easier to write concurrent code and avoid costly synchronization primitives. Stricter aliasing rules give more optimization opportunities (modulo compiler backend bugs).
You seem to be arguing that rust is faster to write; I was talking about how fast the code runs. I suppose if you write concurrent C code with a similar amount of time and attention as writing the same program in rust, you could end up with slower code because writing C properly can take longer.
You seem to be arguing that rust is faster to write; I was talking about how fast the code runs. I suppose if you write concurrent C code with a similar amount of time and attention as writing the same program in rust, you could end up with slower code because writing C properly can take longer.
I agree with you on this. Thank you for putting it in clearer terms than I could.
For any higher level language than C, and for any problem, you can say that given enough time and enough attention you can write a faster solution in C. And then the same argument goes for assembly. And then the same argument goes for designing specialized hardware.
(It looks like a Turing tarpit of performance in a sense.)
That is very interesting and unexpected; I would retract my unqualified statement that C is faster than Rust if I could still edit the comment. Thanks for sharing.
The cost of array bounds checking is probably non-zero as well
It is a runtime instruction which adds overhead, however if you know the length of your inputs at compile time and can hint them to the compiler and it can prove you never go out of bounds then it will get rid of them.
but writing them in rust is painful
You could say the same the other way too. Having access to a hash map, iterators, growable vectors, and an ever growing list of libraries (crates) you can write code at a high level that has close performance to C without really trying. I did advent of code in Rust in 2021 and while I spent extra time with the borrow checker and memory management my code looked to be a similar abstraction level as if I had written it in Ruby.
We need to go beyond programming based on procedures and data structures.
Yes we do!
And that doesn’t mean we need to stop programming based on procedures and data structures. But data algorithms and data structures are only a small part of what we need to do, and we need ways to express these other things that we do (which I would claim are architectural). Our current “general purpose” programming languages are largely equivalent to ALGOL, the ALGOrithmic Language. They are DSLs for the domain of algorithms.
I think this goes to the heart of what Crockford was intending to communicate. We seem to not lift our eyes beyond the minutiae of language features to new mechanisms of abstraction and representation. It seems we are stuck with functional decomposition and data modeling as all there is and will ever be, with object orientation as just a means to organize code.
We need new ways to model relationships, interactions and constraints. New ways to represent general-specific and whole-part relationships. But more importantly even higher abstractions that let us better model systems into code particularly outside the domains of the computer and data sciences and computing infrastructure.
It’s important to note that Crockford, Mark Miller, and other E veterans deliberately steered ECMAScript to be more like E. From that angle, Crockford is asking for something better than ECMAScript, which is completely in line with the fact that “E” should be more like Joe-E, then E-on-Java, then Caja, then Secure ECMASCript…
When we’re talking about application development, raw performance is the last characteristic that is interesting to me.
There was a recent story about how Mojo takes Python and adds a sub-language for optimization. It seems like a similar approach would be great for JavaScript. WASM is great and all, but it suffers from the two language problem, but worse because of how sandboxed WASM is.
That is a problem with WASM, but the funny thing is that it started exactly like that – asm.js was a subset of JavaScript that the browser JITs could optimize to native performance. And that became WASM, which reduced the parsing burden with a binary code format.
The reason the subset approach works for Mojo is because it’s a language for machine learning. It’s meant for pure, parallel computation on big arrays of floats – not making DOM calls back to the browser, dealing with garbage-collected strings, etc.
The Mojo examples copy arrays back and forth between the embedded CPython interpreter and the Mojo runtime, and that works fine.
WASM also works fine for that use case – it’s linear memory with ints and floats. It would be slower because there’s no GPU access, and I think no SIMD. But you wouldn’t really have the two language problem – the simple interface works fine.
Machine learning is already distributed, and JavaScript <-> WASM (+ workers) is basically a distributed system.
asm.js was a subset of JavaScript that the browser JITs could optimize to native performance. And that became WASM, which reduced the parsing burden with a binary code format.
Wasn’t AssemblyScript the answer to the loss of asm.js? That was my understanding, but maybe I’m wrong.
I don’t understand. asm.js was a strict subset of JavaScript designed to be a compilation target. AssemblyScript is, supposedly, “designed with WASM in mind,” so presumably spiritually successive, given asm.js inspired WASM?
AssemblyScript is not any sort of successor to asm.js. It’s a programming language (not a compilation target) that uses TypeScript syntax and compiles to WebAssembly.
Though “for AI” is everyone’s tagline at the moment. I’m not sure I’d read too much in it. I just saw AWS advertising on my IAM login screen that I should store vectors in RDS Postgres with pgvector because AI.
My understanding is that Mojo is being led by Chris Latner, who after leaving Apple (where he started Swift) went to Tesla to work on self-driving cars and then did more AI stuff at Google. At one point, I think he was working on FFI from Swift to Python just for ML ecosystem. I think the AI part of the description is more than just pure marketing.
It used to be that we’d get new computer languages about every generation. […] And then it kind of stopped. There are still people developing languages, but nobody cares.
Pretty myopic opinion — I can see you might think that if all you pay attention to is web development, but that’s circular reasoning since web dev is based on browsers that only support one language. (I know back-end dev doesn’t require JS, but I think the synergy with client-side code is a big part of what made node.js so popular.)
I don’t think I even need to make any refuting arguments, given that this is lobste.rs and there are dozens of languages posted about, quite a few of which are newish and non-niche.
I wonder if the progress of WASM will start to erode JS’s dominance, especially once the GC features allow better integration between object models.
That seems uncalled for. Graydon’s post is very reasonable and simply goes through the differences between his original idea for Rust and how it eventually turned out. Nowhere does he say he’s disappointed with it or that it’s bad.
“The Rust I Wanted probably had no future, or at least not one anywhere near as good as The Rust We Got. The fact that there was any path that achieved the level of success the language has seen so far is frankly miraculous. Don’t jinx it by imagining I would have done any better!”
Doug Crockford’s early contributions to the JS ecosystem deserve some credit: The Good Parts, JSLint, and JSON were hugely influential. But this YouTube interview (from which the article’s author extrapolates other thoughts of their own) is not new except in what it leaves out this time, which is pretty much anything substantial. He also makes some vague comments about how we should move on from old operating systems, but the headline wouldn’t scream as well if it read, Douglas Crockford: “We should stop using Unix”.
Slightly off topic, but I couldn’t help but notice at this point in the linked YT video that Crockford casually uses the noun “evangel”, which one might describe as “archaic” at best. Lovely word though.
And looking at what he said as a whole, I wasn’t sure whether he was talking about JavaScript specifically, or humanity in general.
After spending a few years with TypeScript, I remain impressed with all it accomplishes especially with structural typing. But its central goal is still to clean up after JavaScript, and it cannot escape the design limitations that imposes. For instance it can’t avoid having both undefined and null. Working in TS I feel somewhat held back by JS. It’s better, but not like I think two decades better ought to be.
England should drive on the right side of the road like everyone else, right?
Except the NPV (net present value) of the switching costs end up being more than the NPV of the payoff. Perhaps the cost of deprecating JavaScript will be higher, for decades, than just supporting it.
In general, WASM means that LLVM targets from your favorite new breed of languages will run in a browser and other infrastructure.
I’m afraid to even begin imagining how costly it is to have two manufacturing lines for left- and right- side cars, to produce lots of spare parts in two options, to refit cars, etc.
The cost to left-side driving (and massive ugly British sockets) is paid constantly, it’s just amortized. I think that avoiding standardization here is a sunk cost fallacy.
As someone emotionally invested in the web, and who learned a lot from and liked Crockford in my early education, who thinks Svelte and TypeScript might be my BFFs, this doesn’t land. But technically maybe, because TypeScript has mainstream supplanted JS in dev polls, so I’m crossing my fingers for something like an optimized subset of TS or some AI-rewrite-it-in-Rust/WASM future or something else that doesn’t challenge my technology choices, which are working great for UX and DX.
the only way this happens is amazing wasm,platform support and 1 or 2 killer apps. the web is the killer app for js/ts, iOS for swift, kotlin for Android, C# for Windows, performance tasks for C++. we need a reason to use them and break from the familiarity and amazing amount of resources js provided through online questions and answers, tutorials and ease. it’s just hard.
I prefer the video that is the article’s subject to the article itself. Many of our stacks are tall and wobbly when they could be short and stable and long-lasting. Although our field has done some serious work to produce alternatives, the entrenched old things still dominate. I know I’m just as vague as the video. Suffice to say it resonated with me.
So.. there’s a lot to unpack here.
But the thing that really irks me is Douglas in the video said very vague assertions, which is fine for click-bait, but the author of this article is make a ton of assumptions of what those “bad foundations” are.
I am not a Douglas Crockford stan.. but a good place to start if you want to see the world from his perspective is his programming language “E”.
Another thing to pick apart, in the video he said “it may be the best language right now to do what it does, but we should do better.” That would imply we’re including all the modern languages in there.
Now for my take:
When we’re talking about application development, raw performance is the last characteristic that is interesting to me.
And the things that are holding us back from writing massive understandable applications isn’t just stronger core data structures and destructors, these are baby steps. We need to go beyond programming based on procedures and data structures.
Using a lang like Rust means I never have to encounter a case where the language does not meet requirements due to performance (unless it’s need to drop down to optimize assembly or something and I just don’t think I’ll ever really need that). Even though I don’t “need” the performance most of the time, it is nice knowing that it’s there if a problem comes up. With Ruby if you hit an issue it’s “write a C extension” but then I write Ruby because I don’t want to write C.
The other thing I think about is expressivity. If a language does not have semantics that allow me to express my low level performance requirements to the machine (so it can be optimized), what other kinds of things are hard to express?
We spent decades trying to decouple logic “compute” from memory only to come full circle as it turns out the two are deeply intertwined.
I don’t organize my tech choices by the 1% bottleneck in my system, I guess the difference between us is I don’t mind writing a C/Zig/Rust extension if 99% of my code can stay in ruby. I think we could find new ways to solve the 2-language problem, but I don’t believe its as simple to solve people think. You cannot build rails in rust, and rails is still more boilerplate & restrictive than I’d prefer, the system I want doesn’t exist yet but I know it wouldn’t be able to be written in rust.
I guess what I was trying to express is that the two language problem isn’t about performance but rather expression (for me).
I love that I have the capability to express to my computer “I want exclusive access to this input” (via a mutable reference) or that I can express “this function does not mutate its input” or “this function should not allocate”.
I am a ruby core contributor and maintain syntax suggest. After about a year of writing rust code I ran into an internal mutation bug in syntax suggest (written in Ruby) that cost me a few hours of my life. In Rust it would be impossible (and the default) to prevent that kind of logic bug because the code wouldn’t have even compiled. Yes, that is the same limitation that allows for not needing a GC, but it also has benefits beyond performance.
Im not advocating everyone using it for everything, but I’m saying you cannot avoid thinking about memory (in GC languages). It’s just a question of how much do you have to think about it and when.
That’s a good point, thanks for clarifying.
There’s an inescapable tradeoff in languages that are “smart” at some level where most of the time it figures out the optimizations on its own and it’s fine, but every once and a while it’s not quite performing as well as it could, and then you have to understand the underlying system to trick it into actually doing the optimization it needs. In Go, it typically takes the form of the developer knowing that something can be stack allocated and then jumping through some hoops to tell the compiler not to use heap allocation. In Rust, I think a more common gyration is when you know something could be done SIMD but have to make sure the compiler understands that by writing the loops out in a certain way. Databases keep you from having to write manual loops over your data, but you have to tell them the indices ahead of time and even change how you write a query to keep it on the indexed path. Lots of systems end up having this property.
Are we sure that we can’t have both, though? For example, Common Lisp allows incremental typing which acts as hints to the compiler, and the mature compilers will use them to generate very efficient machine code if they can. The v8 VM and Hotspot JIT for the JVM both come from work on heavily optimizing Smalltalk and Self (see Strongtalk).
I do think we can have both, I like the approach I see from Red with Red and Red/System.
I’ve been imagining in my own language a high level DSL to generate C code to interface into, but with analysis done to generate safe C and make it highly interoperable.. maybe a pipe dream, but I do think there’s a lot of unexplored space here.
C is faster than rust though, just so everyone knows
Asm is faster than C though, just so everyone knows
certainly, but nobody is mistaken about that
I don’t think that’s necessarily the case. Why do you think that C is faster?
It’s a very broad topic with a lot of nuances but let me share a few short points.
On one hand Rust design enables fearless concurrency. Clear ownership makes it easier to write concurrent code and avoid costly synchronization primitives. Stricter aliasing rules give more optimization opportunities (modulo compiler backend bugs).
On the other hand, there are programs which are easy to express in C but writing them in Rust is painful (see Learn Rust With Entirely Too Many Linked Lists). The cost of array bounds checking is probably non-zero as well (although I haven’t seen a good analysis on this topic).
Marketing language like “fearless concurrency” tells us nothing about what Rust design enables or is good for. I’ve never been scared of concurrency, just annoyed by it. What practices or features does Rust afford the programmer that improves their experience writing concurrent code? This is something I haven’t yet heard.This Rust book explains it in meaningful terms: https://doc.rust-lang.org/book/ch16-00-concurrency.html
I don’t know the methodology here but I had this graph in mind: https://benchmarksgame-team.pages.debian.net/benchmarksgame/download/fastest.svg
You seem to be arguing that rust is faster to write; I was talking about how fast the code runs. I suppose if you write concurrent C code with a similar amount of time and attention as writing the same program in rust, you could end up with slower code because writing C properly can take longer.
All right, I see what you mean. That said, if we look at https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html, then we see that the fastest solution is in Rust 50% of the time.
I agree with you on this. Thank you for putting it in clearer terms than I could.
For any higher level language than C, and for any problem, you can say that given enough time and enough attention you can write a faster solution in C. And then the same argument goes for assembly. And then the same argument goes for designing specialized hardware.
(It looks like a Turing tarpit of performance in a sense.)
That is very interesting and unexpected; I would retract my unqualified statement that C is faster than Rust if I could still edit the comment. Thanks for sharing.
Will this do? https://lobste.rs/s/yibs3k/how_avoid_bounds_checks_rust_without
It is a runtime instruction which adds overhead, however if you know the length of your inputs at compile time and can hint them to the compiler and it can prove you never go out of bounds then it will get rid of them.
You could say the same the other way too. Having access to a hash map, iterators, growable vectors, and an ever growing list of libraries (crates) you can write code at a high level that has close performance to C without really trying. I did advent of code in Rust in 2021 and while I spent extra time with the borrow checker and memory management my code looked to be a similar abstraction level as if I had written it in Ruby.
Yes we do!
And that doesn’t mean we need to stop programming based on procedures and data structures. But data algorithms and data structures are only a small part of what we need to do, and we need ways to express these other things that we do (which I would claim are architectural). Our current “general purpose” programming languages are largely equivalent to ALGOL, the ALGOrithmic Language. They are DSLs for the domain of algorithms.
See also:
Why Architecture Oriented Programming Matters
Can Programmers Escape the Gentle Tyranny of call/return?
Glue: the Dark Matter of Software
And of course my current attempt at a fix:
Objective-S
Thank you for sharing these links, they are very insightful!
I think this goes to the heart of what Crockford was intending to communicate. We seem to not lift our eyes beyond the minutiae of language features to new mechanisms of abstraction and representation. It seems we are stuck with functional decomposition and data modeling as all there is and will ever be, with object orientation as just a means to organize code.
We need new ways to model relationships, interactions and constraints. New ways to represent general-specific and whole-part relationships. But more importantly even higher abstractions that let us better model systems into code particularly outside the domains of the computer and data sciences and computing infrastructure.
As far as I’m aware, Pony and Monte both follow in the tradition of E in one way or another.
It’s important to note that Crockford, Mark Miller, and other E veterans deliberately steered ECMAScript to be more like E. From that angle, Crockford is asking for something better than ECMAScript, which is completely in line with the fact that “E” should be more like Joe-E, then E-on-Java, then Caja, then Secure ECMASCript…
There was a recent story about how Mojo takes Python and adds a sub-language for optimization. It seems like a similar approach would be great for JavaScript. WASM is great and all, but it suffers from the two language problem, but worse because of how sandboxed WASM is.
That is a problem with WASM, but the funny thing is that it started exactly like that – asm.js was a subset of JavaScript that the browser JITs could optimize to native performance. And that became WASM, which reduced the parsing burden with a binary code format.
The reason the subset approach works for Mojo is because it’s a language for machine learning. It’s meant for pure, parallel computation on big arrays of floats – not making DOM calls back to the browser, dealing with garbage-collected strings, etc.
The Mojo examples copy arrays back and forth between the embedded CPython interpreter and the Mojo runtime, and that works fine.
WASM also works fine for that use case – it’s linear memory with ints and floats. It would be slower because there’s no GPU access, and I think no SIMD. But you wouldn’t really have the two language problem – the simple interface works fine.
Machine learning is already distributed, and JavaScript <-> WASM (+ workers) is basically a distributed system.
Wasn’t AssemblyScript the answer to the loss of asm.js? That was my understanding, but maybe I’m wrong.
I don’t think AssemblyScript could fill that niche since it is both not a superset of JavaScript and compiles entirely to WASM.
I don’t understand. asm.js was a strict subset of JavaScript designed to be a compilation target. AssemblyScript is, supposedly, “designed with WASM in mind,” so presumably spiritually successive, given asm.js inspired WASM?
AssemblyScript is not any sort of successor to asm.js. It’s a programming language (not a compilation target) that uses TypeScript syntax and compiles to WebAssembly.
Mojo doesn’t appear aimed at application development, their headline is “a new programming language for all AI developers.”
Though “for AI” is everyone’s tagline at the moment. I’m not sure I’d read too much in it. I just saw AWS advertising on my IAM login screen that I should store vectors in RDS Postgres with pgvector because AI.
My understanding is that Mojo is being led by Chris Latner, who after leaving Apple (where he started Swift) went to Tesla to work on self-driving cars and then did more AI stuff at Google. At one point, I think he was working on FFI from Swift to Python just for ML ecosystem. I think the AI part of the description is more than just pure marketing.
[Comment removed by author]
Urks?
Language confuses me, I spell phonetically - I believe I was looking for “irk”, updated
Pretty myopic opinion — I can see you might think that if all you pay attention to is web development, but that’s circular reasoning since web dev is based on browsers that only support one language. (I know back-end dev doesn’t require JS, but I think the synergy with client-side code is a big part of what made node.js so popular.)
I don’t think I even need to make any refuting arguments, given that this is lobste.rs and there are dozens of languages posted about, quite a few of which are newish and non-niche.
I wonder if the progress of WASM will start to erode JS’s dominance, especially once the GC features allow better integration between object models.
Once WebAssembly doesn’t require JavaScript to work, I’m going to stop using JavaScript as soon as possible.
GC and hopefully stringrefs, too, otherwise interop will be a pain if every lang has to have their own string implementation. Fingers crossed.
Wrap it up folks, it’s time to stop using Javascript because It’s Bad and Crockford is Bored With It
just the fact that it’s bad should be enough shouldn’t it?
Same with Rust: It’s Bad and Graydon is Disappointed With It
That seems uncalled for. Graydon’s post is very reasonable and simply goes through the differences between his original idea for Rust and how it eventually turned out. Nowhere does he say he’s disappointed with it or that it’s bad.
In fact it closes with:
“The Rust I Wanted probably had no future, or at least not one anywhere near as good as The Rust We Got. The fact that there was any path that achieved the level of success the language has seen so far is frankly miraculous. Don’t jinx it by imagining I would have done any better!”
It was sarcastic.
Doug Crockford’s early contributions to the JS ecosystem deserve some credit: The Good Parts, JSLint, and JSON were hugely influential. But this YouTube interview (from which the article’s author extrapolates other thoughts of their own) is not new except in what it leaves out this time, which is pretty much anything substantial. He also makes some vague comments about how we should move on from old operating systems, but the headline wouldn’t scream as well if it read, Douglas Crockford: “We should stop using Unix”.
Slightly off topic, but I couldn’t help but notice at this point in the linked YT video that Crockford casually uses the noun “evangel”, which one might describe as “archaic” at best. Lovely word though.
And looking at what he said as a whole, I wasn’t sure whether he was talking about JavaScript specifically, or humanity in general.
Arguments are weak. We use TS now.
After spending a few years with TypeScript, I remain impressed with all it accomplishes especially with structural typing. But its central goal is still to clean up after JavaScript, and it cannot escape the design limitations that imposes. For instance it can’t avoid having both undefined and null. Working in TS I feel somewhat held back by JS. It’s better, but not like I think two decades better ought to be.
anyone know if there’s a full version of the interview or only these short clips cut like tiktok videos?
I found this talk of his in which he outlines his ideas for a future language (heavily Actor model oriented): https://www.youtube.com/watch?v=R2idkNdKqpQ
England should drive on the right side of the road like everyone else, right?
Except the NPV (net present value) of the switching costs end up being more than the NPV of the payoff. Perhaps the cost of deprecating JavaScript will be higher, for decades, than just supporting it.
In general, WASM means that LLVM targets from your favorite new breed of languages will run in a browser and other infrastructure.
I’m afraid to even begin imagining how costly it is to have two manufacturing lines for left- and right- side cars, to produce lots of spare parts in two options, to refit cars, etc.
The cost to left-side driving (and massive ugly British sockets) is paid constantly, it’s just amortized. I think that avoiding standardization here is a sunk cost fallacy.
As someone emotionally invested in the web, and who learned a lot from and liked Crockford in my early education, who thinks Svelte and TypeScript might be my BFFs, this doesn’t land. But technically maybe, because TypeScript has mainstream supplanted JS in dev polls, so I’m crossing my fingers for something like an optimized subset of TS or some AI-rewrite-it-in-Rust/WASM future or something else that doesn’t challenge my technology choices, which are working great for UX and DX.
Surprised to see no mention of Misty, the new language I thought he was working on.
the only way this happens is amazing wasm,platform support and 1 or 2 killer apps. the web is the killer app for js/ts, iOS for swift, kotlin for Android, C# for Windows, performance tasks for C++. we need a reason to use them and break from the familiarity and amazing amount of resources js provided through online questions and answers, tutorials and ease. it’s just hard.
I prefer the video that is the article’s subject to the article itself. Many of our stacks are tall and wobbly when they could be short and stable and long-lasting. Although our field has done some serious work to produce alternatives, the entrenched old things still dominate. I know I’m just as vague as the video. Suffice to say it resonated with me.