I’d very much welcome a crates.io alternative that doesn’t require github and supports namespacing by username or org. The dependency on a proprietary platform rubs me the wrong way.
I’d very much welcome a crates.io alternative that doesn’t require github and supports namespacing by username or org. The dependency on a proprietary platform rubs me the wrong way.
Thank you. That’s good to know. In my OS architecture lectures, we were introduced to an OS with core bound threads. I can’t remember if it was a learning OS or something that really existed, hence my doubts.
IINM whether it’s “true” parallelism depends on the number of hardware cores (which shouldn’t be a problem nowadays). A single, physical core means concurrency (even with “hyper threading”) and multiple cores could mean parallelism. I can’t remember if threads are core bound or not. Processes can bound to cores on linux (on other OSes too most likely).
So I suppose this is the preferred way to do concurrency, there is no async/await
Python does have async which is syntax sugar for coroutines to be run in threads or processes using an executor (doc). The standard library has asyncio which describes valuable usecases for async/await in python.
and you won’t use At “just” for a bit of concurrency. Right ?
Is “At” a typo?
We learn a little bit everyday. Thanks!
You’re welcome :) I discovered the GIL the hard way unfortunately. Making another person aware of its existence to potentially save them some pain is worth it.
Does it also support writing compiling or exporting to python modules?
Python has a Global Interpreter Lock (GIL) which has been a bane and a boon. A boon because many basic types are thread-safe as actions happen in lock step. A bane because despite having multiple threads, there’s still a master coordinating them all, which means there is no parallelism but concurrency. Python 3.13 allows disabling the GIL, but I cannot say much to that since I haven’t tested it myself. Most likely it means nothing is really thread safe anymore and it’s up to the developer to handle that.
So, in Python, using multiple threads is not a surefire way to have a performance boost. Small tasks that don’t require many operations are OK for threading, but many cycles may be lost to the GIL. Using it for I/O bound stuff is good though as the main python thread won’t be stuck waiting on those things to complete (reading or writing files, network access, screen access, …) . Larger tasks with more operations that are I/O bound or require parallelism (encoding a video file, processing multiple large files at once, reading large amounts of data from the network, …) are better as separate processes.
As an example: if you have one large file to read then split out into multiple small files, threads are a good option. Splitting happens sequentially, but writing to disk is (comparatively) slow task that one shouldn’t wait on and can be dedicated to a thread. Doing these operations on multiple large files is worth doing in parallel using multiple processes. Each process will read a file, split it, and write in threads, while one master process orchestrates the slave processes.
Of course, your mileage may vary. I’ve run into the issue of requiring parallelism on small tasks and the only thing that worked was moving out that logic to a cython and outside the GIL (terrible experience). For small, highly parallel operations, probably Python isn’t the right language and something like Rust should be explored.
Not sure I understand this. Is it a watch clippy
? Or a completely new tool? If it’s new, what does it provide over clippy?
Your post is nearly the epitome of Chesterton’s Fence. You don’t seem to understand why Rust looks the way it does, works the way it does, why it exists, what it’s used for, and what problems it solves, but you’re very happy (or not, which is probably why you wrote this post) to trash it.
There are many responses to your comments that explain things quite well, yet, from what I see, you do not seem to concentrate on those.
And what I quoted is just the icing on top. It looks very much like you have one style of programming and approaching problems (the PHP style of “if it runs, it’s good”) and apply it to every problem. You have used a hammer your whole life and every problem looks like a nail. You can build a good many things with duct tape, nails, and a hammer. It might all do the job well enough for your standards or purposes and at times it might even be the perfect tool for a task.
But now you’ve discovered a screw driver, tried to hammer in a nail, and gotten quite frustrated that it didn’t work well. Instead of considering using a screw, you have tossed aside the screwdriver and decided to yell expletives into the ether.
The ether has responded with explanations, but you have chosen to ignore them all and staunchly hold on to your “screwdrivers are shit” conclusion. Had you said “I’m just blowing off steam, don’t take this seriously”, that’s what it would’ve been. However, you seem quite serious. Or, as I said before, you’re just trolling.
Oh but in rust you learn more about computers/low level concepts, you’re just not good at coding”
Who cares? Coding is a tool to get shit done and I think devs forget this way too often, like if one works easier than the other why does learning lower level stuff matter?
This is pure junior energy. Or trolling, I honestly can’t tell.
Congrats 🙂
pyenv, virtualenv, pipenv, aren’t package managers… they are virtual environment managers / creators and use pip for package management.
I either missed it or it isn’t in the “developer tools” section: how do you connect this to an IDE or editor with an LSP or DAP? The image might have python:3.12 but locally you only have python:3.6 mind you, so it’s not something one can ignore. How do you handle this?
Even this article of the thread states it dropped from 76% to 24% through the introduction of Rust.
If you seriously think:
I’d like to see the water you walk on.
Linux Foundation, this is what could happen if you invested more than 2% in kernel development.
Those new though… Pondrat, poolrat, applejesus 😂 They sure are having fun.
At the same time, I’m becoming more convinced that dev environments should run in VMs or containers. It’s not clear to me if SELinux would help Amy against these kinds of threats.
Oh, this is great! I had a few usecases for this back in the day, but never bothered implementing any of the algorithms myself. Do you use these yourself? (from the name I assume you’re the author?)
Oh wow… This might be what the rust in Linux people need to switch to. Fuck all the LKML bullshit, fuck mailinglists, fuck C, fuck the shitty tooling and hodgepodge of languages. This looks amazing. Seriously, cargo run and the kernel starts up in a VM? How friggin cool is that?
Wow…
Again, the Linux kernel needs more funding. For crying out loud, these kinds of people holding back progress should be made obsolete (by bringing in and paying talent that is willing to work towards a brighter future with less memory errors, a sane tech stack with better tooling, and better processes). Holding back progress because of their incessant pearl clutching “but my dearest C!!!” Just hurts everybody and impedes progress.
Of course blindly adding the latest and greatest is asking for trouble. Assessing risk, weighing options, making a plan and continuously assessing impact is definitely important, but straight up blocking the road on principle is extremely unproductive.
Ah shit… I always assumed it was just a nix timestamp. What’s the use of storing the timezone? :/
Nearly expected. The Linux Foundation doesn’t spend nearly enough money on the linux kernel to get new blood into it willing to contribute what is necessary (in this case Rust).
Is that a problem with java? In fact, is it even a problem on github where repos are namespaced by user or org?
Anti Commercial-AI license