I think I disagree that you can have a Rust program that doesn't use all these concepts, at least outside of very basic tutorial material. You will very very quickly run into compiler errors that mention them the second you write your own program.
> The author conveniently left out all of the things needed to understand that JavaScript version, including async/await, promises, modules, string interpolation, [...] not to mention the runtime that is running this, etc.
no. the JS program has obvious syntax bugs that TS wouldn't compile. commentors above are right that I was just lazy (ty for the callout, I have since fixed the JS program).
tech salaries in the US are high enough that this is approximately 1-3 years of income as a lump sum. more than that, if you got this amount as a bonus you already have stupid money.
of course $140k would be life changing for most people. but OP, and i suspect most of the other commenters, are not in that situation.
oh hey Will! long time no see lol, it's been ages. small world.
i think this is on a good track! i like that it's designed to be extensible while still keeping some amount of structure, and that the DSL makes things very compact. how are those filters implemented? are you spawning a shell to run jq or are you interpreting in-process or something like that?
in general i'd love to see a bunch more DSLs, i think using general-purpose languages for everything is most of the time not actually helpful (cc https://jyn.dev/constrained-languages-are-easier-to-optimize...). i have some vague thoughts about how to make interop between DSLs and the host language easier but i need to think about them some more.
have you seen https://pharo.org/ by chance? it's a smalltalk IDE built in smalltalk, which means that the whole thing is editable at runtime. it's hard to describe before you see it, https://pharo.org/features has some demos.
I tried pharo, its an interesting thing but I don't see it as a particularly practical solution.
Yes its editable in runtime, but not the whole thing and not reliably so: I remember changing some low level array methods that broke the whole image.
Even in pharo your data has to be organised in some way and if you add new code to existing image you have to know how to reach the data you need.
And the biggest downside to productivity and stability is it doesn't have a type system and every action can fail because the receiver doesn't support a particular message.
originally i had them both in one article but it was getting to be really quite long and i am still thinking through what i want to say in the follow-up
A bit off-topic, but in a shell pipeline like that, if you put your pipe chars at the end of the line you don't need backslashes and you can comment out bits of the pipe for devving.
This little change was mind-blowing for me so I always try to share when I can :)
when’s the last time you wrote a parallel array traversal in C?
also, consider reading the linked post about how assembly instructions are no longer a good approximation of how your computer works: https://queue.acm.org/detail.cfm?id=3212479. in general, writing in a language that is not close to the hardware allows the compiler to adapt when the hardware changes; for example futhark has the ability to execute using either SIMD or GPUs precisely because it’s not over-determined by the source language. C ties processors to the model of the PDP-11, which hasn’t been manufactured for 30 years.
It's not especially difficult to write a parallel array sum in CUDA, which is C++ with a couple of keywords bolted on. Haven't done that in a bit, but I wrote a SIMD hsum not long ago without much difficulty either.
C was of course originally designed for the PDP-11, but neither the standard nor the implementations have assumed that anytime this century. It would be a quite a stretch to say that thread local storage, atomics, the weird restrictions on pointers to deal with segmented architectures, IEEE floats, and other "modern" additions have anything to do with PDP-11s. And obviously you can take C/C++ code and efficiently build it for a wildly different architecture, like you do every time you use a compiler (including NVCC).
I'm not even saying that C is the fastest possible language because it really shouldn't be. What I'm saying is that decades of HLL advocates saying that we just need a sufficiently smart compiler to beat C have failed to produce one. C-family languages remain the gold standard for performance, and there's not much that even reliably competes beyond Rust and Fortran. Fortran is also an interesting example of a "low level" language without many of the bad ideas of C that ends up not much faster these days.
you can imagine a version of Haskell that doesn’t have polymorphism or laziness, that only has unboxed integers, and as a result doesn’t need a GC. in such a language it’s still easy for the compiler to do stream fusion; whereas it’s still hard in C because the compiler needs to prove the loop doesn’t have side effects.
> The author conveniently left out all of the things needed to understand that JavaScript version, including async/await, promises, modules, string interpolation, [...] not to mention the runtime that is running this, etc.
These are also left out of the Rust version.