Anil Madhavapeddy, a Cambridge computer scientist, writes about OCaml, unikernels, MirageOS, FPGAs, WebAssembly, and systems.
HN commenters link his Mirage papers and OCaml experience report, and discuss unikernels and virtualisation in that context.
I think the AI portion is not just something that ought have a toggle, but it should not be part of the platform.
Somewhat recently, the ACM (one of the premier publishers for computer science) integrated AI-generated summaries for all papers, and it made these summaries appear in place of author-written abstracts; to find the abstract, users had to use a toggle. The ACM argued that this was a benefit. After significant community pushback, the ACM has swapped things: author-written abstracts now appear first, but users are still offered a toggle to access AI-generated summaries instead.
As highlighted by professor Anil Madhavapeddy [1], the AI summaries are often factually incorrect, sometimes obviously, but often subtly. This sentiment was corroborated by numerous colleagues of mine less publicly: they checked the AI-generated summaries of their own papers, and for almost every paper were able to identify at least one factually incorrect or significantly misleading statement.
Some people argue that AI-generated summaries help to democratize academia; I think instead they are democratizing misunderstanding. The models fundamentally lack the capacity to "understand" when what they say is wrong or misleading. It is not uncommon that I have students in office hours with severe misgivings about our course material because they asked an LLM some innocuous question to which they thought surely the LLM would generate an accurate response. The course material is, of course, drawn…
https://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf
> Mu is a true Haskell dialect in that code written in Mu may be compiled with a Haskell compiler.
> [...]
> Their experience with strict semantics has been positive. Particularly useful is the ease of obtaining meaningful stack traces, tracking resource usage, […]
My point was that "if S&C is to count as a Haskell success story (which it's often touted as), then it's fair to point out that it's a codebase where eager evaluation is used throughout." Please note the 'if'. The article presents S&C's large Mu codebase as a Haskell success story. In this context it's perfectly fair to point out that Mu has a strict semantics.
If you want to insist that Mu is an 'entirely different' language to Haskell then that's fine. As with natural languages, there's no objective line to be drawn between 'different dialect' and 'different language'. However, anyone who holds to this view obviously cannot follow the article in presenting a large Mu codebase as an example of Haskell in production.
If you find this interesting you may want to read about this more current research:
http://www.openmirage.org/
To quote from the vision paper http://anil.recoil.org/papers/2010-bcs-visions.pdf
Mirage is written in the spirit of vertical operating
systems such as Nemesis [17] or Exokernel [10], but
differs in certain aspects: (i) apart from a small runtime,
the operating system and support code (e.g., threading)
is entirely written in OCaml; and (ii) is statically
specialised at compile-time by assembling only required
components (e.g., a read-only file system which fits
into memory will be directly linked in as an immutable
data structure). These features mean that it provides
a stronger basis for the practical application of formal
methods such as model checking; and the removal of
redundant safety system checks greatly improves the
energy efficiency of the system.
It's back up now; the ML TCP stack was running a pcap dumper for debugging, which didn't cope well with a hackernews link.
Hacking is going pretty well on Mirage. The longer-term plan is to generalise the support libraries to work with other languages (particularly HalVM and GuestVM for Java), but it's far simpler to work with just OCaml for getting the first cut out. The Xen Cloud toolstack (also written in OCaml) is currently being adapted to support low-latency microkernel establishment, which will remove much of the hassle of coordinating multiple Mirage 'processes'.
Another interesting performance-related aspect has been the heavy IPC workloads that result from using many VM-VM interconnects. Some early benchmarks in http://anil.recoil.org/papers/2012-resolve-fable.pdf .
This is good though it's not clear whether these papers will appear in the PMC Open Access subset (https://pmc.ncbi.nlm.nih.gov/tools/openftlist/) and be bulk downloadable.
I've been doing some work with colleagues at Cambridge and Imperial over the last year on using LLMs to improve evidence synthesis, primarily trying to find papers on the effectiveness of certain Conservation interventions. It's becoming clear that you really need to move beyond screening papers only by title and abstract - there's often information buried deep within papers that can only be found with access to full text. My colleague Anil Madhavapeddy has written a bit about our adventures in trying to ingest full-text academic papers: https://anil.recoil.org/notes/uk-national-data-lib
Unfortunately, SML has no industrial users. At least, that I've heard of. It's a language that's used mostly in teaching and academic research. First ML I used was SML/NJ in my intro CS class, and haven't seen it since. Whereas OCaml has a many industrial users and is widely deployed. My favorite example is of course management layer for the Xen hypervisor[0][1], but there are more as well[2].
Adam Chlipala has a writeup[3] on comparing SML and OCaml that may be of interest to the discussion.
[0]: https://github.com/xapi-project
[1]: http://anil.recoil.org/papers/2010-icfp-xen.pdf
[2]: http://ocaml.org/learn/companies.html
[3]: http://adam.chlipala.net/mlcomp/