> your definition of dead is elms definition of stability
If Elm's definition of stability is keeping bugs and runtime errors for years, then I'm glad I stopped using Elm long ago.
Not only were the issues unaddressed, but for the past years the PR got no human response. For instance this one¹ fixes infinite loops in the core.
[¹]: https://github.com/elm/core/pull/1137
You are not entirely wrong, but there’s still a difference between being dead and very stable. Among the languages that compile to JS, I would look at ClojureScript as the prime example of stability rather than Elm. I mean Elm has removed features breaking compat; ClojureScript doesn’t do that.
I remember when Rich Hickey was asked "what feature of Clojure you regret and would like to remove?", he said: "None. Doing that would break stuff for people".
> your definition of dead is elms definition of stability, I think :D haha
The Elm community (or those who remained anyway) has a very cult-like way of spinning the current status quo as being good for you, even if it’s not.
Removing native JavaScript interop in 0.19? They’re just making it more pure! Sorry your project had to become impossible to continue on Elm, but this is the price we pay for a leader with vision.
No appreciable updates or bug fixes for 7 years? That’s just stability! Look how stable and mature it is that it can go 7 years without a release!
I've just stated working around that time when the cult was active. And I think that is the correct term for it because other languages that have been praised to the same level (ruby, rust, haskell) actually have things to show for and not just simplistic functional programming
Were people forced to use elm prior to a 1.0 release or something? Is Evan being accused of baiting people with a lovely experience and then bailing? I'm not really familiar, so maybe the ball was dropped in some kind of contract I'm not aware of.
If not, the expectations you and many have here seem pretty unreasonable. There's room for projects like Elm. Not every PL has to meet the demands of every single non paying user of the community.
> Were people forced to use elm prior to a 1.0 release or something?
Obviously not, but for a short while it felt like Elm evangelization was everywhere.
Ironically, the small group pushing it so hard at the company I was with at the time were arguing that it was very stable and production ready, despite being pre-1.0.
That argument switched for the 0.19 release, when it was argued that it was still early and changing a lot.
The argument switched again when they didn't make any progress for 7 years, which was supposed to be a sign that it was highly stable and mature.
> There's room for projects like Elm. Not every PL has to meet the demands of every single non paying user of the community.
Fully agree, but there's also room for opinions of people using the project. When a project encourages adoption and then pulls the rug out from under actual users, it's also okay for those users to be upset.
That's one thing the Elm project disagreed with. They had drama where even contributors were being handed 7-day bans for innocuous things like talking about native modules after the decision had been made to move away from them. Their subreddit was the kind of place ruled with an iron fist where any post that wasn't completely Elm-positive would be disappeared. There wasn't any room for disagreement in the Elm community and it partially collapsed on them when they pushed it too far.
Well surely evangelization doesn't absolve a technical leader for choosing to rely on a BDFL project that's pre 1.0.
People are welcome to their opinions, but I don't see a rug pull, I see a grad student who created a project that people enjoyed and a few companies offered to fund. Evan clearly wanted to maintain control over direction and stepping away from open source is completely acceptable and not uncommon for the very reasons on display here. People have completely unreasonable expectations from maintainers of free software.
Elm was very heavily evangelized for a while, and people were using it. Had there been a migration path through the breaking changes, it would have been a lot less disruptive.
Even if there had just been incremental bug fixes, I suspect between some and most people would have gotten over it, but seven years of silence is a very long time- long enough for an entire generation of new developers to start calling themselves seniors knowing only that Elm has stalled and shouldn't be used, because the controlling developers are unreliable and prone to giving the appearance of abandoning the language.
I've head the displeasure of working with more than one Elm zealot in the past, and also allowed a service to make it into production (which was a huge disaster). Due to that, I know a lot more about Elm than I'd like to.
I think the "Elm is stable not dead" seen from the few people that stuck around with Elm is largely cope for being stuck with an unmaintained language. Languages, like all other pieces of software need maintenance or they degrade in the world moving around it (e.g. there is/was no official aarch64 build of Elm in the period of non-maintenance).
I also would say that Elm is still largely unfit for most realistic production scenarios, unless you have the manpower to build everything from scratch, as interoperability with the outside web world (JS/TS) is an afterthough, and by some parts of the community not desired.
This, 200 times. No weekly news does not mean dead. In some specific places like this one, it means stable.
(And also arguably, for good or bad reasons, why it will never become mainstream).
This is quite different. Salvadori's work aims for optimal reduction of the full lambda calculus (which requires something called "bookkeeping"/"oracle"), while HOC works on optimal/parallel reduction of a certain subset of the lambda calculus.
Both approaches have been researched for a long time now, where HOC's subset is typically referred to as "abstract algorithm". For example, a version of the lambdas calculus where any variable can be used at most once (the "affine lambda calculus"), can be reduced optimally with interaction nets without requiring any bookkeeping.
The novel thing about Salvadori's work is that it develops a new (and better explained) bookkeeping mechanism.
The article discusses Twitter specifically. By practically all measures, Twitter (now X) is doing worse than before Musk acquired it. Indeed, Musk's creditors have downgraded the value of the investment multiple times. Financially, the acquisition has been a bust. It's been pure self-destruction.
Another thing about Twitter/X that most people don't realize is how little it has changed. Superficially it's changed, including a new domain name, but the actual code and operation seem to be more or less the same as before. And in fact some of the new features that shipped after the acquisition were already in the works before the acquisition. Years ago I wrote a Twitter-specific web browser extension, and aside from the change in domain name, the extension continues to work almost perfectly. In a way, it's shocking how little has changed.
There's a sibling comment that says the following: "i’ve been the arsehole who demands high standards and then lambasts folks when they don’t achieve it."
Then goes on to say that this is a bad way to get anything done
That seems obvious
I think what Musk does isn't this. I think Musk has high standards, then gets rid of people who don't meet them. Then tries to find and hire people who do meet them
If you can actually find people who do live up to incredibly high standards then you will very likely have a successful company
Frankly, the answer to this seems mundane to me. I served in the Army and put up with hardship and abuse on a level no engineer would ever consider acceptable, and so did everyone else in my organization. Why? Because we deeply believed that what we were doing was worth it for the larger good of country, something bigger than us. It's the same reason athletes in sports that pay shit or nothing at all will do it, or parents will sacrifice, suffer incredible hardship, and sometimes die for their children.
When I moved to my current house, my neighbor had been an engineer for Tesla, but he burned out and decided to renovate his current house, which had an unused barn, into a destination bnb. I talked to him a lot about his experience and why he did it in the first place. He and other Tesla engineers were true believers. They were leading a green revolution that was going to save the world. SpaceX is in a similar situation. Achieving viable large-scale space travel is a literal moonshot that nerds dream about.
It's no mystery either why his antics have failed at Twitter. Nobody at Twitter believes that 140-character microblogging will save the world. They don't get to go to work feeling like firefighters or astronauts. They'll work for pay and comfort, not for mission.
This is HR speak and from my experience, "technical" people talking about these topics tend to be overcompensating for lack of competency, or interest, in their domain. Its objectively easier to talk about this stuff all day vs coding or being knee deep in the guts of systems. My last job was big on this and many engineers with high "EQ" were rapidly promoted into middle management roles. Lets just say, the promotions were short lived because a "reduction in force" followed. This isn't an excuse to be a jerk, but the industry has over indexed on HR/psychology talk and real hardcore technologists don't give a shit. Fortunately many of these firms are super upfront about these things, like on their career page, or if you feel inclined, look at their leaders/manages on linkedin - they put this stuff on blast all over their profiles. A little research goes a long way.
I wrote a piece on this exact point and how much you should actually worry about EQ:
Technical and cognitive skills are clearly "threshold factors" that cannot be ignored— they get you in the game and let you keep playing it. While they might not be sufficient, they sure are a necessary condition for success in most domains.
In order to stand out on your EQ skills you have to be first competitive on your technical/cognitive skills. It will be tough to compete just on your social skillset.
EQ is probably not a differentiator at lower levels and early stages of your career. Technical chops, cognitive skills and execution will probably help you stand out more. It's only when you move on to the managerial and executive ranks that EI/EQ starts becoming a differentiator, what Goleman calls a "discriminating competency".
Even at higher levels, EQ is not a given. Where it can probably make the most impact is in avoiding pitfalls once you get there, what researchers call “leadership derailment", rather than being an active mechanism in reaching there.
Just because a person lacks social skills does not mean social skills magically become unimportant. For all technologists like to brag about their world being black-and-white and that technical chops are the be-all and end-all, this is only true in very specific roles. For everything else, you have to deal with actual human beings, and in this case "this is the way I am, get over it" is generally a very poor strategy.
javascriptland really warps peoples minds on stability and project-liveness