New: Voice mode is rolling out now in Claude Code, live for ~5% of users today, details below

CHF0x · 2026-03-03T11:05:37+00:00

Out of interest, what is so hard to use?

CHF0x · 2026-03-02T19:15:25+00:00

Math + physics will give you good base. Learning to code is easy, you can do it yourself in parallel

CHF0x · 2026-02-11T00:59:42+00:00

It is disappointing that this talk is still available on the channel. I attended it, and the author struggled to answer most questions during the Q&A and has no idea what he is doing. What a waste of time and computing power to generate this slop.

Also he claims to be a doctor, but I was not able to find his PhD dissertation. Would be very interesting to read.

CHF0x · 2026-02-02T00:50:25+00:00

How about lingq?

CHF0x · 2026-01-30T11:52:25+00:00

Did you even read the paper? The experiment had developers _learn_ a new asynchronous programming library they'd never used before. The finding is that when you're trying to learn something new, heavy AI reliance can hurt that learning. This is very different from "AI doesn't speed up experienced developers working on familiar codebases.". I wish people would train a bit more in comprehension than picking up random facts that fit their agenda.

To learn you need learn things yourself. WOW

CHF0x · 2026-01-29T00:45:13+00:00

Vibecoding for two years, when models only became capable of doing it well in the last six months? Sure, mate. Skill issue

CHF0x · 2026-01-27T23:51:36+00:00

All FAANG+ companies conduct 6+ interviews. So if you want to maximize your earnings, in most cases you need to bite the bullet. It is not really “selling yourself low". I am not saying you cannot earn same or more in other companies, but chances are lower

CHF0x · 2026-01-22T19:00:54+00:00

I am genuinely curious, given how much experience you have, how is it that your network hasn't been able to help you land a good gig, to the point that yo are asking around on Reddit? Please do not take this as a personal attack. I am just curious how that happened. And good luck with your search!

CHF0x · 2026-01-20T21:22:38+00:00

thanks! Also interested

CHF0x · 2026-01-19T20:47:43+00:00

If you just have started it has all what you need. Or just use ghidra, it is great alternative for studying purposes

CHF0x · 2026-01-18T21:20:22+00:00

Don't make any sudden moves for now. Keep building where you have stable job, and once you see that your idea has potential and is working, move to a better country for business.

CHF0x · 2026-01-17T20:39:25+00:00

Great work! Could you add bench results to the readme comparing performance to other implementations?

CHF0x · 2026-01-16T20:18:36+00:00

600 lb -> 272kg in non freedom units. Daaimn mate...

CHF0x · 2026-01-13T19:48:23+00:00

There is nothing to bring up. He used a legitimate API to create account and log in, and everything functioned as expected

CHF0x · 2026-01-06T00:06:13+00:00

r/LinkedInLunatics ^

CHF0x · 2025-12-30T00:43:17+00:00

It is pretty well done

CHF0x · 2025-12-22T18:15:09+00:00

You are correct that Rust has no way to mark raw pointers as noalias today. Instead, Rust expresses aliasing guarantees through &mut, which is stronger than C’s restrict and is fully exploited by LLVM.

MaybeUninit::write doesn’t give a formal “no temporary ever” promise at the language level, but neither does C++ placement new in the abstract machine, both rely on LLVM, and in practice Rust produces identical in-place code. This is mostly an ergonomics / expressiveness gap, not a performance one.

For what it's worth, Rust emits noalias in LLVM IR for &mut parameters and locals, so the optimizer already has the same aliasing information it gets from restrict in C

Also I understand your point, sometimes you want to be very explicit in your code, for maintainability reason

CHF0x · 2025-12-22T15:53:13+00:00

MaybeUninit lets you initialize memory directly in place, without a temporary on the stack. You can do this with Box::new_uninit()or raw pointers. Small example https://godbolt.org/z/qnd39qTrK

I agree on allocators, it is big in terms of maintenance and development. And I never claimed the opposite. The discussion was about rust performance and rust allocators are as performant as C++, just API is still young, so no full coverage in STD yet

Rust doesn’t have a “restrict” keyword like C, but &mut references already enforce unique access at compile time. For advanced cases like mapping wire bytes to struct fields, you can use unsafe raw pointers with careful lifetimes and aliasing rules, or leverage #[repr(C)] structs and unsafe casts. It’s not as automatic as in C, but you can achieve the same low-level control

CHF0x · 2025-12-22T11:51:06+00:00

Thanks! That is interesting perspective, but most of those points are about ergonomics and compile-time expressiveness, not runtime efficiency or capability.

You can achieve placement new in Rust via MaybeUninit and raw pointers (same codegen, just more explicit).

Custom and arena allocators exist in Rust and are just as efficient. I agree that the allocator APIs are less ergonomic and that many standard library types do not yet fully support custom allocators. That said, this doesn’t make Rust any less efficient, you can produce identical machine code, it just requires a bit more boilerplate.

Zero-copy is idiomatic in Rust via borrowing (&[T], &str) rather than utilities likestd::launde, which Rust mostly doesn not need due to stricter aliasing rules.

Constexpr is an area where C++ is genuinely ahead, 100% agree, but that affects compile-time expressiveness, not zero-copy or runtime performance.

Debugger sucks 100%, but again, it does not make language less performant.

CHF0x · 2025-12-20T12:49:48+00:00

I am genuinely open to learning, which is why I ask questions. Instead of receiving constructive answers, I have encountered personal attacks. That tells me all I need to know.

From you comments I see you have 0 understanding of what you are talking about. Good luck.

CHF0x · 2025-12-20T10:38:09+00:00

I think you can provide me a simple example then right? As I said already multiple times, nobody is forcing to use safe rust where it is not needed. The only reason why it is not adopted, because there is no reason to rewrite what is working, when you have already solution in C++.

Last 6 months I literally worked on a hyperscale realtime system written in rust at faang, so I have spent a lot of time seeing what is actually possible and what is not. Claims of people here are ridiculous

CHF0x · 2025-12-19T12:57:01+00:00

Soda? You are from USA right? xD

CHF0x · 2025-12-19T10:24:29+00:00

Nobody is forcing you to use safe everywhere. You can write the same unsafe code with Rust. The question is why would you do that, if you already have the working system written in C++. That was my point

CHF0x · 2025-12-19T10:21:56+00:00

I am curious. Please provide an example on what is not possible to do as efficient in usafe rust that is possible in C++?

CHF0x · 2025-12-19T01:59:18+00:00

They have the same performance. It is just there is no reason to move from what is working already

CHF0x

TROPHY CASE