> We want to help people in the EU, but with laws like replaceable batteries, it's going to push us further and further away from being able to do that.
We want to help people, but only if and when it’s profitable for us to do so on terms we decide for you.
Incredibly corrupt sports organisation awards incredibly corrupt politician the peace prize. Something neither party have any concept of, nor seem to understand the definition of.
I feel for the South Park creators because boy do you have a challenge coming up with absurdity this season.
The title is interesting but the article lacks a lot of background information. There’s no explanation of what the CPU-bound endpoints are, what causes them to be CPU-bound etc. They mention they didn’t think optimising the Go code would’ve given them enough, but there’s nothing to substantiate it and no way for the reader to form their own opinion since we’re never told what the problem is other than “doesn’t scale.”
I have no issue with Rust, there’s nothing wrong with what they did, they approached it sensibly and the results are certainly compelling. But it reads a lot like “we wanted to write something in Rust” and found a reason to do so.
File name doesn’t necessarily include the whole path. The last 16 characters of CHANGELOG.md is the full file name.
If we interpret it that way, that also explains why the filepathwalk solution solves the problem.
But if it’s really based on the last 16 characters of just the file name, not the whole path, then it feels like this problem should be a lot more common. At least in monorepos.
I’ve been very happy and impressed with the Framework AMD edition. I’d steer clear of their Core Ultra Intel edition since that’s Meteor Lake. I use mine for open source development things I do on my own time.
If work supplied me with one of them I’d happily use it. Support has been great and they live up to their upgradable promise.
For a widely deployed example, take a look at how JSON-LD uses IRIs for keys and how the context object plays into that. The whole fediverse is built on top of it.
This story is bogus. The vulnerability lives in a demo app that’s disabled by default. Enabling that app would require the attacker to have physical access to the device and your passcode.
The WASM solution doesn’t rely on a custom libc or transpiler to convert C code to Go. The transpile is an amazing feat of engineering, but it’s hard to debug.
I can wrap my head around the small amount of wrapping the go-sqlite3 WASM library does. If I had to I can maintain that should the maintainer lose interest. I can’t say the same for the modernc transpile. You can also apply the WASM trick to other libraries with much less effort.
And as noted, it seems to be performing better. As the wasm runtime improves it should pull further ahead.
We want to help people, but only if and when it’s profitable for us to do so on terms we decide for you.