panstromek

I will join the others and say you should just leave twitter: https://yoyo-code.com/you-should-delete-twitter/

That makes sense, because JWT is base64 encoded, and those base64 tokens are bigger and more expensive. JWT has 3 parts, so it's 3x more expensive, obviously.

Also, the game is much faster on desktop, looks like it's maybe not framerate independent?

The game is pretty fun. Page height is a bit wrong on mobile, you probably need some dvh height?

Depends on how many JSON tokens you need to format. I recommend getting JSON ForMAX+ with 200k tokens and 100k sign in bonus.

Actually, from the OP, the timeline is:

> March 31, 00:21 UTC: axios@1.14.1 published with plain-crypto-js@4.2.1 injected

> March 31, around 01:00 UTC: axios@0.30.4 published with the same payload

> March 31, around 01:00 UTC: first external detections

> March 31, around 01:00 UTC: community members file issues reporting the compromise. The attacker deletes them using the compromised account.

So it was found out almost immediately.

Well, the hack didn't survive more than 2-3 hours if I'm not mistaken. I don't think that counts as "nobody acted on it."

As far as I understood it, it only talks about electricity, so that doesn't seem like a contradiction to me. I think some electrification of heating is expected in 2030, but not that much bigger than it is now.

The parent comments references real world data from Google: https://security.googleblog.com/2024/09/eliminating-memory-s...

The talk "Black-Hat LLMs" just came out a few days ago:

https://www.youtube.com/watch?v=1sd26pWhfmg

Looks like LLMs are getting good at finding and exploiting these.

Yea, passing `-movflags +faststart` to ffmpeg when processing the file should be enough.

If you don't need to switch versions at runtime (ABR), you don't even need to chunk it manully. Your server has to support range requests and then the browser does the reasonable thing automatically.

The simplest option is to use some basic object storage service and it'll usually work well out of the box (I use DO Spaces with built-in CDN, that's basically it).

That's good and arguably the right default for most websites.

Yea, honestly you probably just don't understand. FE frameworks solve a specific problem and they don't make sense unless you understand that problem. That TSoding video is a prime example of that - it chooses a trivial instance of that problem and then acts like the whole problem space is trivial.

To be fair, React is especially wasteful way to solve that problem. If you want to look at the state od the art, something like Solid makes a lot more sense.

It's much easier to appreciate that problem if you actually try to build complex interactive UI with vanilla JS (or something like jQuery). Once you have complex state dependency graph and DOM state to preserve between rerenders, it becomes pretty clear.

> Most integration tests are not thread safe and make assumptions about running against an empty database. Which if you think about it, is exactly how no user except your first user will ever use your system.

Yea, cypress has this in their anti-patterns:

https://docs.cypress.io/app/core-concepts/best-practices#Usi...

Dangling state is useful for debugging when the test fails, you don't want to clean that up.

This has been super useful practice in my experience. I really like to be able to run tests regardless of my application state. It's faster and over time it helps you hit and fixup various issues that you only encounter after you fill the database with enough data.

> It feels a little tricky to square these up sometimes.

In my experience, this heavily depends on the task, and there's a massive chasm between tasks where it's a good and bad fit. I can definitely imagine people working only on one side of this chasm and being perplexed by the other side.

> There must be a really good reason for this, such as Rust doesn’t interop well with C++

Yea, I'd bet it's that. Ideally, you'd want to stop writing C++ and continue with Rust on all new code, but Rust has stricter semantics, so the interop is somewhat "easy" in one direction, but very hairy in the other direction.

This means that in practice, you want to start porting from leaf components and slowly grow closer to the root, which stays in C++ for quite some time and just calls into Rust through C API (or something close to it).

