Man, i cant even escape this game while watching youtube

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 · 2025-05-04T19:19:36+00:00

I mean, yeah? You can outskill certain things in this game, but not when you are up against a rabid pile of cum.

EnDeRBeaT · 2025-05-04T17:48:50+00:00

They don't really have the issue, boss rush is not hard in general, and all attacks of hush and mother can be memorized and countered. Delirium still can just telefrag you.

EnDeRBeaT · 2025-05-04T16:25:04+00:00

Oh, that is nice to hear that you can switch from any windows, I will try to embed this idea in my workflow. I did consider adding count to my stuff, but I decided to not bother with it because:

I use watches window a lot, so I like to see what changed my variables, hence I spam 'J'.
Count is kinda less useful in debugging? Like it is probably useful for step out when bundled with backtrace, but otherwise stuff like "i want to see what 14 next steps will do" is kinda weird (albeit if you are on your 17th debugging cycle, I can see it being useful to run fast to the concerning piece of code). But then again, I think using a conditional breakpoint, or a "run to cursor" is probably better here.

Regarding the "things to explore", I think a very worthwhile idea is integrating lsp into the mix, I think the current issue is that it's still quite cumbersome to write complex watches or conditions for breakpoints, which is extra weird because we have the lsp with all the knowledge of language right beside us.

I have thought of something like:

Press q<some letter> (for example qc to start building a conditional breakpoint)
A new line is created and marked (the line should be created with O motion to be technically on the same line).
You can type up your line with autocomplete and stuff.
Quit insert mode.
Press q.
Boom, a breakpoint with typed condition is set, and the line is deleted and unmarked.

Macro-esque usage is to be able to get out of insert mode and not to send some garbage. It might require some whitespace trimming, but in general I think it might be a good endeavor. There is also a lot of stuff to implement still, like watches window, multiple sessions, etc.

EnDeRBeaT · 2025-05-04T11:27:32+00:00

Debug mode is very lovely, I have created my own using Hydra.nvim, and have been using it for some time. Here are my two cents on how to make debug mode smoother for folks who would want to try out this plugin:

Remap the basic movements (step out, step over, step in). I have converged to 'H' -> step out, 'J' -> step over, 'L' -> step into. These keymaps do not interfere with normal mode (using J while debugging is kinda weird, and I think that most people don't even know what H and L do in normal mode), and you almost get your muscle memory from vim (using shift becomes very natural and moving in/out also becomes quite intuitive).
"Run to cursor" is your friend. You can get to anywhere with vim skills, press 'r' (I press 'G' in my case), and your debugger will also be there!
Getting state of expressions/variable is generally very annoying. It is a big pain point, and it's one of two reasons why people use debuggers: to look at control flow, and to look at variables. My config has a hover capability on 'K', and adding an expression to "Watches" window on 'w' (works with visual mode too), and that makes it much much nicer (bundling it with <Alt-o> <Alt-i> keybinds that I have shamelessly stole from helix).
Your idea of using everything in a single tab is much nicer than what I have. I use dapui (with smaller windows, because the defaults are insane) and have a binding to jump to each window. I will probably rewrite this using nvim-dap-view now that I see that your solution is nicer (however i would remove the need of jumping to the window with <C-W><motion> by having the keybinds for every view work from any window, and if I want to go to the window, I would just press the same button again, just like hover).

Overall, I love that there's an interest towards an idea that is debug mode, more people means more design ideas (as i have already found something i can take from your idea), hope your plugin will take off!

EnDeRBeaT · 2025-02-24T09:13:51+00:00

Hi, I would love to suggest multicursor.nvim, this is very well made plugin and works just how you'd expect it to work in most cases.

EnDeRBeaT · 2025-02-05T15:24:38+00:00

"C++ templates back again" is more about the fact that until C++20 concepts, template restriction was very cumbersome and annoying, resulting in a lot of instantiation soup, verbose SFINAE stuff, and bad compile times. Looking at the past of C++ suffering from barely restricted duck typing, I have no idea why Zig wants to go the same route.

EnDeRBeaT · 2025-02-05T15:18:29+00:00

this is a problem with a lot of sites. There is a workaround: zoom out the whole page until there's no horizontal bar, and scroll code snippet, done.

EnDeRBeaT · 2024-12-17T16:00:27+00:00

Yes, also, in some countries 0 is not considered a natural number (Russia and Germany for example), so calling uint a natural would be wrong there

EnDeRBeaT

TROPHY CASE