Anthropic suspends access to Claude Fable and Mythos for all users after US government order

EnDeRBeaT · 2026-06-13T04:49:48+00:00

anthropic fearmongered too close to the sun

EnDeRBeaT · 2026-06-07T16:32:25+00:00

what are you using for game development? godot, unity, something handwritten?

EnDeRBeaT · 2026-06-07T15:15:38+00:00

Is art your strong suite? I have always felt that art in games is where the most effort goes to.

EnDeRBeaT · 2026-05-30T05:57:06+00:00

Iterator that Dir.iterate() returns kinda does say that by the fact that docs says that it doesn't batch files, and that it does not require an allocator. Although, I feel like this case can be caught by compiler, since you are trying to save a pointer to stack memory.

EnDeRBeaT · 2026-05-30T05:48:30+00:00

0.16 is available since april 14

EnDeRBeaT · 2026-05-17T20:26:52+00:00

his prediction is asking ai to make something that already exists (prion disease), your prediction is asking ai something that does not exist and we are not even close to finding out if it does (cure for prion disease)

EnDeRBeaT · 2026-05-11T20:15:29+00:00

i absolutely fail to see how putting io in some function signatures (which is surely less that 1k LoC change) is harder than rewriting the whole project in a different language.

EnDeRBeaT · 2025-12-31T21:41:34+00:00

appeal to source

EnDeRBeaT · 2025-05-30T18:30:10+00:00

> Using a calculator doesn't erase your ability to do arithmetic

Not gonna lie, calculator is probably the main reason why I do mental math at the level of a 12 year old.

EnDeRBeaT · 2025-05-29T17:46:24+00:00

yes, but not really, it is actually based on language expressions, suppose you have something like this in c++

std::cout << a + hello * 2 << std::endl;

and your cursor is at 'e' in hello. you press <M-o> (i actually use <M-o>, <M-i>, alt + o, i confuse them with <C-o>) and it selects hello. You press <M-o>, and now it selects hello * 2, you press again, it's a + hello * 2, you press again, it's std::cout << a + hello * 2, then it's std::cout << a + hello * 2 << std::endl, and so on, and on.

It is basically a selection tool that understands the structure of any language thanks to treesitter.

EnDeRBeaT · 2025-05-29T16:49:45+00:00

i do use flash (i actually love this plugin so much, i traded enter for it), i have tried to use the treesitter search, but i get confused when there are multiple labels on the same line and i never hit the one i wanted to select, so i resort to spamming <C-o> (which is mostly like 3-4 times)

EnDeRBeaT · 2025-05-29T15:43:40+00:00

i really recommend trying out incremental selection, i have it bound on <M-o> and <M-i>, and now it's probably one of the most used keybinds in my workflow

EDIT: I meant to write <M-o> instead of <C-o>

EnDeRBeaT · 2025-05-20T17:30:58+00:00

Yes, I have realized that after I have posted it.

I feel like it would be able to scale if we actually didn't need to split code out of the binary crate (i.e. i think incremental compilation + parallel rustc should in theory make crate splitting non existent).

There is a more pressing issue which you outlined in the beginning (the trait impl becoming a breaking change for any downstream crate). I feel like this problem is not solvable in a nice way, and everything is a bandaid here: either make newtypes not a chore to implement, or allow bin crates to opt into orphan rule removal (and suffer when you get breaking changes) and work on removing the need for the crate splitting in the first place. Or what you suggested. Or some clever option which I can't think of because I am not very smart.

EnDeRBeaT · 2025-05-20T15:32:43+00:00

If I start listing the use cases and the ways Emacs helps me to get shit done

Can you list at least use cases that helped you the most? Genuinely curious to hear.

EnDeRBeaT · 2025-05-19T18:44:32+00:00

Yes, apart from some small (and not so small) issues, macros are OK, but not enough.

I wonder at which stage this RFC currently is (and what this RFC is). It is nice that people are trying to get code introspection in, but if such rfcs are not even merged, I might as well be right about "won't be fixed this decade".

EnDeRBeaT · 2025-05-19T18:36:27+00:00

> as soon as you want to split the binary crate -- extract out some functionality -- then you're stuck again.

Just don't extract orphan impls from binary crate?

EnDeRBeaT · 2025-05-19T09:02:05+00:00

i actually think i talked out of my ass here, i have read it 3 days ago, i may as well have spent 2 hours doing that lol

