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.)

Rhetoric is empty. Always.

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.

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.

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.

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 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.)

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.

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!

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.

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.

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.

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. 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.

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

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

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...

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.