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
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.
As the downcycle lingers on everyone’s doorsteps a lot of non profits that do incredible work are losing funding as the investors back out from commitments they confidently put forward when things were going well. It quickly shutters the non profits. It makes me sad tbh.
Can’t say this is the same thing that happens at Mozilla but you are very right in that a lot of nonprofits seem to be lead by those bring the same operational decision making experience and solutions that you see in publicly traded companies. There are plenty of non-profits that are indistinguishable from public companies in how the board is composed of an inner circle of wealthy unsavory people.
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.
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
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.
> A member of the Kent Archaeological Society analyzed the grotto and concluded in 2006 that it was likely a mediaeval denehole, a small chalk mine, reworked and decorated in the 17th or 18th century.
There are multiple buildings in my village older than that (and the core of the church is centuries older).
I remember there being sufficient documentary evidence in the entrance/shop/museum bit to conclude it was most likely created by the very people who “discovered” it, to serve as a tourist attraction.
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).
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 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
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)
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)
I might be misunderstanding, but I don’t think that's quite accurate. As I understand it, Zig ships a Clang frontend and wraps it with precompiled sysroots. Unless they're developing an LLVM backend, I'm not sure how it could serve as a completely self-contained toolchain.
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.
Interesting. OCaml cross compilation scared me the one time I considered it, so it's nice to know this is an option. I will be pedantic and say it isn't a replacement for a custom sysroot/binutils/whatnot, since it really just papers over those user-facing details by shipping a prebuilt collection of sysroots and using LLD. They sorta get this for free since they need it for cross-compiling Zig code anyways.
They're also getting an aarch64 backend soon (or has it already landed)? Really looking forward to this one for development on my Mac!
My point was that Zig uses their backends (which includes their homegrown ones), but since `zig cc` is a wrapper around Clang, it always goes through the `LLVM` path and sidesteps the Zig backend(s).
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.
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.
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.
reply