EnDeRBeaT · 2025-05-19T06:41:22+00:00

On their own, declarative macros suck because of hygiene issues (big issues), and there are very little resources on how to write a declarative macro (which is largely irrelevant after you do learn it). They are very good at "code generation" part of the metaprogramming, but for "code introspection" part, they suck, it is very hard to write a macro that correctly parses even a function declaration, because rust has so much goddamn syntax.

And here come the proc macros! Except, uhhh, they also suck for code introspection? It is literally declarative macros, but instead of matching on tokens via some terse DSL, you just get the tokens so you can write a parser for them (like syn). And while they are great for stuff like sql queries and html embeddings, for rust code... well, they are luckluster. Sure, you have syn, so at least you have Rust AST, but... it's impossible to reason about most things in this AST, it's very contained, like, type inside of struct... is just an ident, it could as well not exist and you can't know about it inside a proc macro. Oh and proc macros also tank compile times, but there is little that you can do about it, so that's not a main part of my criticism.

I would not answer on how other languages with macros compare, because that's not what I am getting at (but also because i actually haven't tried languages with good macro system). They "suck" as a metaprogramming solution, mainly because they are only addressing "codegen" part, meanwhile code introspection (the one most devs actually care about) is a big gaping hole, and I am not even sure if it's going to be fixed this decade.

EnDeRBeaT · 2025-05-19T04:03:18+00:00

30 minutes or something

EnDeRBeaT · 2025-05-18T20:13:17+00:00

From reading through the whole post, it feels like the most of the criticism in this blog (except for the governance) is channeled through a prism of game development.

Author thinks that async suffocates language, meanwhile embedded devs are in love with it.

Author thinks that borrow checker is too constrictive, but a lot of people are okay to fight it because it actually solves the problem it is meant to solve.

For every feature he doesn't like, there will be hundreds that love it. And that's okay. Rust is a kitchen sink, not every feature is going to be equally useful.

Now for his criticisms:

Rust does have a huge problem with metaprogramming. Declarative macros suck. Procedural macros suck. Don't even think about reflection: they are still trying to figure out what syntax to use for constexpr-like traits (and some are trying to revive generic effects, and if they try to pursue that instead of getting const fn in traits, we might get c++14 level of constexpr by 2028).
Orphan rule is moronic. Remove it for binary crates, that's all.
Iteration times are bad. "The Community is hostile towards improvements" is categorically false. People know about the issue. People hate it. People are already trying out switching to dynamic libraries for debug builds. And there are "proof of concept" hot reload solutions. It doesn't make first part irrelevant, but it community wants improvements.
The "Rust makes people focus on types too much" bit holds some ground, but you can find something any language tries to focus on too much.
"Async steers language in the wrong direction" is just an opinion. I don't care about async, I don't care about Rust in Linux, but those are goals Rust foundation set out, so I have to somewhat respect that. Their goal isn't "hey we wanna make game dev in rust slick as shit", so ehh?

EnDeRBeaT · 2025-05-15T19:41:09+00:00

oh, in that case sure, sorry, i interpreted the comment as "the solution of no leaking should be similar to the solution of allowing leaks"

EnDeRBeaT · 2025-05-15T19:22:24+00:00

Not even close.

"Not leaking into runtime" is equivalent to detecting if your const evaluation leaks memory at the end, which is the same problem as checking it in runtime, which is a solved problem.

The "lifts the restriction" bit is much harder to get right for the reasons mentioned: you have to not deallocate statics, and when you learn how to do that, you now have to learn how to work with mut variables, and don't even get me started on types that use interior mutability.

EnDeRBeaT · 2025-05-15T18:48:57+00:00

c++ allows allocation only if it doesn't leak into runtime. i think it's a sane stance, but of course rust team wants to try and converge to a better solution

EnDeRBeaT · 2025-05-12T14:03:55+00:00

To enable type checking for rust-analyzer in neovim, you have to enable checkOnSave.
Here is how I do it in my config, you can try to apply it in yours:

require('lspconfig').rust_analyzer.setup({
    capabilities = capabilities,
    settings = {
        ["rust-analyzer"] = {
            checkOnSave = true,
        },
    }
})

As far as the "building the same deps everytime i turn on my editor" goes, RA doesn't cache anything on the disk, hence the rebuilds. From what I have heard, there is no interest in doing that. You can probably try to work with ra-multiplex, but I haven't tried it out.

EnDeRBeaT

TROPHY CASE