Maybe you just weren't white enough

@retoor -.-

Now I'm hungry :(

Screw society then. Bunch of sheep anyways

@whimsical @AlgoRythm @YourMom Bunch of heathens :P

@YourMom Well, they explicitely made the decision that it should crash. They could have also ignored the error, or properly handle it and it wouldn't have crashed

I get your point about python but that's more of a coincidence that in this specific case this is what you want: Exceptions bubble up automatically and the async runtime will handle any exception and restart the task or whatever

Rust forces you to handle errors instead of auto bubbling up, but they *could* have also bubbled it up to the root and then restart the service

At the end of the day it was a deliberate bad decision, not something that accidentally happened because of flaws in Rust

@retoor Guess I'm too fast (that's what she said :P)

@retoor Yes that would happen in Python because they chose (!) not to handle that error case

That's the python equivalent of not catching and handling the exception -> crash

@YourMom It wasn't a memory error. The code tried filling up an array with too many elements. That (safely) returned an error. And then somewhere up the call stack they unwrap'ed the Result because they thought this situation could/should never occur

The bug was that they preallocated memory for 200 feature flags because they thought nobody ever needed more, and somebody loaded more than 200 features

*Literally* has nothing to do with Rust

Please stop falling for these absolutely retarded rage bait headlines

@YourMom TOML is justice 😭

Do note that toml doesn't really do nested objects easily, so not the best choice for a scene graph, but I guess you could just have a flat list of objects with parent = <id> field

Classic prisoners dilemma

At the end of the day you'll always find someone who will do it, so we are all doomed to also play along

@CoreFusionX I think as long as you don't compose multiple euler angle rotations you shouldn't have a problem with gimbal lock. I.e. you can always decompose any rotation into a sane set of euler angles in a given coordinate system

But you're right, just use quaternions :P They're faster anyways because of less trigonometric operations

@retoor No, I'm just procrastinating and reading dR all the time :P

@retoor I've tried claude a little online and it's output seems a lot better than chatgpt. You can ask it stuff about LLVM passes and it can tell you the exact source file where something is implemented, pretty cool stuff!

@AlgoRythm You really underestimate how autistic and knowledgable the Rust user base is. I have no idea where the idea come from that all Rust users are dumb script kiddies because it's actually quite the opposite, there are so many incredibly smart people (and it makes sense, because just like OCaml or Haskell, Rust is complex enough that anybody doing anything serious *has* to know what their doing :P Script kiddies can't)

The real issue with adding Rust is just the fact that you're doing new development, and especially if you replace something, you'll inevitably add bugs that need to be ironed out over time

Linux isn't being rewritten in Rust btw. It's for new subsystems or subsystems which badly need fixing anyways. And for anything security related I see it as a win

@Lensflare Oh come on, Eclipse is fineee

Still use it from time to time for Minecraft modding!

There's a reason chatgpt plus is $20 and pro is $250

Those data centers ain't cheap! All that free AI usage was subsidized by investors burning billions of dollars for customer acquisition

Now they want to actually make some of that money back :P

@D-4got10-01 I don't agree with canonical's choice either. But if you read some of the comment sections on different news sites, hoo boy, are there some mentally retarded rust haters lol

@Liebranca If the question is "is accessing an allocation on the stack or heap faster?" the answer is "they're both just memory, so it doesn't matter (ignoring that the stack region might already be in your caches)"

If the question is "is *allocating* faster on stack or heap?" then stack is magnitudes faster

:P

@whimsical How am I wrong? o.O

The hate against uutils is retarded

But ubuntu replacing battle tested gnu utils with alpha uutils is also really retarded

@whimsical Oh, stack allocation by far

@Liebranca Damn, pretty cool!

Also first time seeing someone still using perl :P

@Liebranca How are you dealing with the complexities of x86 though!??

I mean you also have to follow some ABI when doing function calls, and you also have to deal with x86 memory operands which can be as complex as `[rbx + rax * 4 + 0x1337]` (and should be as complex for performance!), you have to implement register allocation, etc.

I'm actually curious

@Liebranca I agree with you that I don't have to follow any specific specification (which to be fair i'm not because of complexity :P)

But do note that I'm writing a real compiler with an x86_64 machine code backend. I legitimately have to put things into physical registers or on the stack for this to work, and I'd like to not make something *completely* shitty so I'd also like to support some pretty important optimizations like folding ptr calculations into x86 memory operands

I've written a stack machine based compiler before and that was fine-ish (still pretty complex :P) but for x86 that just won't cut it

@AlgoRythm Can zig do dynamic allocations in comptime?

Understandable. Prostate massages are allegedly pretty pleasurable

Yeah C++ is crazy powerful -- and arcane :P