![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://lemmy.world/pictrs/image/c47230a8-134c-4dc9-89e8-75c6ea875d36.png)
Imagine voting for Voldemort
Imagine voting for Voldemort
In the case of docker I’m already at the point where I no longer think it’s necessary. At my current job our stack is JS, PHP and Python. 3 interpreted languages, we then build on Ubuntu and deploy on Ubuntu. I don’t think our project really needs docker, even though it does use it. We also have wasm/wasi prepping to eat Docker’s lunch.
I’m not against immutable distro’s on principle. I imagine they still have some kinks to iron out, but I haven’t looked in on them for a while.
My opinion on these things is; if it’s a superior system, then it’ll become the new standard, that’s always what happens, and the naysayers are largely irrelevant. Just like computers, smart phones, the internet, etc.
Maybe this is a case of hindsight being 20/20 but wouldn’t they have caught this if they tried pushing the file to a test machine first?
I like how at the start of the line it explicitly says “out of memory” but we’re just pretending this is some satanic bullshit.
She obviously read the error to find “kill process” and “sacrifice child” but still ignored the memory error
Add Exporters MVP
At work we have a lot of old monolithic OOP PHP code. Dependency injection has been the new way to do things since before I started and it’s basically never used anywhere.
I assume most people just find it easier to create a new class instance where it’s needed.
I’ve never really seen a case where I think, “dependency injection would be amazing here” I assume there is a case otherwise it wouldn’t exist.
It looks like it’s 3x faster than the previous cpython wasm compilation. Recall that most of the performance improvements in python have been done in the last ~2 releases.
My distro is debian based so it’s still on 3.10 which I would guess this new wasm implementation is much closer to in performance.
Compiling to wasm also means that you can distribute a binary rather than needing people to have python installed.
What mantra? I think this maintainer is doing the right thing here by trying to understand why this fix works.
You should always attempt to address the root cause of an issue instead of slapping band aid patches onto everything.
To me it looks like the maintainer is trying to find out what exactly is wrong. “this doesn’t happen in our C implementation” implies that there’s something wrong with the rust code specifically.
In the article it’s said that the JiT has similar performance to the latest stable interpreter but that it’s also very unoptimised. So I would assume it’s inferior to the pypy implementation right now.
FYI, this is from 2015 and was deprecated around rust v1.0 release. It’s not a current issue.
As far as I was aware Go didn’t have enums and this
const()
Pattern is just a weird thing people do because it behaves like an enum?
I don’t know where “software engineer” started but in Australia engineers have to study for years and then do a minimum amount of study every year to keep their license. Which we don’t have to do. I’ve always been weirded out by Software Engineer even though it seems to be becoming more common.
Sure, so you just get a fine for obstructing your license plate then.
As far as I’m aware cybercrime is generally: “anything done maliciously involving a computer” intentionally sticking a drop table command over your plates because you’re expecting something to read your plate and input it into a db might count.
Id guess maybe, if I generated a string using AI and intentionally crashed their stuff, it might be crime.
I’d be more worried that this could count as some form of cybercrime.
I’m not sure if the rules are different with macros, I’ve never written one but this lint is generally caused because you set a var to a value and then overwrite that value before you use it. e.g.
let mut a = 1; a = 2; println!(“{}”, a);
This will throw the same warning because 1 is never used, this could’ve just been:
let a = 2; println!(“{}”, a);
So first I’d double check that I NEED last at all. Maybe try:
cargo clippy
See if it can tell you how to fix it.
If that doesn’t work, it’s sometimes necessary to skip certain lints. E.g. if you make a library, most of the code will be flagged as dead code because it isn’t used and you can use an #[allow(dead_code)] to stop the linter warning. You might be able to use #[allow(this_linting_rule)].
Hope something here helps.
I love when I make a small code change and then I make my PR, CI runs and some piece of code entirely unrelated fails and it’s now my job to work out how these two unrelated things are related.
The performance is just a “nice to have”.
Python package management, especially at scale is infuriating. At work we use python microservices in docker containers and it infuriates me trying to update the one our team is responsible for.
I always like to rant that python 3rd party package management tools are a mistake. We should’ve gone for an “as simple as possible” setup instead of all this.
So I’m sceptical of UV on principle since it’s yet another 3rd party package manager but if it can do all of this and not be a nightmare I’ll be ok with it.