I was puzzled by this article at first, but when you put it that way it makes more sense. The author also had a presentation awhile back about why Haskell is a terrible language for startups to adopt. I imagine that in the current venture environment vibe coding is being pushed heavily by investors since companies are effectively in an arms race where feature development cost is moving towards zero and investors don't care about individual companies because they have a portfolio of bets.
I don't think it has almost anything to do with vibe-coding. When I tried Haskell and OCaml some 3 years ago, they were infuriating in terms of tooling and just needless friction (don't ask, forgot, but it was mostly around package management and just entering a project and be able to run the program was a saga).
Iteration speed is not only to appease business people. As a long-time dev I prefer for my PL and its tooling to not stand in my way. I want to be enabled, not be left a scarred veteran with badges of honor like "Managed to install 5 dependencies and compile and run! And it only took me 3 hours!" or some such.
Compare to Golang, Rust, Elixir, and no small amount of others -- you add a dependency, run a command, twiddle your thumbs 30 seconds, done.
I want to solve problems. Not troubleshoot tooling that should have been prod-ready 10 years ago.
I've been using Haskell for 20 years. I've been running a company built on Haskell for 10. I have a very large legacy Haskell codebase. I've invested in several companies built on Haskell. Your anecdote is about your own lack of familiarity, nothing more.
Yes, companies can get into trouble with Haskell compile times, memory use, etc., but enforcing disciplined coding rules and advances in tooling solved the majority of the problems by 2016.
We use LLMs to assist in writing Haskell and have for several years. We keep track of compile times to catch regressions and on our largest code base an agent-driven change takes an average of 96 seconds (as of this month) to compile. Agents looking to do quick compile checks during code writing can run with flags that make the compilation run in less than 5 seconds. In all cases, running out test suites takes a lot longer than compile times.
The only time this isn't true is when you compile from cold start, as you would when using multiple work trees...which is the expected behavior when vibe coding features. So yes, I believe the issues they're running into have a lot to do with vibe coding. Check out all their integrations...Haskell's probably a poor match for what they do, but vibe coding integrations is probably what they need to do to get new customers.
To comment separately: lack of familiarity is true of course but do consider your bias -- familiarity should come quickly and easily. Long gone are my days where I wanted to wear badges of honor and suffer through difficult tooling, and I am willing to bet that's true for a lot of programmers.
We want to iterate and progress. You likely are used to Haskell's tooling quirks long time ago. Everyone else outside of the ecosystem does not have that advantage.
IMO from the info given in the OP it seems to me that they never actually needed Haskell, not playing to its strengths anyway, especially if they felt Python was an adequate replacement -- which it absolutely is not if you value the compile-time finding of bugs, better known as "a strong static typing system". But that's a separate discussion vector.
It's people over 65. Cell phone ownership is pretty much universal, but only 78% of people 65+ own a smartphone. I don't think that's really surprising at all. I wouldn't expect an 80 year old to adopt a smartphone when their cognition, fine motor control, and/or vision is going. And who needs one in a nursing home? I bet if they broke it down further you'd find that the non-ownership skews towards people who were already elderly ~15 years ago.
Perhaps unsurprisingly, in New England jam seems more popular than jelly. The FDA regulates the labels...jelly is made from fruit juice, while jam is made from fruit chunks. The only jelly I routinely see is concord grape jelly. Jams are usually apricot, raspberry, or strawberry.
Given the number of small batch jams available at various farmers markets, my guess would be that for smaller farms, making jam is more practical than jelly.
> Reviewing code is important, but it's only 50% of the learning process, at best
I don't know about everyone else, but the code I reviewed as a Junior was high quality code I was expected to learn from. That's entirely different from doing code review on whatever CC outputs.
Is there really nothing like BitTorrent for git, or have we just not heard about it because of GitHub's network effects? It feels like this problem was solved long ago for binaries.
Yeah I’ve met the Radicle people a couple times. I’ve never given it a thorough review but, for their goals, their designs have always seemed strong, and they’re pleasant people to chat with.
The main difference was atproto wanted to tackle scale, so we went with a servers & aggregation model. Radicle is going for device-to-device networking as a primary goal.
Do you think it will be possible to use them together? Having some sort of unified distributed system is intriguing to me. (e.g. can the Radical foundation and AT-proto foundation integrate, even?)
gittorrents were talked about and built at least 15 if not 20 years ago.
the issue isn't mirroring of data, this is a solved problem. everything else that a forge does is a problem - issue tracking, PRs, reviews, CI/CD, authn, authz, secrets, audit trails, ...
BitTorrent also enabled search engines to be built easily, which created discoverability. Unfortunately it's a much harder problem for git repos, especially when competing with GitHub search.
Git is already distributed by itself. The management-part is what's missing (mergerequests, permissions, issues..), and it's disputable whether this is really necessary, or just a nice to have.
Every country tries to claim critical dependency for innovations. I guess you parochially mention that one because you remember that narrative (maybe because it makes you feel better).
I maliciously searched for examples of the French thinking they invented the transistor.
Turns out the French do have a claim of inventing it simultaneously (at the same time as Bell) and the French even commercialised their version since their tech had different parameters (Apparently it was two German inventors working for Westinghouse in France on a project for French telecoms as I recall). The history of invention/commercialisation is usually wierd.
>Apparently it was two German inventors working for Westinghouse in France on a project for French telecoms as I recall
So the Germans invented it! JK
I like how you put this. It always seems weird to me how some people get hung up on these claims when it's so obvious that history is full of basically simultaneous inventions.
Except ASML licensed the technology from the US Government, after the government labs built the first EUV fab in 2001. Not to take anything away from ASML...all the US companies that also licensed the tech failed to commercialize it, but the US Government blocked Canon and other Japanese companies from acquiring the technology. The entire reason ASML has the technology and nobody in Japan does is geopolitical.
I mean, your brain has an order of magnitude more neurons than there are people on the planet. I think humans are just incapable of wrapping our heads around the sheer number of tiny things that fit in small macroscopic spaces.
reply