But it doesn't take too many cash purchases that are not inline with your tax returns before somebody is going to start snooping around.

edit: although sometimes, a lot longer than one might expect.

Maybe you should take a step back and realize that sofware developers themselves are not the primary purchasers of most software. The average joe or jane purchaser doesn't have some magical AI slop detector, especially if the UI is well done.

Even if all signs point to impending doom, at the end of the day if people are still buying, stocks will hold their value.

Everyone has what they like and what they’re familiar with, and for better or worse, especially for startups it’s rarely .net. But I couldn’t imagine e.g. using js instead on the back end, but that’s just me.

The blurb toward the end about Rent/return makes me a bit nervous though. They say they’re not going full borrow checker, but rent at least sounds an awful lot like borrow to me. Details were basically non-existent though.

I guess I wonder what the end game is here though. The more they make C# like Rust with a GC, the less incentive people have to use C# except maybe to support legacy work. I am still far more comfortable in C# than Rust, and I believe C# is superior for e.g. web, but over time this advantage could be lessened quite a bit as the Rust ecosystem continues to grow.

When I vibe, it's C# all the way. Not a popular opinion on HN, but the LLMs are trained heavily on the language and are very, very good at it, plus with the 1-file-per-class organization, it can stay pretty clean. I mean, v10 LTS was just released, with all kinds of new language features, EFCore is still the best ORM I've ever used, with full support for SQLite, Postgres, MySql, etc. It just makes writing and reviewing code a pleasure. And the LLMs don't f*ck it up.

I ported around 20 RNGs to C# (all non-cs), and there are tons of uses for non-cryptographic RNGs, so I'm a little torn. I guess in modern development most people who need an RNG need it for crypto purposes (I would guess salts, keys and nonces mostly), but I'd hate to see all the Xoshiros, Mersenne Twisters, PCGs, and MWCs, etc. go the way of the dodo simply because they are not deemed fit for crypto purposes. Games, simulations, non-cryptographic hashes all need deterministic and high performance RNGs, and don't need all of the cryptographic guarantees.

To top it off, there is no standard definition of what makes an RNG cryptographically secure, so it's a slightly loaded question anyway. Everything I've read says an algo needs the following properties: forward secrecy (unable to guess future outputs given the current state), backward secrecy (if I know current outputs, I shouldn't be able to recover previous internal state or previous outputs), and the output must be indistinguishable from true random bits, even with a chosen-input attack. This is where I politely defer to the expert mathematicians and cryptographers, because I'm not equipped to perform such an analysis.

I can understand why things have developed this way though- people have needed random numbers far longer than they've needed cryptographically secure random numbers, so the default is the non-cryptographically secure variant. A language created tomorrow would likely follow in Go's footsteps and default to the cryptographically secure.