chris_armstrong

I'm working on ocgtk, which are GTK4+ bindings for OCaml.

My current focus is adding support for signals, amongst other things: https://www.chrisarmstrong.dev/posts/ocgtk-development-updat...

Not yet - it's mostly a build tool, but package management abilities (which is otherwised covered by opam) is being added to it^1. It's currently usable for some projects (and worth trying out), but still in preview mode.

^1: https://dune.readthedocs.io/en/stable/tutorials/dune-package...

Installing via opam and using the cygwin method is supported and should be working fine (cygwin is just used for build - binaries still just link with mingw).

That specific combination (ocaml + mingw) has a known problem with ocamlfind that's still awaiting a new release (see https://github.com/ocaml/ocamlfind/pull/112). ocamlfind underpins quite a bit of the package ecosystem, so this one is annoying, as the mingw workflow is otherwise quite good.

I completely forgot about Wolverine, but you've reminded me I was using that back in the day to read my mail from Fidonet point (as well as Bluewave).

“cognitive surrender”

It’s maddening, because you can’t reason with a person who won’t even think for themselves

The answer, as always, is to write a compelling story about it, and make the front page of ‘new’.

No where in Australia would you expect a fridge to be supplied as part of a tenancy. It does restrict what you can buy, as may removalists will not touch move a fridge if there’s too many stairs or if you can’t get it in the door

I would say Australian English relies on this negation even more than British English, to the point of being confusing without more cultural context.

Genuine independence is almost impossible at this size, because you need a strong internal discipline to only rely on small donors, and not bend your organisation’s mission to keep larger donors

I think this because nonprofits are subject to a similar market discipline as companies: they compete for funding, relevance, market share etc.

And their board composition converges similarly as those same people are relied upon for their connections to fundraise, hire, etc. They don’t want to be seen taking an unusual strategy as it would be perceived as risky and jeopardising precious donated funds, so the same groupthink emerges.

Even if someone outside these circles was hired, they’d be knocked down with the smallest misstep, with the veiled criticism they weren’t suitable for the position (ie someone with better connections should have been chosen), so even they will fall into line.

Non profit organisations trying to remain relevant (or just survive) behave this way because they arent much different from companies operating in a market for profit.

Their leadership is often not that much different, with similar people working in similar jobs educated in the same institutions and walking in the same social circles, producing the same solutions to the existential problem of organisational survival.

I stand corrected - there’s so little known about it that it’s probably some strange labor of love from recent centuries

It was discovered in the 1800s, the shell grotto is much much older and probably built over a very long period of time

This is probably the highlight of a visit to an otherwise unremarkable English seaside town. The chambers are very old (even by English standards) and so unlike anything else medieval that is still around.

It's interesting reading many of the associated comments, because there is a genuinely active effort to address many of the pain points of the language:

* Windows support has improved to the point where you can just download opam, and it will configure and set up a working compiler and language tools for you[^1]. The compiler team treat Windows as an first tier target. opam repository maintainers ensure new libraries and library versions added to the opam repository are compiled and tested for Windows compatibility, and authors are encouraged to fix it before making a release if its reasonably straightforward

* debugger support with gdb (and lldb) is slowly being improved thanks to efforts at Tarides

* opam is relatively stable (I've never found it "buggy and surprising"), but there are aspects (like switches that behave more like python venvs) which don't provide the most modern behaviour. dune package management (which is still in the works) will simplify this considerably, but opam continues to see active development and improvement from release to release.

* the platform team (again) are working on improving documentation with worked recipes and examples for popular uses cases (outside of the usual compiler and code generation cases) with the OCaml Cookbook: https://ocaml.org/cookbook

There are other things I find frustrating or that I work around, or are more misperceptions:

* there isn't a builtin way to copy files because the standard library is deliberately very small (like Rust), but there is a significant ecosystem of packages (this is different to other languages which cram a lot into their standard library). The result is a lot of friction for newcomers who have to install something to get what they need done, but that's valued by more experienced developers who don't want the whole kitchen sink in their binary and all its supply chain issues.[^2]

* the type inference can be a bit of a love/hate thing. Many people find it frustrating because of the way it works, and start annotating everything to short-circuit it. I've personally found it requires a bit of work to understand what it is doing, and when to rely on it, and when not to (essentially not trying to make it do things it simply will never be able to do).[^3]

* most people use singly-linked lists because they work reasonably well for their use cases and don't get in their way. There are other data structures, they work well and have better performance (for where it is needed). The language is pragmatic enough to offer mutable and immutable versions.

* ocamlformat is designed to work without defaults (but some of them I find annoying and reconfigure)

Please don't take this as an apology for its shortcomings - any language used in the wild has its frustrations, and more "niche" languages like OCaml have more than a few. But for me it's amazing how much the language has been modernised (effects-based runtime, multicore, etc) without breaking compatibility or adding reams of complexity to the language. Many of these things have taken a long time, but the result is usually much cleaner and better thought out than if they were rushed.

[^1] This in itself is not enough, and still "too slow". It will improve with efforts like relocatable OCaml (enabling binary distribution instead of compiling from source everywhere) and disentangling the build system from Unixisms that require Cygwin.

[^2] I particularly appreciate that the opam repository is actively tested (all new package releases are tested in a CI for dependency compatibility and working tests), curated (if its too small to be library, it will probably be rejected) and pruned (unmaintained packages are now being archived)

[^3] OCaml sets expectations around its type inference ("no annotations!") very high, but the reality is that it relies on a very tightly designed and internally coherent set of language constructs in order to achieve a high level of type inference / low level of annotation, but these are very different to how type inference works in other languages. For example, I try and avoid using the same field name in a module because of the "flat namespace" of field names used to infer record types, but this isn't always possible (e.g. generated code), so I find myself compensating by moving things into separate modules (which are relatively cheap and don't pollute the scope as much).

