Chocolate Dolphin
@chocolatedolphin7.bsky.social
hello I'm a human being 🐬🍫 he/him
Wishlist Fierce Kingdoms on Steam! https://store.steampowered.com/app/3406130/Fierce_Kingdoms/
Wishlist Fierce Kingdoms on Steam! https://store.steampowered.com/app/3406130/Fierce_Kingdoms/
tl;dr code eventually made it to prod globally without having a specific buggy path actually run, and when it did, it was too late and crashed everything
wouldn't be surprised if it was vibecoded but they're not gonna say that
wouldn't be surprised if it was vibecoded but they're not gonna say that
June 16, 2025 at 12:16 AM
tl;dr code eventually made it to prod globally without having a specific buggy path actually run, and when it did, it was too late and crashed everything
wouldn't be surprised if it was vibecoded but they're not gonna say that
wouldn't be surprised if it was vibecoded but they're not gonna say that
Which ones? I'm interested in any low level language that doesn't depend on LLVM. It's really sad that every new language I come across depends on LLVM because getting high-quality optimized codegen is extremely difficult. Writing a parser, analyzing semantics etc is super easy in comparison
June 15, 2025 at 7:38 AM
Which ones? I'm interested in any low level language that doesn't depend on LLVM. It's really sad that every new language I come across depends on LLVM because getting high-quality optimized codegen is extremely difficult. Writing a parser, analyzing semantics etc is super easy in comparison
Both clang and gcc max out near perfectly at 100% cpu usage for the threads I give them, so I wonder what exactly the culprit is. Maybe it's something to do with header files? They're essentially processed many many times, but maybe they allow for better parallelization. Idk
June 15, 2025 at 7:35 AM
Both clang and gcc max out near perfectly at 100% cpu usage for the threads I give them, so I wonder what exactly the culprit is. Maybe it's something to do with header files? They're essentially processed many many times, but maybe they allow for better parallelization. Idk
so while mozilla does some good things very rarely sometimes, I woudn't consider myself lucky or fortunate for being close friends with mozilla people, and I don't take them very seriously either. the entire org depends on morally wrong $$$ from google, it's not a very grassroots org
June 14, 2025 at 10:56 PM
so while mozilla does some good things very rarely sometimes, I woudn't consider myself lucky or fortunate for being close friends with mozilla people, and I don't take them very seriously either. the entire org depends on morally wrong $$$ from google, it's not a very grassroots org
can't think of 2) as a positive though, to this day mozilla depends entirely on google, they went from being #1 in marketshare to <6% and shrinking each year, while not improving the browser much and doing lots of questionable things. they're pretty much a facade for google's monopoly on the web
June 14, 2025 at 10:51 PM
can't think of 2) as a positive though, to this day mozilla depends entirely on google, they went from being #1 in marketshare to <6% and shrinking each year, while not improving the browser much and doing lots of questionable things. they're pretty much a facade for google's monopoly on the web
that's an interesting background, that being said, 1) is most likely tied to the connection between wasm/rust/mozilla. haven't used wasm myself but I do know plenty of c++ projects exporting to web and workng great though (except multithreading), so idk what the exact issue is
June 14, 2025 at 10:47 PM
that's an interesting background, that being said, 1) is most likely tied to the connection between wasm/rust/mozilla. haven't used wasm myself but I do know plenty of c++ projects exporting to web and workng great though (except multithreading), so idk what the exact issue is
I forgot but it should be like only 4 cores. didn't bother to troubleshoot but I think it was either the linking process or one big crate in particular that caused it. could you try compiling that CLI program I linked to maybe?
June 14, 2025 at 9:32 PM
I forgot but it should be like only 4 cores. didn't bother to troubleshoot but I think it was either the linking process or one big crate in particular that caused it. could you try compiling that CLI program I linked to maybe?
because it defeats the purpose of packages in the first place? the point is to group related functionality into one package split into several files. if by design you can't do that without compromising build times, the design is broken and pushes you into a less flexible, less organized structure
June 14, 2025 at 9:29 PM
because it defeats the purpose of packages in the first place? the point is to group related functionality into one package split into several files. if by design you can't do that without compromising build times, the design is broken and pushes you into a less flexible, less organized structure
are you talking about docker containers or something like that? that is NOT the same thing at all. but I give up trying to explain things to you
June 14, 2025 at 8:49 AM
are you talking about docker containers or something like that? that is NOT the same thing at all. but I give up trying to explain things to you
it's been way over a decade at this point that the core fancy features were introduced. it's not unworkable at all, it's mostly just that lots of c++ projects are legacy or old programs. rust is so dangerous and harmful that it can steer potential new programmers away from c++ by making false claims
June 14, 2025 at 8:47 AM
it's been way over a decade at this point that the core fancy features were introduced. it's not unworkable at all, it's mostly just that lots of c++ projects are legacy or old programs. rust is so dangerous and harmful that it can steer potential new programmers away from c++ by making false claims
I know it's most definitely documented & according to spec, that's besides the point, I'm not even that far into the docs and already the compiler is not smart enough to notice something's wrong, it didn't even emit a warning. wouldn't be surprised if it was at least a warning in c or c++ tbh
June 14, 2025 at 8:42 AM
I know it's most definitely documented & according to spec, that's besides the point, I'm not even that far into the docs and already the compiler is not smart enough to notice something's wrong, it didn't even emit a warning. wouldn't be surprised if it was at least a warning in c or c++ tbh
go and try it yourself then, maybe that's the only way you'll learn why it's not doable, not in a remotely sane, workable manner. i could keep explaining it to you, but you simply do not get it
June 14, 2025 at 8:40 AM
go and try it yourself then, maybe that's the only way you'll learn why it's not doable, not in a remotely sane, workable manner. i could keep explaining it to you, but you simply do not get it
I give up with even considering to use this lang, it's a total mess without even looking that deep, and from what I've seen so far, it's totally a cult. and just a fun fact: yes you can have fairly safe C++ code, see isocpp.github.io/CppCoreGuide... but oh well ppl watch youtube instead of reading
C++ Core Guidelines
The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++
isocpp.github.io
June 14, 2025 at 8:38 AM
I give up with even considering to use this lang, it's a total mess without even looking that deep, and from what I've seen so far, it's totally a cult. and just a fun fact: yes you can have fairly safe C++ code, see isocpp.github.io/CppCoreGuide... but oh well ppl watch youtube instead of reading
also I had just started to try to understand rust a little bit better, was reading this doc.rust-lang.org/rust-by-exam... and then apparently simply changing slice[0] to something illegal like [8] crashes the program. WHY!? the length is even known at compile yet just crashes at runtime instead
Arrays and Slices - Rust By Example
Rust by Example (RBE) is a collection of runnable examples that illustrate various Rust concepts and standard libraries.
doc.rust-lang.org
June 14, 2025 at 8:35 AM
also I had just started to try to understand rust a little bit better, was reading this doc.rust-lang.org/rust-by-exam... and then apparently simply changing slice[0] to something illegal like [8] crashes the program. WHY!? the length is even known at compile yet just crashes at runtime instead
again another video, yay! but also not really representative of reality. it's too long to elaborate on why they're wrong, but essentially rust *IS NOT* an upgrade from say, C++. it's quite the opposite, it's objectively worse in too many ways
June 14, 2025 at 8:33 AM
again another video, yay! but also not really representative of reality. it's too long to elaborate on why they're wrong, but essentially rust *IS NOT* an upgrade from say, C++. it's quite the opposite, it's objectively worse in too many ways
who said single binary? how is it not clear to you that static linking everything isn't feasible? to clarify, when you statically link something, you're essentially including an entire copy of that lib's compiled code in your program (unused parts can prob be optimized away by compiler/linker tho)
June 14, 2025 at 8:28 AM
who said single binary? how is it not clear to you that static linking everything isn't feasible? to clarify, when you statically link something, you're essentially including an entire copy of that lib's compiled code in your program (unused parts can prob be optimized away by compiler/linker tho)
it's not so much just choosing dependencies wisely, but also even doing it in the first place. less friction = way more dependencies. and the problems w/ too many deps are not obvious at first, they only pop up later in the form of instability, at which point it's annoying to replace/remove deps
June 14, 2025 at 8:25 AM
it's not so much just choosing dependencies wisely, but also even doing it in the first place. less friction = way more dependencies. and the problems w/ too many deps are not obvious at first, they only pop up later in the form of instability, at which point it's annoying to replace/remove deps
btw setenv is so discouraged that it's not even supported in languages like java. if libs include libs that makes it much more likely you end up w/ obscure libraries in your product like that rust one. again, that's why C/C++ libs tend to avoid using libs themselves, it's not a new concept
June 14, 2025 at 7:45 AM
btw setenv is so discouraged that it's not even supported in languages like java. if libs include libs that makes it much more likely you end up w/ obscure libraries in your product like that rust one. again, that's why C/C++ libs tend to avoid using libs themselves, it's not a new concept
the original article in itself is good empirical evidence that indeed, being too eager to use dependencies for trivial things leads to instability and often poor quality code. the crash happened in part bc the library is using setenv for no good reason at all, that lib shouldn't do that afaik
June 14, 2025 at 7:43 AM
the original article in itself is good empirical evidence that indeed, being too eager to use dependencies for trivial things leads to instability and often poor quality code. the crash happened in part bc the library is using setenv for no good reason at all, that lib shouldn't do that afaik
"most likely poorly" this in fact leads me to believe that it is you who doesn't have much experience being a dev, because this is like the most popular misconception ever that at some point everyone realizes is not even remotely true. sometimes using a library makes sense, sometimes not so much
June 14, 2025 at 7:40 AM
"most likely poorly" this in fact leads me to believe that it is you who doesn't have much experience being a dev, because this is like the most popular misconception ever that at some point everyone realizes is not even remotely true. sometimes using a library makes sense, sometimes not so much
very ironic because rust is so slow to compile when you change something, it wastes plenty of human time. it's been a real issue for lots of ppl and orgs who unfortunately got baited into using rust and had to do dirty workarounds to lower the compile times
June 14, 2025 at 7:37 AM
very ironic because rust is so slow to compile when you change something, it wastes plenty of human time. it's been a real issue for lots of ppl and orgs who unfortunately got baited into using rust and had to do dirty workarounds to lower the compile times
and what would you do if, for example, you have dep A that's fairly close to the core, that is required by nearly every other dep? good luck constantly recompiling the entire system for every one-liner fix
June 14, 2025 at 7:31 AM
and what would you do if, for example, you have dep A that's fairly close to the core, that is required by nearly every other dep? good luck constantly recompiling the entire system for every one-liner fix
why not instead you provide an example fully featured stable OS where *everything* is written in rust and does static linking everywhere? it's literally impossible. sure 1 program might be ok, but not all of them. don't you think if static was better, everyone would have moved to it loooong ago?
June 14, 2025 at 7:29 AM
why not instead you provide an example fully featured stable OS where *everything* is written in rust and does static linking everywhere? it's literally impossible. sure 1 program might be ok, but not all of them. don't you think if static was better, everyone would have moved to it loooong ago?
also ironic bc supposedly from what I've read, rust is the least productive language of all bc of the borrow checker but idk if that's true
June 14, 2025 at 7:25 AM
also ironic bc supposedly from what I've read, rust is the least productive language of all bc of the borrow checker but idk if that's true
saying rust forces you to do things properly is a pretty wild, biased and hard to prove claim. and no, writing safe code in *new* C++ projects does absolutely not require extreme care, it just shows you probably never even tried to and are parroting misleading information from the internet
June 14, 2025 at 7:24 AM
saying rust forces you to do things properly is a pretty wild, biased and hard to prove claim. and no, writing safe code in *new* C++ projects does absolutely not require extreme care, it just shows you probably never even tried to and are parroting misleading information from the internet