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?

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.