Some great stuff in this release. I contributed some rendering code, most notably reducing the renderer to O(number of changed entities) on the CPU, that went unmentioned in the release notes.
I do have to say, however, that BSN syntax isn't good and is getting worse. There are too many sigils, and -- to separate list elements (!) is an indication that it's been designed into a corner. The fact that it's not LR(1) should have been an indication that it was misdesigned. The scene format should be redesigned to be editor-first, with ease of VCS merging as a paramount consideration.
I was curious how the design was arrived at and found some of the trade-offs discussed in this issue[0]. I personally liked the idea of using a combination of semicolons and commas to separate entities and components; but oh well, I guess we'll get used to the double-dash.
I love the work you are doing in Bevy. I often filter the PR list based on your handle just to see what big graphics/performance work you are cooking up.
I unfortunately do agree with you on the BSN syntax, I guess it's a matter of tradeoffs, but I don't think backward breaking changes are off the table for the foreseeable future, so curious what can be done to improve the syntax in the next couple of releases.
Although what I really look forward to is auto-formatting of the syntax, I care about the feel and look of the syntax, but I care even more about consistency across my code base.
It's not that dissimilar to how Dioxus does this kind of thing with rsx! but yeah, it first got released in 0.19 and got big improvements in this release. It'll be interesting to see how uptake and adoption goes.
Dioxus is much easier to understand though, and Leptos and Yew are just HTML. One of the core issues is that (a) a scene format for editors, (b) a SwiftUI-like DSL for UI, and (c) a DSL for spawning game objects are just different problems. A single syntax that tries to cover all three ends up being a compromise that satisfies few.
> From all state actions I’ve seen for a decade straight in the crypto space, this largely seems to be an education issue that makes the state’s ability to prosecute a brief privilege
Or, you know, they could come up to you in a San Francisco public library while your computer is unlocked and logged into your account, slap handcuffs on you, and image the contents of the laptop's RAM, establishing proof beyond a reasonable doubt that you had access to the Monero account in question. Just like they did with Ross Ulbricht.
If there's anything you should learn from the history of state actions in this space, it's that the USG is very good at overturning naive assumptions about the real-world anonymity of these technologies.
What happened in 2013 has nothing to do with the time frame I mentioned, 2016 through 2026. The infrastructure is different now to the point that government's don't even try stunts like that and darknet markets are larger than ever - practically immediately since the takedown of Silk Road and onwards. Ross' plight was an instruction manual of both what not to do, and to implement what everyone already knew to do but was to lazy to in the face of only theoretical threats at the time. The government moved once and the whole ecosystem hardened.
Your recount of events is hyperbolic for emphasis about naive assumptions - attempted to rehash an XKCD comic strip - yet is a wholly unrelated attack surface. The imaging of Ross' laptop did not prove everything about the case, it did not prove ownership of some servers, and Ross was not using Monero which as several US court cases in the time frame I mentioned, specifically, for a reason, have shown, the US government has no access to Monero it believes it has seized in those cases. Doesn't even know the balances or whether its still there.
What you wrote isn't even a counterpoint to the concept of having basic privacy. This isn't a how to on how to deter the government, it deters everyone. If you're doing something that needs to involve the intelligence community, then do more or don't do it at all. But the gradient of actors from people that can't subpoena you, to ones that could but get nothing from said power, are all things to consider.
> Apple seems to have lost its academic roots, and suffers for it now. Or I should say, its customers suffer while it grosses almost half a trillion dollars per year. At least with vibe coding we can just whip up a Preview app in an afternoon, so maybe none of this matters anymore.
Eh, I'm with Apple on this one: we can just use Ghostscript. Apple's move effectively forces the few applications that need to use PostScript on macOS to migrate from a proprietary PostScript implementation to an OSS one, which strikes me as ultimately a good thing.
You can run arbitrary computations on iOS devices if they're written in JavaScript, WebAssembly, or Swift (via Playgrounds). All of these are Turing complete, and all three compile into machine code. What you don't have without an Apple developer account is direct machine code access.
Also note that apps like Pythonista allow you to write programs that call arbitrary Objective-C APIs without permission from Apple. This means that you have a Turing-complete language running unsigned code that can do anything a signed app can do. Your programs do, however, execute slowly.
Sure, but the relevant comparison isn't between languages: it's between a state-of-the-art JIT implementation of one language and a likewise-state-of-the-art AOT implementation of the same language. Unfortunately there aren't many examples of this; most languages have a preferred implementation strategy that receives much more effort than the other one.
Mathematically, what you want to do here is to calculate the area of the pixel square (or circle; however you want to approximate it) that the shape covers. In this case a linear ramp actually approximates the true value better than smoothstep does. (I had the derivation worked out at some point; I don't have it handy, unfortunately.) Of course, beauty is in the eye of the beholder, and aesthetically one might prefer smoothstep.
By the way, since the article mentions ellipse distance approximations, the fastest way to approximate distance to an ellipse is to use a trick I came up with based on a paper from 1994 [1]: https://github.com/servo/webrender/blob/c4bd5b47d8f5cd684334... Unless it's changed recently, this is what Firefox uses for border radius.
Your note taking app doesn't need AI, but it also doesn't need OLE, which represented an equally hot buzzword ("software componentry") of the 90s that Microsoft was trying to shoehorn into everything.
Every generation has its hype cycle; it's nothing new.
My recollection is that Brian Anderson, who came from the C# world, was an early advocate of the easily-googlable error codes that Microsoft compilers use a lot, and pushed to get them in. That was a good call. (In general Brian had a lot of behind-the-scenes positive influence on Rust: my favorite brson-ism is "if the code doesn't have a test it doesn't exist".)
Yeah this PR cites it as explicitly a continuation of Bryan’s work. I never did any implementation work on errors, I was just a big fan of the codes concept.
I do have to say, however, that BSN syntax isn't good and is getting worse. There are too many sigils, and -- to separate list elements (!) is an indication that it's been designed into a corner. The fact that it's not LR(1) should have been an indication that it was misdesigned. The scene format should be redesigned to be editor-first, with ease of VCS merging as a paramount consideration.
reply