johnnyjeans

The part where it becomes appearances is that it's public. The negative impact here stems from the office of the president criticizing the CEO of a publicly traded company, using an unofficial but public channel. This impact doesn't exist if it happens in private backchannels.

I think it's foolhardy to hold any certainty on the effect of transitioning from gloabalism to neo-mercantilism, which seems to be the economic policy of this admin. Given the complexity of the systems involved it should be flagrantly obvious that whether this is good or bad for the American people is wholly unpredictable for tiny little monkey brains. Thus, when I speak of the negative impacts in this context, I'm implicitly just sticking to what's definitely harmful, which is tied up in appearances here, and empirically measurable in intel's stock price (though it seems to be mostly minimal, thankfully.)

As I understand it, people have a higher priority of maintaining affiliation with social groups (of which, political parties are an example) than they have a commitment to any given personal view. It varies based on context, the person, etc. and is obviously a complex phenomenon. But the default operating mode of the human being is to toe the line and to (genuinely) change their views based on where their self-identified in-groups are heading. Mob mentality, group think, etc. All sides of the same coin.

Rhetoric is empty. Always.

In fairness the laisseiz-faire market has been dead for over 2 centuries, it's just that this kind of thing usually happens with backchannels, often with a threat of malicious legislation if you don't play ball. There's a point where the more capital you control, the less freedom you actually have. For a company the size of intel, the line between private and public is blurred. Sometimes it's brazen, like with the seizure of the railroads in the 19th century, but the state is usually sensible enough to keep the illusion alive in the public's eye if they can help it.

This administration doesn't seem to care very much about appearances. Nothing you and I can do about it but pity the poor sons of bitches who are large enough to be perceived by the archons, and clench our assholes in the hopes that we aren't swept up in the damages.

you're right, but sec is about threat profiles. there's a point where selinux, firejail, etc. aren't enough either. even a virtual machine may as well be wet rice paper to an alphabet soup agency. you should very much assume that even airgapping isn't enough, unless it's inside of a faraday cage.

xorg security measures are a different matter from stopping any random program from writing to your filesystem. broaden the conversation to be about all security across all attack surfaces under all conditions and nothing is safe. i'm still not gonna run everything as root.

It should also be noted that handling state like that is not really idiomatic Erlang. State is updated at a process level, thus traditionally you spawn another process which is trivial to do. On the BEAM that is fast enough for 95% of cases. If you really need mutation on local variables for performance reasons, you should already be writing NIFs anyways.

State variables are what I think corpos call a "code smell". The BEAM/OTP isn't a number cruncher, there are better tools out there if you're doing a lot of that. Erlang is, at it's core, about constraint logic programming. It should be best thought as a tool for granular, scalable, distributable userspace scheduling. If you need something outside of that, NIFs or Ports. Both are quite nice.

I'm not trolling, but I'm very serious about language design after going through a long gauntlet. I don't think making mutation easy, and also having the ability to hide code execution, is necessarily a good practice in a system principally designed for safe, robust and efficient concurrency. Don't use a flathead on a phillips screw.

No rebinding, better fits the grain of the OTP, no AST macros. Last I checked, the debugging experience with elixir was pretty subpar. Erlang is also a fundamentally nicer syntax that I find a great deal more readable. I'm not really sure what the appeal of Elixir as a language is actually supposed to be, outside of people who have spent a lot of time writing Ruby code.

This is a good post and I agree with it in full, but I just wanted to point out that (safe) Rust is safer from data races than, say, Haskell due to the properties of an affine type system.

Haskell in general is a much safer than Rust thanks to its more robust type system (which also forms the basis of its metaprogramming facilities), monads being much louder than unsafe blocks, etc. But data races and deadlocks are one of the few things Rust has over it. There are some pure functional languages that are dependently typed like Idris, and thus far safer than Rust, but they're in the minority and I've yet to find anybody using them industrially. Also Fortnite's Verse thing? I don't know how pure that language is though.

The naive way wouldn't be any different than what it's like to dynamically load sepples binaries right now.

The real way, and the way befitting the role of the standards committee is actually putting effort into standardizing a way to talk to and understand the interfaces and structure of a C++ binary at load-time. That's exactly what linking is for. It should be the responsibility of the software using the FFI to move it's own code around and adjust it to conform with information provided by the main program as part of the dynamic linking/loading process... which is already what it's doing. You can mitigate a lot of the edge cases by making interaction outside of this standard interface as undefined behavior.

