pcwalton

> 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.

> 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.

I believe HotSpot is usually faster than GCJ.

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.

[1]: http://mesh.brown.edu/taubin/pdfs/Taubin-tog94.pdf

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.

jcranmer is correct and pointer provenance-related issues are not "boxed and contained". Start here: https://www.ralfj.de/blog/2020/12/14/provenance.html

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".)

When I was first developing early versions of rustc I was really fascinated with Clang's effort at good error messages, which was helping it gain traction vs. GCC at the time, and I tried to start the Rust compiler project off on the right foot. I'm really glad that the Rust compiler dev community has continued to value great error messages: they're the UX of a compiler, and are every bit as important as UX of any other app.

The modal urbanist who lives in the suburbs is usually just someone who wants to be able to have the lifestyle they want without a commute to work. Someone who works at Google in Mountain View but would prefer not to have to drive everywhere, for example. Or, in your example, someone who works at the Pentagon but doesn't want to have to commute from Maryland (or D.C.) in order to live in a walkable area.

But urbanists do live in cities? San Francisco proper is, like, the origin of the YIMBY movement. Searching for "baltimore yimby" on Google brings up a lot of advocacy, like this: https://www.thebaltimorebanner.com/community/housing/baltimo...

Yes, all Rust papers anyone tried to submit were consistently rejected up until Rust became popular, at which point Rust became the hot new thing in applied programming language research. Academic PL is very insular (to its detriment, I'm convinced).

You can raise the cost of cheating so that cheating kids will get annoyed and go cheat in some other game or scroll TikTok or whatever. We're not exactly dealing with nation-states here.

Yeah, sorry, my mistake. GitHub did report on the SO survey [1], which probably led to my mixup.

Anyway, Rust was still the "most admired" language in 2024 [2].

[1]: https://github.blog/developer-skills/programming-languages-a...

[2]: https://survey.stackoverflow.co/2024/technology#admired-and-...

Yes, you have correctly pointed out that there are some developers who are unhappy with Rust.

I don't really care to have an argument as to whether "Rust has peaked" or not. Rust is the same language now as it was in 2023, and 2022, and 2021, etc., and developers liked it then. That's all.

I'm happy to revise what I said from "Rust keeps winning" to "Rust continually won" if you want to nitpick my choice of verb tenses. It refutes the idea that the "developer joy is pretty low" either way.

Because "else" technically includes "comptime_float", so that case is handled, just not in the way that's expected.

One of the downsides of comptime over generics is that, because it's low-level and procedural instead of high-level and declarative, things like automatically inserting coercions become harder.

> Rust is still popular but it turns out the developer joy is pretty low.

I mean, Rust keeps winning the "most loved" language contest on GitHub, so it seems someone likes it.

This is a good point. Zig is practically optimized for this: comptime is extremely dynamically typed compared to actual generics, and the lack of memory safety is often "a breath of fresh air"--until you have to actually fix bugs (including security bugs) resulting from it.

> It's not a great hobby language but it is a fantastic professional language,

I never thought I'd live to see the day when someone would say this. The first 5 years of Rust were all "this is interesting for hobby projects but nobody will ever adopt this in industry".

If Microsoft had adopted this attitude, then by now Excel's market share would probably be 0% and Google Sheets' would be 100%. Microsoft doesn't add features because they like bloated software; they add features because the market demands them, and the market demanded support for more than 65,535 rows.

Over the past year I've been working at my studio to add enough features to Bevy to ship real apps, and Bevy is at the point where one can reasonably do that, depending on your needs.

> You can't do possibly-erroneous pointer math on a C# object reference.

Bevy entity IDs are opaque and you have to try really hard to do arithmetic on them. You can technically do math on instance IDs in Unity too; you might say "well, nobody does that", which is my point exactly.

> You don't need to deal with the game life cycle AND the memory life cycle with a GC.

I don't know what this means. The memory for a `GameObject` is freed once you call `Destroy`, which is also how you despawn an object. That's managing the memory lifecycle.

> In Unity they free the native memory when a game object calls Destroy() but the C# data is handled by the GC. Same with any plain C# objects.

Is there a use for storing data on a dead `GameObject`? I've never had any reason to do so. In any case, if you really wanted to do that in Bevy you could always use an `EntityHashMap`.

Thankfully my studio has given me time to be able to submit a lot of upstream code to Bevy. I do agree that there's a bootstrapping problem here and I'm glad that I'm in a situation where I can help out. I'm not the only one; there are a handful of startups and small studios that are doing the same.

I just don't, and even less often with game logic which tends to be rather simple in terms of the data structures needed. In my experience, the ownership and borrowing rules are in no way an impediment to game development. That doesn't invalidate your experience, of course, but it doesn't match mine.

> No Tiny Glade doesn’t count.

> And if you look at Steam there are simply zero Rust made games in the top 2000. Zero. None nada zilch.

Well, sure, if you arbitrarily exclude the popular game written in Rust, then of course there are no popular games written in Rust :)

> And maybe not Switch although I’m less certain.

I have talked to Nintendo SDK engineers about this and been told Rust is fine. It's not an official part of their toolchain, but if you can make Rust work they don't care.

> I really don’t think Rust is a good match for game dev. Both because of the borrow checker which requires a lot of handles instead of pointers and because compile times are just not great.

I completely disagree, having been doing game dev in Rust for well over a year at this point. I've been extremely productive in Bevy, because of the ECS. And Unity compile times are pretty much just as bad (it's true, if you actually measure how long that dreaded "Reloading Domain" screen takes).

> More than anything else, this sounds like a good lesson in why commercial game engines have taken over most of game dev. There are so many things you have to do to make a game, but they're mostly quite common and have lots of off-the-shelf solutions.

> That is, any sufficiently mature indie game project will end up implementing an informally specified, ad hoc, bug-ridden implementation of Unity (... or just use the informally specified, ad hoc and bug-ridden game engine called "Unity")

But using Bevy isn't writing your own game engine. Bevy is 400k lines of code that does quite a lot. Using Bevy right now is more like taking a game engine and filling in some missing bits. While this is significantly more effort than using Unity, it's an order of magnitude less work than writing your own game engine from scratch.