- notnullorvoidTo be clear only the path and query parameters part of the url can change, the domain (or sub domain) stays intact.
- By they looks of it their docs are under a subdomain, and no part of the domain can be changed when setting the url this way. So it would still look a little out of place at least.
- `history.replaceState(null, "", "/login")`
- This specific XSS vulnerability may not have been, but the linked RCE vulnerability found by their friend https://kibty.town/blog/mintlify/ certainly would've been worth more than the $5,000 they were awarded.
A vulnerability like that (or even a slightly worse XSS that allowed serving js instead of only svg) could've let them register service workers to all visiting users giving future XSS ability at any time, even after the original RCE and XSS were patched.
- In general if a script can run, users sessions and more importantly passwords are at risk.
It's true that an HTTP-only session cookie couldn't be directly taken, but it's trivial to present the user with a login screen and collect their password (and OTP), at which point you can easily get a session remotely. It can look entirely like the regular login page right down to the url path (because the script can modify that without causing a page load).
- I had to go check to see what their pricing was, and I couldn't believe it. The base tier was $4/month, now that tier is gone and the premium tier is 2x what it used to be only 5 years ago.
- I was under the impression that the security concerns there are handled by AppArmor and SELinux (though maybe not granular access control to secrets). Which all desktop Linux installs should be using one or the other, because there's much more than just D-Bus that can be a security risk.
- Transpilers: SWC, Oxc Linters/Formatters: DPrint, deno lint, Biome, Oxlint, Oxfmt Bundlers: Rolldown (replacing esbuild in Vite), Rspack, Turbopack, and certain components of Parcel
All built with Rust
- Sure, and Rust is the most used language for modern TS/JS tooling, outside of TS/JS. There would have been substantial ecosystem benefits had Rust been chosen.
- > If memory management and ability to handle complex graph processing efficiently isn't related to architecture to you I don't know what to tell you.
Rust can do complex graph processing, as well as efficient easy memory management, but it's going to do it in a different structure than a GCed lang would. Hence my statement that 1 to 1 translation was the primary factor.
> CTRL+F "rust" on the Go issue and see how many results you get.
Yes and so what? There's 35 for .NET or 74 for C#, yet you don't see people claiming the C# cult was harassing the TS team.
- TS decision to choose Go was primarily, because they could take the existing code and do a near 1-1 translation. You can frame that as an architectural concern, but it's really only one that applies when your attempting to migrate an existing program to a new language. The Go rewrite has some negative outcomes as well, most concerning is the performance of the WASM builds is worse than the old JS/TS version.
A TS compiler from scratch built in Rust would be fine.
> cultists
The cult is in your imagination.
- Success isn't a binary thing. It's true that Servo has long struggled to make progress, and that can be seen as a failure. It's recent progress can also be seen as a success.
Your life might improve if you stop believing that Rust devs belong to a cult of your own imagination.
- Excessive social media is detrimental (to everyone). Age restrictions are not a good solution, it effectively categorises it as an adult activity, and glorifies it further.
Kids are very good at identifying hypocritical behaviour and scare tactics. It'll end up counterproductive like the D.A.R.E. program.
If the kids are forced out, the adults should be too.
- It was a big mistake to leave Jony Ive in charge of design after Steve Jobs left. Jobs had a good design sense that was key to grounding Ive's work.
Ive's vision of Apple as a luxury brand certainly aligned with Cook's focus on profit, and the results of that sadly still echo through the company today.
- Wouldn't the implication of them being "opposite" be that in some sense they are mutually exclusive? I don't really see evidence of that. Your example of sensory input vs world model weight is a bit flawed, because both of those are extremely multifaceted. One can have extreme weight in sensory input in one sense but not others, as well as extreme weight on world model for certain aspects of life.
- You can use RC liberally to avoid thinking about memory though. The only memory problem to think about then is circular refs, which GC languages also don't fully avoid.
- It's not a perfect analogy, but none of my comments are directed at the use of JS for a game, it's a fine choice. It's the use of Next.js that's the issue, it's a framework for server side rendering of HTML. It serves no benefit if your goal is to make a 3D game, it only adds overhead. If he had not been using it he would have realised there's a few bundlers out there that are far better than what Next.js dev server provided at the time.
- Yes, but there are obvious limits to that. This is like someone who knows how to bake wanting to build a car, so they start making it out of dough.
- I am more shocked about the origin story compared to the acquisition.
> Almost five years ago, I was building a Minecraft-y voxel game in the browser. The codebase got kind of large, and the iteration cycle time took 45 seconds to test if changes worked. Most of that time was spent waiting for the Next.js dev server to hot reload.
Why in the hell would anyone be using Next.js to make a 3D game... Jarred has always seemed pretty smart, but this makes no sense. He could've saved so much time and avoided building a whole new runtime by simply not using the completely wrong tool for the job.
- Bun and Deno's goals seem quite different, I don't expect that to change. Bun is a one stop shop with an ever increasing number of built-in high-level APIs. Deno is focused on low level APIs, security, and building out a standard lib/ecosystem that (mostly) supports all JS environments.
People who like Bun for what it is are probably still going to, and same goes for Deno.
That being said I don't see how Anthropic is really adding long term stability to Bun.