The canonical way to do your example is to get the address of std::string::length() and ask how to appropriately call it (to pass "this, for example.)

Any particular year?

> they're not embedding LLVM - they're embedding clang

They're embedding both, according to the article. But it's also just sloppy semantics on my part; when I say LLVM, I don't make a distinction of the frontend or any other part of it. I'm fully relying on context to include all relevant bits of software being used. In the same way I might use "Windows" to refer to any part of the Windows operating system like dwm.exe, explorer.exe, command.com, ps.exe, etc. LLVM a generic catch-all for me, I don't say "LLI" I say "the LLVM VM", for example. I can't really consider clang to be distinct from that ecosystem, though I know it's a discrete piece of software.

> name mangling is by the easiest part of cpp FFI

And it still requires a lot of work, and increases in effort when you have multiple compilers, and if you're on a tiny code team that's already understaffed, it's not really something you can worry about.

https://en.m.wikiversity.org/wiki/Visual_C%2B%2B_name_mangli...

You're right, writing platform specific code to handle this is more than possible. But it takes manhours that might just be better spent elsewhere. And that's before we get to the part where embedding a C++ compiler is extremely inappropriate when you just want a symbol name and an ABI.

But this is besides the point: The fact that it's not a problem solved by the gargantuan standard is awful. I also consider the ABI to be the exact same issue, that being absolutely awful support of runtime code loading, linking and interoperation. There's also no real reason for it, other than the standards committee being incompetent.

I'm not surprised to see that Jank's solution to this is to embed LLVM into their runtime. I really wish there was a better way to do this.

There are a lot of things I don't like about C++, and close to the top of the list is the lack of standardization for name-mangling, or even a way mangle or de-mangle names at compile-time. Sepples is a royal pain in the ass to target for a dynamic FFI because of that. It would be really nice to have some way to get symbol names and calling semantics as constexpr const char* and not have to deal with generating (or writing) a ton of boilerplate and extern "C" blocks.

It's absolutely possible, but it's not low-hanging fruit so the standards committee will never put it in. Just like they'll never add a standardized equivalent for alloca/VLAs. We're not allowed to have basic, useful things. Only more ways to abuse type deduction. Will C++26 finally give us constexpr dynamic allocations? Will compilers ever actually implement one of the three (3) compile-time reflection standards? Stay tuned to find out!

"Worse is better" is an extremely misleading phrase. It's supposed to be ironic, not sarcastic. Unfortunately, the authors of "Unix Haters Handbook" exercised terrible judgement used it as a sarcastic pejorative. Now nobody understands what anybody is actually saying when they use it. I mean it in the original sense, where it's basically another way to express "Less is more."

SML is borderline minimalist, it's "worse" because it doesn't try to solve everybody's problems with a bunch of ad hoc language features and a stdlib and formalization larger than the entire legal code of the United States. It's "worse" because it comes with "less". You can't just import solution and start writing AbstractFactoryManager2 garbage. It's not actually worse to anybody but beancounters.

> Good enough wins. Worse is better rules. Release early... and so on.

None of that applies to this case, where ML is not only a fair bit older than Java, but abides the principle of "worse is better" far more.

> While scheme, standardml and numerous other perfect little languages are mostly just Wikipedia pages now.

Frankly, I'm thankful I work in an environment with creative autonomy and can choose (and create) my own tools, rather than being forced to work with ones I don't particularly care for because they had a large marketing push.

Edited for accuracy, thanks.

> Most of us still mispronounce some words

The bureaucratization of language is more problematic in my view, where things are seen as wrong and right and we try to cram the beauty of of natural language into a restricted box that can be cleanly and easily defined and worked with universally. I quite literally have nothing but detest for this conception of language, that it must bend to the whims of rigidity when it's very clearly a natural, highly chaotic dynamic system constantly undergoing evolution in unexpected ways.

2nding this. The "non-phonetic alphabet" is the biggest non-issue I see people raise a stink about. It really doesn't matter, context is the heavy-weight backbone of language.

On top of that, I think people really underestimate how inappropriate diacritics would be for English. It has a massive phonemic inventory, with 44 unique items. Compare with Spanish's 24, or German's 25. English's "phonetic" writing system would have to be as complex as a romanized tonal language like Mandarin (which has to account for 46 unique glyphs once you account for 4 tones over 6 vowels + the 22 consonants). Or you know, the absolute mess that is romanization of Afro-Asiatic languages. El 3arabizi daiman byi5ali el siza yid7ako, el Latin bas nizaam kteebe mish la2e2 3a lugha hal2ad m3a2ade.

What are your thoughts on basis[1] and successorml[2]?

[1] - http://www.mlton.org/MLBasis

[2] - https://smlfamily.github.io/successor-ml/

> the treatment of things like equality and arithmetic is hacky in its own way

mlton allows you to use a keyword to get the same facility for function overloading that is used for addition and equality. it's disabled by default for hygienic reasons, function overloading shouldn't be abused.

https://baturin.org/code/mlton-overload/

> labelled arguments

generally speaking if my functions are large enough for this to matter, i'd rather be passing around refs to structures so refactoring is easier.

> polymorphic variants

haven't really missed them.

> GADTs

afaik being able to store functors inside of modules would fix this (and I think sml/nj supports this), but SML's type system is more than capable of expressing virtual machines in a comfortable way with normal ADTs. if i wanted to get that cute with the type system, i'd probably go the whole country mile and reach for idris.

> even the much-maligned object system that have their place

never used it.

> Is there anything SML really brings to the table besides the omission of features like this?

mlton is whole-program optimizing (and very good at it)[1], has a much better FFI[2][3], is much less opinionated as a language, and the parallelism is about 30 years ahead[4]. the most important feature to me is that sml is more comfortable to use over ocaml. being nicer syntactically matters, and that increases in proportion with the amount of code you have to read and write. you dont go hiking in flip flops. as a knock-on effect, that simplicitly in sml ends up with a language that allows for a lot more mechanical sympathy.

all of these things combine for me, as an engineer, to what's fundamentally a more pragmatic language. the french have peculiar taste in programming languages, marseille prolog is also kind of weird. ocaml feels quirky in the same way as a french car, and i don't necessarily want that from a tool.

[1] - http://www.mlton.org/Performance

[2] - http://www.mlton.org/ForeignFunctionInterface

[3] - http://www.mlton.org/MLNLFFIGen

[4] - https://sss.cs.purdue.edu/projects/multiMLton/mML/Documentat...

sml, specifically the MLTon dialect. It's good for all the same reasons ocaml is good, it's just a much better version of the ML-language in my opinion.

I think the only thing that ocaml has that I miss in sml is applicative functors, but in the end that just translates to slightly different module styles.

I'm not sure why we would want to replace mechanical systems. A portable AC unit with 10,000 BTUs uses ~650wh these days, and it'll turn a 50m^2 apartment into an icebox. That's not much more than a flagship GPU pulls. This is also about the least efficient class of aircon you can get.

Sure less energy usage is always better, and if we could get the same out of mere single digit wh power draws that would be cool. But I don't think thermoelectrics are ever going to get us there.

I'm aware of all of this, it might not be clear if you've not used it directly yourself, but unshare(1) is your shell interface to namespaces. You still need to use a chroot if you want the namespace to look like a normal system. Just try it without chrooting:

unshare --mount -- /bin/bash

> It is relatively trivial to break out of chroot jails. In fact it can happen accidentally.

Same is true for namespaces actually.

https://www.helpnetsecurity.com/2025/05/20/containers-namesp...

I know that I've stopped using Google's search primarily because it's been intentionally[1] made a worse tool. The AI overviews sound obnoxious and I'm not surprised if they're driving more people off of the platform.

I don't know what the hell is going on over there, but the systemic issues and awful decisions I see coming out of Alphabet companies in recent years paints a picture of suicidal levels of hubris at the c-suite level. The boards need to pull their heads out of their asses, otherwise incompetence is going to sink that ship before 2040.

[1] - https://jackyan.com/blog/2023/09/google-search-is-worse-by-d...

> Apptainer is for running cli applications in immutable, rootless containers.

What's the appeal of using this over unshare + chroot to a mounted tarball with a tmpfs union mount where needed? Saner default configuration? Saner interface to cgroups?

Engineers like to work from the bottom up because nature isn't made out of straight lines and regularity. Breaking things apart into abstractions works to a certain point, then the natural irregularity of reality steps in and you need to be able to react to that and adjust your foundation. So yes, fundamentally it is about thermodynamic knock-on-effects of handling things from the top-down.

Messing around with lisp and smalltalk environments is fun. But the moment you have to stick your hand beneath the surface, you can very quickly end up in someone else's overengineering hell. Most serious GNU Emacs users shudder at the thought of hitting Doom Emacs with a wrench until it suits their tastes. It's universally agreed that building your Emacs environment up from the defaults is fundamentally a wiser choice. Now realize that a full Lisp operating system is several orders of magnitude more complex than Doom Emacs, and most things you're going to program emacs to do are absolutely trivial in comparison to most industrial-grade application logic.

> Actually, the people who are "overly attached to code" tend to be computer scientists who are deeply interested in computation and its expression.

What academics are you rubbing shoulders with? Every single computer scientist I have ever met has projects where every increment in the major version goes like:

"I was really happy with my experimental kernel, but then I thought it might be nice to have hotpatching, so I abandoned the old codebase and started over from scratch."

The more novel and cutting edge the work you do is, the more harmful legacy code becomes.

> That's simply a reality, just as weavers saw massive layoffs in the wake of the automated loom, or scribes lost work after the printing press, or human calculators became pointless after high-precision calculators became commonplace.

See, this is the kind of conception of a programmer I find completely befuddling. Programming isn't like those jobs at all. There's a reason people who are overly attached to code and see their job as "writing code" are pejoratively called "code monkeys." Did CAD kill the engineer? No. It didn't. The idea is ridiculous.

> but it had set! for just as long.

Purity has nothing to do with functional programming.

> It is also not a list based language, but a tree based one.

It's not called Trep, it's called Lisp. Yes, you can represent trees as lists embedded in lists, and the cons cell allows that thanks to type recursion. But it's still based around lists. Trees don't allow cycles, lists formed from ordered pairs do. Every single piece of literature written by McCarthy talks about lists[1].

> The fundamental point of lisps is that you can manipulate the abstract syntax tree directly

Macros weren't introduced until 1963[2]. They might be the reason you use a Lisp, and they may have become synonymous with Lisp after 1.5, but they are not a "fundamental point" of Lisp. The fundamental point was always about lambda calculus[1].

[1] - https://history.siam.org/sup/Fox_1960_LISP.pdf

[2] - http://bitsavers.informatik.uni-stuttgart.de/pdf/mit/ai/aim/...

Datalog is simpler, not turing complete , and IIRC uses forward chaining which has knock-on effects in its performance and memory characteristics. Huge search spaces that a trivial in Prolog are impossible to represent in Datalog because it eats too much memory.

Datalog is a commuter car with a CVT. Prolog is an F1 car. Basically, it's not about improvement. It's about lobotomizing Prolog into something people won't blow their legs off with. Something that's also much easier to implement and embed in another application (though Prologs can be very easy to embed.)

If you're used to Prolog, you'll mostly just find Datalog to be claustrophobic. No call/3? No term/goal expansion? Datalog is basically designed to pull out the LCD featureset of Prolog for use as an interactive database search.

> Prolog has relatively poor performance, whereas Datalog dramatically improves performance

It's easier to write fast Datalog code but the ceiling is also way lower. Prolog can be written in a way to allow for concurrency, but that's an intermediate level task that requires understanding of your implementation. Guarded Horn Clauses and their derived languages[2] were developed to formalize some of that, but Japanese advancements over Prolog are extremely esoteric. Prolog performance really depends on the programmer and the implementation being used and where it's being used. Prolog, like a Lisp, can be used to generate native machine code from a DSL at compile-time.

If you know an understand how the underlying implementation of your Prolog works, and how to write code with the grain of your implementation, it's absolutely "fast enough". Unfortunately, that requires years of writing Prolog code with a single implementation. There's a lot of work on optimizing[3][4] prolog compilers out there, as well as some proprietary examples[5]. But even something like SWIPL[6] is absolutely fast enough to use (and it has a cute (nameless?) mascot :3) SWIPL is easy to embed, actually disturbingly easy. I don't know if SICSTUS is, or how well it copes with dynamic updates to the knowledge base.

[1] - http://logicprogramming.stanford.edu/readings/ullman.pdf

[2] - https://www.ueda.info.waseda.ac.jp/AITEC_ICOT_ARCHIVES/ICOT/...

[3] - https://www.sciencedirect.com/science/article/pii/S074310669...

[4] - https://link.springer.com/content/pdf/10.1007/3-540-18024-9_...

[5] - https://sicstus.sics.se/

[6] - https://www.swi-prolog.org/

Is light slow? Or is the human perception of time just scaled down as a result of our rapid metabolism and infinitesimality? People historically mistake plants for being inanimate things with no reactivity, that they are far more simple and stupid than they truly are. Outside of a few exotic examples, plants simply operate on a wider timescale that's basically imperceptible without careful and particular observation. It becomes much more apparent how alive plants are when we observe them in a time-lapse. Now realize that plants are still relatively short-lived. The absolute oldest ones only go back to the early neolithic, that's only 14000 years or so. 1000 years is a long time for humans, but probably not for the trees where a single one can live 10x that.

From the hypothetical perspective of a star, with a lifespan measured in billions upon billions of years, the entire ecoscape of the world changes in a blink. From the sun's perspective, MENA was green just a very short while ago. Hell, Pangea wasn't that long ago. At this timescale, continental drift would be as apparent as the movement of boats are to humans. Anything that's working at the cosmic scale where the seemingly low speed of light sounds exhausting is most definitely working at this stellar perspective at the minimum. 14000 years of travel might as well be the equivalent of a 10 minute commute to the store.

Philosophically speaking, of course.