yosefk

Fair enough but Rust also gives you a mix of safety and efficiency nothing else does

Zig dumps core and Go is slower and needs more memory though, and this matters, too. (not that Rust build times are really a price to pay for avoiding these things, it's more a result of not making fast builds a goal from the start)

...because your work projects are bigger, there's only so big a black box can get before you lose all comprehension of it, and splitting it to smaller black boxes the shapes of which you keep refining is programming, and the part of it LLMs currently can't do

No, the argument is that it's less appealing to leadership even when it's the better outcome, but not vice versa - it might or might not be better for reasons unrelated to said appeal ("standardizing on something across the company vs having everyone roll their own variant is a hard decision to make.")

And of course you can also end up standardizing on something because it benefits someone good at politics even though it's a bad idea, I just didn't elaborate on this stuff because it is too far away from the subject. I didn't say you should always stanardize on something though, I said that it was a hard decision

TFA author - I very much agree, don't do this for free

Ah, I call this the defense-dominant workplace. Not a fun situation to be in!

Well, they are 2 different failure modes. You have people dumping their work on someone all too willing (I even know productive people who just like helping way more than doing their own work and then complain that they have no time for said work, not as easy to manage as it sounds), and you also have teams which mostly refuse to do anything from anyone. You can tell a "workplace shark" from a more vegetarian workplace animal by whether they credit people for their work.

What are you disagreeing with in TFA though? I agree with your points, I just think there are counterpoints and this needs to be decided on a case by case basis

Right, but that's more a lack of reward than outright punishment. If you work with these people on something that "crosses boundaries" and that something succeeds, you can credit them and in the hope to help their career. I agree that larger places are worse in this regard (though there can be a small part of a large place which is, well, small enough to work like a small one), and that you should generally make sure you're rewarded for your work, and if you're not, either work less or work elsewhere.

Uber reported that their Go code has quantitatively more concurrency bugs than code in other languages, and while to me it seems obvious from looking at Go's concurrency model, this is backed by actual data. Is there any quantitative data to back the claim that Go is better in an LLM based workflow than another popular language?

Bush knew what he was doing - Hamas has the influence it has because the US wants it to have it. When Trump decided he wants them to release Israeli hostages he forced them to do it rather quickly, all things considered, showing who really controls Hamas. Restraining American "allies" is key to how America understands its interests and Hamas is an excellent lever to pressure Israel, or Hamas-controlled Gaza wouldn't be flooded with American and European money.

Similarly, Obama supported the Muslim Brotherhood because he did; in Ukraine for instance the same admin supported a coup against the elected government (this is not to say that Russia's actions in Ukraine are "justified", it's just a fact.) Democracy has nothing to do with any of this

Currently these models have a limited context window, so the value of a session is not that high, at any rate at some point the model will have forgotten things. If in the future the model will truly learn / "change" as a result of the interaction, in any case this will be non portable to another model. So I think this is kinda moot

I'm able to see how it's safer than Rust but what I like is that it works with existing C++ code; I don't think the extra safety relative to Rust is worth the performance penalty (not to mention needing to recompile every dependency) and I doubt you think that, either

I think Fil-C is awesome and I very much like the style in which you present your work as well. (Hope I'm not being too emotional here!)

FWIW, I can see where TFA is coming from and I had the urge to write something "in defense of Rust" after listening to / reading some of your recent comments. I think your sister comment about the limits to Rust memory safety being real as much as the limits to Fil-C's performance and practicality is spot on, but the feeling (those emotions again) one gets from much of your commentary is that you downplay the latter quite a bit.

I think the real argument for Fil-C is that you aren't going to "rewrite in Rust" but you can often realistically recompile in Fil-C and pay the performance penalty; the fact that that Rust rewrite could also end up less safe is I think should be argued mainly from the AI angle where the only practical way is an LLM based rewrite but that would have a load of unsafe - way more than a "proper" rewrite - to be practical and the recent $100K Bun rewrite is a testament to that.

(I would love nothing more than for Fil-C to become as widely used as it practically can, since no other approach does nearly as much to secure C / C++ code and a lot of said code is out there; and security aside, it could prevent a lot of data corruption that most major C++ programs gift to their users.)