> Why isn't it more popular if it's so good? Because popularity and merit are not the same thing.
Yes! To add to that, the question itself is wrong. We should be asking, how is OCaml able to be so good without being popular? People get the whole thing backward.
The popular languages are typically popular first, then get good later as a result of that popularity. They have to work, they have to be good, they're too big to fail.
This is what happened with Java. It was marketed like crazy at first and only later got refined in terms of tooling and the JVM itself. The R programming language was a mess for data wrangling, but once it was popular, people built things like the tidyverse or the data.table library. The Python ecosystem was disaster with all different testing packages, build tools, and ways to create and manage virtual environments, until the relatively recent arrival of uv, more than three decades after the creation of Python itself. And then there's javascript that's had more money, blood, sweat, and tears poured into it to be improved in one way or another because that's what practically anything running in a browser is using.
Music being "good" is subjective. A programming language, however, can objectively be better if it allows a subset of programmers to better solve certain problems.
The reason for why OCaml is not more popular, thus, is that this subset is small. The reason for this may be either (a) habit or (b) it's not that much better than other languages. I'm gravitating to (b). OCaml guys seem to be quite dogmatic for the wrong reasons.
I posit (c) it’s from France and written mostly by French people and American naturally gravitates towards languages which generate hype in English and preferably from the USA.
Also it didn’t employ a marketing team to work on outreached and write fancy comments here and some people who have used it for 10 minutes are apparently offended by the Pascal-like syntax and can’t stop discussing it on every Ocaml discussion making every actual users tired.
You're right to point out the speed, but it is just not true that GUIs can't be fast. You can have screens that load quickly and shortcut keys etc.
You just have to make fast navigation and data entry a high priority. The assumptions and approaches people make today mean that generally isn't the case. With a TUI there is a hard limit on the amount of data you can load and that helps as a starting point.
- Often it's hitting a server is that is far away rather in the same building.
- you can put the web server in the same building
- Each page is very heavy with lots of JavaScript etc. loading
- you can build lightweight web pages if you priority small script size, minimal dependencies,
and do profiling to keep things in check
- Data loading delays rendering
- limit the amount of data loaded and displayed at one time
- Data is slow to load
- an older system has limited capacity meaning it's not an option to keep inactive data around
- this means data is more likely to be indexed
- new systems have very large storage capacities, leading to a larger and larger growing db
- eventually default configuration for the database does not allow for everything active to be indexed
- solution is to keep inactive data out of active tables being queried for normal operations
- Slow to navigate with mouse
- you can create a keyboard navigation system
- you can build keyboard shortcuts into every screen
- you can create autocomplete shortcut commands to jump to screens
Many years ago I used a TUI retail/inventory terminal that was running in an SSH session over a painfully slow wireless link. Each keystroke came with several seconds of latency. This was not a problem, though, since I'd memorized all the important menu sequences. I could just punch in a rapid-fire string of keyboard strokes representing an entire transaction and then just wait a few moments for the screens to catch up and a receipt to print.
I think this is one of the deepest problems with modern UIs - event delivery is no longer reliable. You type "abc" and only "ac" gets delivered to the application, or "b" ends up sent to another window. Maddening.
At work we recently moved from Jira to Linear. It it fully keyboard navigatable and has shortcuts for pretty much everything. It's great! For me the only downside is that al that keyboard greatness clashes with my Vimium browser extension. Oh well...
> You just have to make fast navigation and data entry a high priority. The assumptions and approaches people make today mean that generally isn't the case.
Indeed. Most developers today make their own easiness of development the priority, not anything related to the end user's experience. This is why software is so bloated and slow, but the pernicious idea of "developer experience matters more than speed" doesn't seem to be going away any time soon.
You can also buy a car, remove all it's part and do the road on feet. I'm not sure how the car was helpful to move across the roads but hei we have a car.
Very interesting and ambitious project and nice design. I hope the author will be able to comment here.
I'm interested to hear about the plans or capabilities in R' or Radiance for things like concurrent programming, asynchronous/scheduling, futures, and invisible or implied networking.
AI is here and will be a big part of future personal computing. I wonder what type of open source accelerator for neural networks is available as a starting point. Or if such a thing exists.
One of the opportunities for AI is in compression codecs that could provide for very low latency low bandwidth standards for communication and media browsing.
For users, the expectation will shortly be that you can talk to your computer verbally or send it natural language requests to accomplish tasks. It is very interesting to think how this could be integrated into the OS for example as a metadata or interface standard. Something like a very lightweight version of MCP or just a convention for an SDK filename (since software is distributed as source) could allow for agents to be able to use any installed software by default. Built in embeddings or vector index could also be very useful, maybe to filter relevant SDKs for example.
If content centric data is an assumption and so is AI, maybe we can ditch Google and ChatGPT and create a distributed hash embedding table or something for finding or querying content.
It's really fun to dream about idealized or future computers. Congratulations for getting so far into the details of a real system.
One of my more fantasy style ideas for a desktop uses a curved continuous touch screen. The keyboard/touchpad area is a pair of ergonomic concave curves that meet in the middle and level out to horizontal workspaces on the sides. The surface has a SOTA haptic feedback mechanism.
Thanks for your comment! In terms of concurrent programming in Radiance, it's likely I go for something inspired by Go's simplicity and Haskell's power with STM[0]. Actors are also on the table, but likely as a library on top of the native system, whatever it is. The important thing is that everything that involves "waiting" be composable in this system: timers, network i/o, IPC, file i/o, etc.
For the AI/OS intersection, it is indeed a very interesting design space. The key insight really is that the better the AI knows you, the more helpful it can be to you, so the more you give it access to, the better. However, to be safe, the OS itself needs to be locked down in such a way that personal data cannot leave your device. This is why capabilities-based security is an interesting direction: software should not have access to more than what it needs to operate, and you need fine grained control over that.
It looks like you've looked over a number of languages, but I don't see anything about Forth, Forsp, Ante, Steps, Austral, Wat or Vale? I'd suggest they all have useful components to steal from :)
I agree! I've been thinking about why terminal software is so compelling, and how to make that the default while keeping the system accessible to beginners. I think there's a way to do it, to unify GUI, TUI and CLI.
Take a look at what Rebol did in the late 90s. They have a DSL called "View" for making user interfaces with your scripts. Rebol itself shipped with a program that came with a ton of sample applications including Tetris. The creator of Rebol (Carl Sassenrath) was also big on the Amiga scene and envisioned what he called iOS (internet operating system, not the Apple iPhone OS) where you would do stuff like load a web page by just running the page's Rebol script iirc.
It never took off for various reasons. For one, the language was a bit like lisp, but with brackets. More importantly, it was commercial and then closed source for too long when Perl was really taking off.
Long story short though, whatever language you implement should have extremely high level primitives for simple GUI widgets. Forget Qt and Windows Forms...there HAS to be an easier solution. I can see how Rebol did it and surely you can make something like that possible.
Cool. Look at both View and Draw I think. It's all incorporated as part of the main language I believe. Here is the source for a simple calculator app:
Red has been in development for a LONG time as a modern rebol replacement. It still isn't complete like Rebol though last time I checked. The development team took a weird turn into block chain and trying to do an ICO and I'm not sure where they are anymore. The project is super ambitious and would be freaking amazing if it ever became production worthy.
Will be interesting to see how fast inference ASICs, diffusion LLMs, architectural changes like IBM granite small (when is that coming to OpenRouter?) and slight compromises for pre-generation can speed this up.
Also I wonder if eventually you could go further and skip the LLM entirely and just train a game world frame generator on productivity software.
They did say some packages were more. I bet some are 5%, maybe 10 or 15. Maybe more.
Well one example could be llama.cpp . It's critical for them to use every single extension the CPU has move more bits at a time.
When I installed it I had to compile it.
This might make it more practical to start offering OS packages for things like llama.cpp
I guess people that don't have newer hardware aren't trying to install those packages. But maybe the idea is that packages should not break on certain hardware.
Blender might be another one like that which really needs the extensions for many things. But maybe you so want to allow it to be used on some oldish hardware anyway because it still has uses that are valid on those machines.
37 Signals [0] famously uses their own Stimulus [1] framework on most of their products. Their CEO is a proponent of the whole no-build approach because of the additional complexity it adds, and because it makes it difficult for people to pop your code and learn from it.
It's impossible to look at a Stimulus based site (or any similar SSR/hypermedia app) and learn anything useful beyond superficial web design from them because all of the meaningful work is being done on the other side of the network calls. Seeing a "data-action" or a "hx-swap" in the author's original text doesn't really help anyone learn anything without server code in hand. That basically means the point is moot because if it's an internal team member or open source wanting to learn from it, the original source vs. minified source would also be available.
It's also more complex to do JS builds in Ruby when Ruby isn't up to the task of doing builds performantly and the only good option is calling out to other binaries. That can also be viewed from the outside as "we painted ourselves into a corner, and now we will discuss the virtues of standing in corners". Compared to Bun, this feels like a dated perspective.
DHH has had a lot of opinions, he's not wrong on many things but he's also not universally right for all scenarios either and the world moved past him back in like 2010.
Even with TS, if I’m doing web components rather than a full framework I prefer not bundling. That way I can have each page load the exact components it needs. And with http/2 I’m happy to have each file separate. Just hash them and set an immutable cache header so it even when I make changes the users only have to pull the new version of things that actually changed.
I'm old enough to have a first hand experience of building a Flash website that required to load couple hundred tiny xml files for configuration only to find out that some ~300kb was taking couple of minutes to load because of limited connection pool in old http.
Back then bundling and overly complicated build steps were not yet invented, so instead of serving one large XML (which would work out of the box, as there was a root xml and certain nodes instead of having data were linking to external files) I quickly decided to implement zip compression and bundle the package that way.
Fast forward to 2025 when most devs need an external library to check if number isEven and the simplest project need a toolchain that's more complicated that the whole Apollo project.
> not using TypeScript at this point is basically the equivalent for many people these days of saying that I use punch cards
I very much enjoy writing no-build, plain vanilla JS for the sake of simplicity and ability to simply launch a project by dragging HTML file onto a browser. Not to mention the power of making changes with notepad instead of needing whole toolchain on your system.
I've been leaning that direction more and more every year. ESM loading in browsers is really good at this point (with and without HTTP/2+). Bundle-free living is nice now.
Even frameworks with more dependencies bundling/vendoring just your dependencies at package upgrade time and using an importmap to load them is a good experience.
I'm not giving up Typescript at this point, but Typescript configured to modern `"target"` options where it is doing mostly just type stripping is a good experience, especially in a simple `--watch` loop.
Definitely team #noBundler for most websites. But I didn't wanna give up TypeScript. With Deno and even Node.js supporting type-stripping now natively, all I had to do for https://mastrojs.github.io was to use ts-blank-space to transform client-components on the fly.
Can't say I generally agree with dropping TS for JS but I suppose it's easier to argue when you are working on smaller projects. But here is someone that agrees with you with less qualification than that https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...
I was introduced to this decision from the Lex Fridman/DHH podcast. He talked a lot about typescript making meta programming very hard. I can see how that would be the case but I don't really understand what sort of meta programming you can do with JS. The general dynamic-ness of it I get.
Check out the most popular music today. Like the top ten songs currently. Do you think those are really the best songs out there?
Popularity is mostly driven by either trends or momentum.
reply