If you're curious about the topic, there's a interop library called Zngur (https://hkalbasi.github.io/zngur/), which is built on this assumption. They have a pretty good explanation of the concrete problems on the homepage.

Lot of DOM APIs are like that. You have methods like element.[parent|children]() which implies circular structure, and then you have APIs like element.click(), which emits a click event that bubbles through the DOM - which means that element has to have some mutable reference to the DOM state. Or even element.remove(), which seems like a super weird api to have on an element of a collection, from Rust API design point of view.

You can model these with reference counting, but this turned out unfeasible in browsers. There's a great talk from when Blink (Chrome) transitioned from reference counting to GC, which provides a lot more details about these problems in practice: https://www.youtube.com/watch?v=_uxmEyd6uxo

> I'd get it if they were writing the UI in this, but the rest of this post is about the JS engine.

I think this might be the reason they started with the JS engine and not with some more fundamental browser structures. JS object model has these problems, too, but the engine has to solve them in more generic way. All JS objects can just be modeled as some JSObject class/struct where this is handled on the engine level.

DOM and other browser structures are different because the engine has to understand them, so the browser developers have to interact with the GC manually and if you watch the talk above, you'll see that it's quite involved to do even in C++, let alone in Rust, which puts a bunch of restrictions on top of that.

> Modern C++ pretty much solves the safety issues.

I always wonder how can one come to such a conclusion. Modern C++ has no way to enforce relationship between two objects in memory and the shared xor mutable rule, which means it can't even do the basic checks that are the foundation of Rust's safety features.

Of course, this statement is also trivially debunked by the reality of any major C++ program with complexity and attack surface of something like a browser. Modern C++ certainly didn't save Chrome from CVEs. They ban a bunch of C++ features, enforce the rule of two, and do a bunch of hardening and fuzzing on top of it and they still don't get spared from safety issues.

> besides the obvious

Well, what else is there besides the obvious? It's a browser.

I don't see the idea is visual tools, I never even heard somebody to talk about it like that. The plan is to target enterprise customers with advanced features. I feel like you should just go and watch some interviews or something where talk about their plan, Evan You was recently on a few podcasts mentioning their plans.

Also, the paradox is not really even there. JS ecosystem largely gave up on JS tools long time ago already. Pretty much all major build tools are migrating to native or already migrated, at least partially. This has been going on for last 4 years or something.

But the key to all of this is that most of these tools are still supporting JS plugins. Rolldown/Vite is compatible with Rollup JS plugins and OXLint has ESLint compatible API (it's in preview atm). So it's not really even a bet at all.

> what if the parsing step was performed immediately on stop symbols rather than later and merged with the program graph immediately rather than during a separate build step?

I think this is the way to go, kinda like on Github, where you write markdown in the comments, but that is only used for input, after that it's merged into the system, all code-like constructs (links, references, images) are resolveed and from then you interact with the higher level concept (rendered comment with links and images).

For programinng langauge, Unison does this - you write one function at a time in something like a REPL and functions are saved in content addressed database.

> Or what if it was like "staging" step?

Yes, and I guess it'd have to go even deeper. The system should be able to represent broken program (in edited state), so conceptually it has to be something like a structured database for code which separates the user input from stored semantic representation and the final program.

IDE's like IntelliJ already build a program model like this and incrementally update it as you edit, they just have to work very hard to do it and that model is imperfect.

There's million issues to solve with this, though. It's a hard problem.

Interesting. It looks to me this was more about the portability of the resulting binary, IIUC.

Dion project was more about user interface to the programming language and unifying tools to use AST (or Typed AST?) as a source of truth instead of text and what that unlocks.

Dion demo is here: https://vimeo.com/485177664

I think neither Unison nor Smalltalk use structural editing, though.

[edit] on the level of a code in a function at least.

IntelliJ diffs are also really good, they are somewhat semi-structural I'd say. Not going as far as difftastic it seems (but I haven't use that one).

I'm referring to UI interfaces that allow you to do structural editing only and usually only store the structural shape of the program (e.g. no whitespace or indentation). I think at this point nobody uses them for programming, it's pretty frustrating to use because it doesn't allow you to do edits that break the semantic text structure too much.

I guess the most used one is styles editor in chrome dev tools and that one is only really useful for small tweaks, even just adding new properties is already pretty frustrating experience.

[edit] otherwise I agree that structural editing a-la IDE shortcuts is useful, I use that a lot.

I think agree (but I think I think about this maybe a one level higher). I wrote about this a while ago in https://yoyo-code.com/programming-breakthroughs-we-need/#edi... .

One interesting thing I got in replies is Unison language (content adressed functions, function is defined by AST). Also, I recommend checking Dion language demo (experimental project which stores program as AST).

In general I think there's a missing piece between text and storage. Structural editing is likely a dead end, writing text seems superior, but storage format as text is just fundamentally problematic.

I think we need a good bridge that allows editing via text, but storage like structured database (I'd go as far as say relational database, maybe). This would unlock a lot of IDE-like features for simple programmatic usage, or manipulating langauge semantics in some interesting ways, but challenge is of course how to keep the mapping between textual input in shape.

I have to respond to your point, though. Whether 30% cut is excessive depends on whether devs feel like they are getting a good deal. As far as I can tell, game developers don't seem to complain about Steam cut very much, it seems like the value you get is worth it.

For example, this thread https://www.reddit.com/r/Steam/comments/10wvgoo/do_you_think... seems like majority is positive about it, even though people debate. When Apple tax is brought up, there's almost never even a discussion there, it's pretty universally hated.

Apple seems to have almost adveserial relationship to its developers. I deploy to App Store and I feel like I'm getting screwed. Even compared to Google, which takes the same cut, but does bahave a lot more nicely to its developers.

I'm not judging that, it just seems to contradict the "But Steam shows us another model..." sentence, so I'm trying to make sense of that.

Steam takes 30% cut, though?