I think there is a crowd, maybe less common than the others, that just want less warts. I can understand that, though I'm not sure the usual dialects that get thrown around are much better.
What I don't understand is wanting to replace elisp with a mainstream scripting language. None of them are really functional-style languages; it's just a completely different world.
(Non-scripting languages are a different story, but fundamentally a different use case.)
To each their own, but I don't really understand the sheer hatred elisp puts in some people. As far as scripting languages go, it's pretty good. I haven't seen a scripting language alternative I'd really prefer for this - maybe Clojure or some other modernized lisp.
I did - I first came to emacs during my lisp phase. I didn't stay with lisp, but I did stay with functional programming, and in those days emacs was the best environment for a number of functional programming languages (maybe still is).
This is how I justify not switching back to vanilla, despite not really being an evil user. Doom's module system is really great for organizing a config.
I've used AI for a number of Emacs-related utilities and configs. Just today I created a script to reproduce the particular combination of MSYS2 packages I use for my newer on Windows setup - the hard part being to get native comp working. Small, but it's the sort of rarely used convenience I wouldn't have written up in the past.
A common thread I see in this, and other articles of its kind, is that rarely do they come out and say what kind of project they are working on, leaving the headline to sound generically applicable. I can make some guesses, given the emphasis on async, that they contrast with Go, and the mention of systems programming as an exception. But after enough of these, one would get the impression that Rust is primarily a backend language, competing with other backend languages, that happens to also be good for systems. I'm not sure that is even the use case driving corporate adoption.
Nearly 10 years of experience at Microsoft, I've been looking for a remote position for almost a year.
Even just finding appropriate openings has been next to impossible. Every company seems to be looking for either a generalist (lots of full-stack) or a senior in an exact specialized bucket and stack. My role at Microsoft was a sort of specialized databases/compilers/functional programming hybrid, but without clear buzzwords no one seems interested. What was once a frequent stream of corporate recruiter messages dried up a little over a year ago too.
My suspicion is that things are a lot better for non-remote positions in the usual hubs.
Similar but not exactly the same as named impls, I'd really like to see a language handle this by separating implementing a trait from making a particular existing implementation the implicit default. Orphan rules can apply to the latter, but can be overriden in a local scope by any choice of implementation.
This is largely based on a paper I read a long time ago on how one might build a typeclass/trait system on top of an ML-style module system. But, I suspect such a setup can be beneficial even without the full module system.
Rust opened the door to innovation in the low-level languages space, but as long as it is already the most theoretically advanced practical language there, it will always attract the audience that actually wants to push it further. I don't know if there is a way to satisfy both audiences.
As an idea, what about allowing the 24 hours to be bypassed using adb (edit: bypass to allow indefinitely, not just install a single app)?
I understand there is some problem trying to be solved here, but honestly this is still quite frustrating for legitimate uses. If this is the direction that computing is moving, I'd really rather there were separate products available for power users/devs that reflected our different usage.
Back when I still thought all headphones were basically the same, I was writing some music and I could not understand why the cello lines sounded so much louder than the violin lines at the same dynamic. It was only years later that I found out that mainstream headphones are tuned to boost the bass, which is supposedly the mainstream taste.
If your tastes in music are not mainstream (and mine definitely is not), mainstream headphones will ruin your music more than you realize - for years I just thought that was how recorded music is supposed to sound, and it wasn't very good. Trying a neutrally-tuned headphone can change your (musical) life. Unfortunately, very few wireless headphones are tuned that way.
Edit: Part of why I never looked into it sooner, I had heard so much about "audiophile snake oil" over the years, I thought that was all there was. That exists, but there plenty of headphones marketed to "audiophiles" that are legitimate.
I don't remember where I read it, but I think Rust cited Cyclone as an influence, a variation of C with "region-based" memory management - more or less the literature name for "lifetimes". I think Rust may be the first to use it directly for stack variables, however.
Early on in my computing life, I discovered TeXmacs as a user interface for a Computer Algebra System I had been playing with called Axiom. Ironically, this was before I had ever even heard of either TeX or Emacs! It seemed like a cool piece of software, but when I later learned LaTeX I discovered I prefer non-WYSIWYG for everything but lecture notes. Still, in the years since I've recognized that this setup, combining a math engine with a rich display interface, was an early version of what would later be popularized as Notebooks.
I tried that too - it works great for large files, but still chokes on large numbers of files. Which, when I'm transferring photos, is usually the case.
I too find the phone market, especially in the United States, has outright abandoned users like me. About a year ago I rushed to buy what seems to have been the last flagship model sold in the United States to have micro SD card support (an Xperia 1V), as soon as I saw stocks were dwindling. Now there are none left, and while I should be good for a few years, I fret over what I will do next time.
Just the other idea, I tried transferring a large number of photos from phone to PC with a cable, just to see how bad it would be without a card. It was so slow I eventually gave up (not to mention the timestamps were messed up). I have no idea how anyone manages this way.
N pretty much is "arbitrary-length information theory". As soon as you leave the realm of the finite, you end up with N. I'm not convinced that any alien civilization could get very far mathematically or computationally without reinventing N somewhere, even if unintentionally (e.g, how does one state the halting problem).
I'd agree with that for practical purposes, but sometimes the external perspective can be enlightening philosophically.
In this case, to actually prove the statement internally that "not every real number is computable", you'd need some non-constructive principle (usually added to the logical system rather than the theory itself). But, the absence of that proof doesn't make its negation provable either ("every real number is computable"). While some schools of constructivism want the negation, others prefer to live in the ambiguity.
I am talking about constructivism, but that's not entirely the same as saying the reals are not uncountable. One of the harder things to grasp one's head around in logic is that there is a difference between, so to speak, what a theory thinks is true vs. what is actually true in a model of that theory. It is entirely possible to have a countable model of a theory that thinks it is uncountable. (In fact, there is a theorem that countable models of first order theories always exist, though it requires the Axiom of Choice).
The idea is we can't actually prove a non-computable real number exists without purposefully having axioms that allow for deriving non-computable things. (We can't prove they don't exist either, without making some strong assumptions).
What I don't understand is wanting to replace elisp with a mainstream scripting language. None of them are really functional-style languages; it's just a completely different world.
(Non-scripting languages are a different story, but fundamentally a different use case.)