1. Web3 hired a lot of these people and so they had less time to work on this stuff. Shame to spend that much on a dead end but eh
2. Scala died with Big Data. It is still around and all but noone care anymore, which emptied the room. It also happened that the whole Implicits experiment for polymorphism, which scala was really supposed to explore, did not pan out that well
3. Effects progressed but... Mostly out of view. Ocaml shipped them with its multicore, we are seeing good work on the academic side, you see Verse wanting them, etc. Same thing with linear types.
4. Dependent types ... Never really crossed to the realm of production. And Idris and co are mostly "complete" so it slowed down
5. Oh and monad interest, mostly fueled by scala, died slowly. Effect handlers seems to be a nicer solution in practice to most of this stuff.
6. Typescript killed a lot of the need for advanced stuff, same with python and ruby shipping their stuff too. Meanwhile Rust and Elixir showed you did not need the really up there stuff to have results in prod.
In the end what happened is that a lot of the highly abstract stuff was driven by "hype domain" that died, while more pragmatic but limited implementation burgeoned and absorbed some of them. Rubber met the road and that tampered a lot of people down.
There is still work being done, but rn it is more at the "experimental language" stage. Think Rust in the mid 00s.
Oh and Rust mindshare is still growing. A lot. A looooot.
Regarding tools affecting their career... Right now pretty limited. We mostly see move around JS and some stuff around Rust for all kind of application. Outside of this, this generation burned out maintaining stuff. And most of the (small) set of people interested in low level are already consumed by keeping the existing projects running. We have a dire lack of investment in low level tooling.
It's really too bad too. Most of the languages we've settled on have glaring problems, but I guess "critical mass" doesn't really care. Python's packaging is a mess (and a host of other problems), JavaScript has almost as much baggage as Java with much worse design decisions, over-complicated tooling, etc. (but has arguably some of the best runtime implementations in existence). Rust is good, but has sharp edges and a steep learning curve.
Both Rust and JS have adopted some FP concepts that are pretty nice, so there's that.
As I understand it, it's related to the decision to make the entire interpreter part of the public C extension interface which drove everyone to write C extensions for anything that was remotely performance sensitive (and the breadth of the extension interface and the pervasiveness of C extensions in the Python ecosystem made it really difficult to make substantial backwards compatible performance improvements in the interpreter). Since so much of the ecosystem is C, Python package management has had to try and figure out how to distribute arbitrary versions of C software to arbitrary target systems which is really hard in large part because C projects don't have any standard build tooling or dependency management. As far as I know, no one has figured out how to do this well given Python's constraints (the best language package managers just absolve themselves from Python's original sin--pushing the ecosystem toward FFI rather than making the core runtime model fast enough for native code).
None of the above is an argument as to why pip, poetry, virtual envs and half a dozen other tools and methods are needed to manage packages with Python. I'd go so far as to say that this isn't even a language level issue, as much as it's an implementation detail, a rather important one. However, for some context, Python first came out in 1991. Back then, nobody was really focusing on making anything run well on multiple cores, best you could get was multiple CPUs in somewhat esotheric systems. It's far easier to understand the design decisions for a programmer friendly (and hardware hostile) language in the 90s.
You also can easily guess who of these two get i18n right earlier.
The AOLServer was made possible by the decisions to have an API to have specific versions of interpreters (including highly constrained safe ones), by forcing extensions to have per-interpreter state and make interpreters communicate by messaging on Tcl level. This resulted that if your extension worked with several interpreters in single thread execution, it would work with several threads ruunning in parallel. The same is for just Tcl code, which does not even know which thread it gets executed on.
Thus, Python developers did not do any looking around.
Tcl also has a simple but effective package management architecture, that required specification of package versions from the start, so no version hell.
Later, a fully functional multiplatform binary package server/client was developed for Tcl [0]. It died of neglect while pythonistas spent (are spending) years trying to build something satisfactory.
Yeah, this matches up pretty much exactly with my understanding of the issue. Python as a language is "pretty good" but far from perfect, and it's really unfortunate that C's packaging/building ecosystem is in such a horrible state.
> it's really unfortunate that C's packaging/building ecosystem is in such a horrible state.
This is a recurring theme in my career. It's one of my cornerstone grievances with Nix as well (any time I need to write a Nix package I end up having to package some obscure C dependency that my package transitively depends on). :)
It is related, but not in a way that matters much. My main issues with Python are related to the language itself, primarily around duck-typing, lack of good lambdas, import side-effects, etc..
Rust has a steep learning curve, but I'm not sure what its "sharp edges" are? Certainly it has fewer sharp edges than a fully dynamic language? FWIW, I'm not a Rust evangelist or anything; my background is largely Python, Go, C/C++ with a smattering of Rust and JS/TS.
I would say the sharp edges aren't unexpected runtime behavior — compiles => works as expected, barring off by one errors — but rather things like “I just spent an hour figuring out the best way to build a tree out of nested HashMaps because the borrow checker didn't want me to do overlapping mutable borrows” or “what's the right way to be agnostic with regard to owned or borrowed data in my struct/function”. I don't consider these to be part of the learning curve because the problems are inherently more complicated than just “how do I use rust”.
Conventionally we use "sharp edges" to mean things which are dangerous in a surprising way. For example freshly cut paper has a sharp edge, it's very easy to cut yourself painfully on a sheet of blank paper. The things you've described don't threaten to be dangerous or surprising. They're not good but they don't strike me as "sharp edges".
I see what you mean. As the sibling noted, I think you're using "sharp edges" in an unconventional way, but Rust definitely has a sort of unpredictable developer experience. Some things go really fast and the programmer finds themselves thinking, "wow! this is as easy as Python/Go/whatever!" and other times something that seems to be easy fails to compile and you get a compiler error that says you need to fix one seemingly small thing, so you try and fix that small thing and you get another seemingly-easy-to-fix compiler error and you just keep pulling on that thread until you've forgotten the problem you were originally setting out to solve. (:
I don't think this is a "sharp edge" (maybe "indeterminately long threads to pull") but it definitely is an unpleasant experience. If anyone knows of any good names for this category of frustration, I'd be happy to hear them!
1. Web3 hired a lot of these people and so they had less time to work on this stuff. Shame to spend that much on a dead end but eh
2. Scala died with Big Data. It is still around and all but noone care anymore, which emptied the room. It also happened that the whole Implicits experiment for polymorphism, which scala was really supposed to explore, did not pan out that well
3. Effects progressed but... Mostly out of view. Ocaml shipped them with its multicore, we are seeing good work on the academic side, you see Verse wanting them, etc. Same thing with linear types.
4. Dependent types ... Never really crossed to the realm of production. And Idris and co are mostly "complete" so it slowed down
5. Oh and monad interest, mostly fueled by scala, died slowly. Effect handlers seems to be a nicer solution in practice to most of this stuff.
6. Typescript killed a lot of the need for advanced stuff, same with python and ruby shipping their stuff too. Meanwhile Rust and Elixir showed you did not need the really up there stuff to have results in prod.
In the end what happened is that a lot of the highly abstract stuff was driven by "hype domain" that died, while more pragmatic but limited implementation burgeoned and absorbed some of them. Rubber met the road and that tampered a lot of people down.
There is still work being done, but rn it is more at the "experimental language" stage. Think Rust in the mid 00s.
Oh and Rust mindshare is still growing. A lot. A looooot.