I mean, I’ve seen a growing number of companies looking for Salesforce; it’s even worse (all of your code only works on their platform because it’s a proprietary language AND they charge for things as absurd as how many lines of code you have).

A lot of the things that you can’t do with serverless expressed in this article are not things you want to do on a web server anyways. Like writing a temporary file, sharing state in process between requests, or spawning a thread.

Sure for a truly small workload where you don’t have to worry about abuse and scaling beyond one machine you can get away with that stuff. However, for companies that do need to be able to deal with multiple machine workloads and don’t want to worry about hiring a team of engineers to implement a scalable cloud or run their own physical hardware in a data center … I think serverless likely has some value.

Hmmm… Working fine for me on a Pixel 9 Pro

🤦‍♂️

I honestly suspect antitrust is the reason Google hasn’t laid more fiber (not that antitrust is bad). They’re dangerously close to being broken up for so many other things adding this would be a very high risk gambit. Especially because ISPs are known for their shitty business practices and leveraging lawyers to maximum pain on any legitimate competition that threatens them.

And games are more expensive than ever for studios to make and push to the market. Given that, I’m not surprised we have loot crates, micro transactions, and predatory dlc. A AAA game should have a baseline price closer to $200.

Yeah … then there are people the won’t buy games for more than $20 (not necessarily because they can’t afford it but because “it’s just a game”) … which is just kinda crazy to me (and disrespectful to the amount of work that went into the game).

Both can be bad.

It’s about content delivery, i.e. the CCP having direct control over what content (i.e. propaganda) is sent to Americans on the platform via their proprietary algorithm (with all the source code heavily guarded in mainland China).

Nice! Thanks for sharing

But there is no such implementation AFAIK? How is it making Typescript faster if it’s a completely new implementation?

Well a new implementation running TypeScript could be 10x faster than the traditional e.g., NodeJS implementation or something; it’s not unusual for things to be compared in such a way.

But certainly, in theory it could become unshackled from JavaScript. Have there been any serious attempts to do so though?

No idea! :)

I… Don’t know about that. I mean, you could implement a browser or even a runtime library that used typescript (or a subset thereof) to directly write LLVM; it would take a lot of work, but typescript doesn’t have to just be for transpiling.

On some level yes, but reading the article nothing persist between boots. This seems like a vulnerability that’s really only that serious A if you don’t apply AMDs patched micro code and B there’s another vulnerability on your system that lets this persist between operating system reinstall/in the BIOS.

Yeah, second hand opinions can be a thing and it’s the main reason I still argue online … but gosh can it be exhausting arguing with a wall.

I’ve always had this opinion… I never got the hype…

Ugh yeah that’s been an increasing problem too. I had some guy last year just as dusk was starting to set with a bike headlight blinding me on the bike trail.

100% this; I’ll see the same make a model go by, with LED lights, and it will be fine one time the next time I’ll be like 🔥 MY EYES 🔥.

Interesting, thanks for the tip!

Looks like an interesting service, but expensive

But they are not the default option. And your new job may not use them.

Who cares if it’s the default? If it’s the best tool, use it.

It’s silly to have a reason for “going Rust” be the build system, especially in the context of something as new as a WASM context where basically any project is going to be green field or green field adjacent.

Exceptions is a non standard exit point. And by “non standard” I’m not talking about the language but about its surprise appearance not specified in the prototype. Calling double foo(); you don’t know if you should try/catch it, against which exceptions, is it an internal function that may throw 10 level deep ?

And that’s a feature not a bug; it gets incredibly tedious to unwrap or forward manually at every level.

By contrast fn foo() -> Result<f64, Error> in rRst tell you the function may fail. You can inspect the error type if you want to handle it. But the true power of Result in Rust (and Option) is that you have a lot of ergonomic ways to handle the bad case and you are forced to plan for it so you cannot use a bad value thinking it’s good:

You can do this in C++ https://en.cppreference.com/w/cpp/utility/expected (and as I said, if you feel so inclined, turn off exceptions entirely); it’s just not the “usual” way of doing things.

I use Kopia to B2, then on a monthly basis I copy the current Kopia repo to an external drive that’s otherwise kept offline in my house.

I mean, maybe it’s not easy because they don’t provide debug information, but a sufficiently motivated person can debug a web assembly binary.