I also find languages like OCaml avoid a lot of this nonsense in their libraries because the ability to build layers and layers of complex abstraction isn’t there in the same way as Haskell, Rust, or any of the LISPs

This resonates. I spent a fair bit of time thinking about library design for an OCaml library that didn’t directly expose more complicated language features (like functors and first class modules) where they weren’t needed.

(I presented on it recently: https://www.chrisarmstrong.dev/posts/icfp-wrapup-2025-10-18)

The ICFP/SPLASH papers are now starting to find their way to HN.

This was a HUGE combined programming conference with several competing tracks over 7 days. You can find the program here ^1 (you can often find a link to the abstract or full paper if you click on it)

Streams from the sessions will also show up here^2 (you’ll need to match the day and room and ff to the time it appeared)

^1: https://conf.researchr.org/program/icfp-splash-2025/program-...?

^2: https://youtube.com/playlist?list=PLyrlk8Xaylp5ihrTVeOSaylaB...

zig has a cross-compiler frontend (zig cc) which can be used as a drop-in replacement for a custom sysroot + binutils + gcc for several platforms. I've used it to build OCaml cross-compilers that only depend on zig itself (https://www.chrisarmstrong.dev/posts/ocaml-cross-compilation...).

There are other projects that have used it in a similar way too.

[1] https://actually.fyi/posts/zig-makes-rust-cross-compilation-... [2] https://jcbhmr.com/2024/07/19/zig-cc-cmake/

If I recall correctly, this is one of the final pieces that allows zig to be used as a fully self-contained cross-compiling C toolchain (once its linker is enabled for more platforms / formats)

Damn this is a blast from the past - it was such an ambitious project with so many interesting ideas to explore. CoreObject itself was revolutionary in its thinking about distributed document sharing and versioning, let alone some of desktop environment ideas for managing projects.

I know Quentin Mathé, kept CoreObject going for a decade longer, but I haven't heard from the rest of those involved for a very long time.

I almost never find a use for GADTs or functors or carefully specifying module types, but when I need them, they help me get stuff done neatly.

Even the object system which most OCaml developers avoid, is actually very useful for some specific modelling scenarios (usually hierarchies in GUIs or IaC) that comes with similar type system guarantees and minimal type annotations.

As someone who uses OCaml for hobby projects, I appreciate how little the language gets in your way when you want to just “get shit done”, despite the language’s origins in academia and industrial uses.

The type system usually means that I might take longer to get my code to compile, but that I won’t spend much (if any) time debugging it once I’m done.

I’m in the middle of pulling together bits of a third party library and refactoring them over several days work, and I’m pretty confident that most of the issues I’ll face when done will be relatively obvious runtime ones.

Onlynulls, the subscription-only service you’d be too ashamed to have your supervisor find you on.

I think the tragedy is that we don't have fluid ways to move between them, that these different development modes (solitary and social, dynamic and static) have produced philosophically and practically incompatible tools and methodologies.

The author spends a lot time describing programming as a solitary activity (discovery, analysis) using like metaphors (poets, explorers, etc) and draws his conclusions thus, emphasizing the malleability of LISPs and Smalltalk as ideal for this task.

I think the author examining the fads of agile or XP would draw quite opposite conclusions if they observed programming as a social activity, building a shared knowledge and understanding that is constantly refined before it is "abandoned" as a piece of software.

The wildest claims are those of increased labor productivity and economic growth: if they were true, our energy consumption would be increasing wildly beyond our current capacity to add more (dwarfing the increase from AI itself).

Productivity doesn’t increase on its own; economists struggle to separate it from improved processes or more efficient machinery (the “multi factor productivity fudge”). Increased efficiency in production means both more efficient energy use AND being able to use a lot more of it for the same input of labour.

Might I add - this isn't limited to languages like TypeScript which simply try and make underlying untyped languages (like JavaScript) safer. It affects well-designed strongly-and-statically-typed-from-the-ground-up languages which have expressive type-constructs (Rust, anything ML-based, etc.) used to reduce repetition and code-generation steps.

Many of the highlighted problems come from TypeScript allowing such complex type definitions in the first place, which in turn stems from JavaScript allowing such an open and untyped (and yet convenient) compositional model.

The expressiveness of JavaScript is a curse upon every library author who (in vain) may try to design an interface with a simpler subset of types, but is undone by the temptation and pressure to use the flexibility of the language beneath.

The author's instincts are right though - target a simpler subset of TypeScript, combine code generation with simpler helper libraries to ease the understandability of the underlying code, and where a simpler JavaScript idiom beckons, use runtime safety checks and simpler types like `unknown`.

OCaml

The compiler is very fast, even over large codebases.

Mostly trying to bring AWS tooling to the platform[1], or experimenting with cross-compilation[2] using another less well known systems language, zig.

[1] https://github.com/chris-armstrong/smaws/ [2] https://github.com/chris-armstrong/opam-cross-lambda