I did that on purpose, i. e. I wanted to confirm your thoughts about uv, drifted off into a general rant, remembered OP’s original question and later realized it would have been better framed as a top level comment. In my defense, I was in an altered state of mind at the time.

pyenv and uv let you install and switch between multiple Python versions.

As for uv, those come from the Python build standalone project, if I remember correctly, pyenv also installs from there, but don’t quote me on that.

I moved all our projects (and devs) from poetry to uv. Reasons were poetry’s non standard pyproject.toml syntax and speed, plus some weird quirks, e. g. if poetry asks for input and is not run with the verbose flag, devs often don’t notice and believe it is stuck (even though it’s in the default project README).

Personally, I update uv on my local machine as soon as a new release is available so I can track any breaking changes. Couple of months in, I can say there were some hiccups in the beginning, but currently, it’s smooth sailing, and the speed gain really affects productivity as well, mostly due to being able to not break away from a mental “flow” state while staring at updates, becoming suspicious something might be wrong. Don’t get me wrong, apart from the custom syntax (poetry partially predates the pyproject PEP), poetry worked great for us for years, but uv feels nicer.

Recently, “uv build” was introduced, which simplified things. I wish there was an command to update the lock file while also updating the dependency specs in the project file. I ran some command today and by accident discovered that custom dependency groups (apart from e. g. “dev”) have made it to uv, too.

“uv pip” does some things differently, in particular when resolving packages (it’s possible to switch to pip’s behavior now), but I do agree with the decisions, in particular the changes to prevent “dependency confusion” attacks.

As for the original question: Python really has a bit of a history of project management and build tools, I do feel however that the community and maintainers are finally getting somewhere.

cargo is a bit of an “unfair” comparison since its development happened much more aligned with Rust and its whole ecosystem and not as an afterthought by third party developers, but I agree: cargo is definitely a great benchmark how project and dependency management plus building should look like, along with rustup, it really makes the developer experience quite pleasant.

The need for virtual environments exists so that different projects can use different versions of dependencies and those dependencies can be installed in a project specific location vs a global, system location. Since Python is interpreted, these dependencies need to stick around for the lifetime of the program so they can be imported at runtime. poetry managed those in a separate folder in e. g. the user’s cache directory, whereas uv for example stores the virtual environment in the project folder, which I strongly prefer.

cargo will download the matching dependencies (along with doing some caching) and link the correct version to the project, so a conceptual virtual environment doesn’t need to exist for Rust. By default, rust links everything apart from the C runtime statically, so the dependencies are no longer neesed after the build - except you probably want to rebuild the project later, so there is some caching.

Finally, I’d also recommend to go and try setting up a project using astral’s uv. It handles sane pyproject.toml files, will create/initialize new projects from a template, manages virtual environments and has CLI to build e. g. wheels or source distribution (you will need to specify which build backend to use. I use hatchling), but thats just a decision you make and express as one line in the project file. Note: hatchling is the build backend, hatch is pypa’s project management, pretty much an alternative to poetry or uv.

uv will also install complete Python distributions (e. g. Python 3.12) if you need a different interpreter version for compatibility reasons

If you use workspaces in cargo, uv also does those.

uv init, uv add, uv lock --upgrade, uv sync, uv build and how uv handles tools you might want to install and run should really go a long way and probably provide an experience somewhat similar to cargo.

It’s not like Bluetooth started demanding location permissions, the conceptual model of the permission was revised: having access Bluetooth means an app could determine your location via a form of lateration.

In earlier versions of smartphone operating systems, this was not transparent to users lacking the technical background, so Bluetooth also requiring location access is actually an attempt at making users aware of that. I’m not an iOS developer, so I can’t comment on iPhones, but on Android versions prior to 11, having access to Bluetooth meant an app would be able to determine your location.

Today, you can require the permission ACCESS_FINE_LOCATION, which expresses that your app might use Bluetooth to obtain location information on Android. Also, if you’re just scanning for nearby devices to connect your app to, but don’t want users to be confused why your smart fridge app needs to know your precise location, you can declare a permission flag (neverForLocation) and Android will strip beacon information from the scan results, better asserting your intentions.

So, overall: no, there is nothing nefarious going on, it was always possible to determine your location via Bluetooth, and the update to the permission model was an honest improvement that actually benefits you as user.

Now, there are still plenty of shady apps around, and apps that are poorly written - don’t use those.

What’s a good way to financially support artists directly, without involving shady corporations, and without resorting to piracy?

This, however, is about diagnostics, i. e. annotating delete with a reason (message) to express developer intent when deleting a function, not about memory management.

Side note: please don’t abuse the word “toxic” until it becomes absolutely meaningless. Let’s keep that to a more fitting context, having a

I was expressing an obviously personal opinion about the language itself, which is objectively a dull, barren wasteland that sucks out your soul while you walk it. That is precisely the reason why it’s so widespread and loved by business entities and managers - there is no excitement, no surprises, just an everlasting monotony of keys clicking produced by a horde of clones wearing button-down shirts while sitting in absolute identical cubicles, creating yet another instance of FactoryProducer. It’s very easy to plan and schedule for, while at the same time being unnecessarily verbose and mildly unproductive (compared to other languages).

Look, the JVM is fine, just pick another language. There is plenty of work doing Kotlin. But yes, if you’re doing this only for the money, go ahead. I’ve always been unable to separate my job fromy personal life and my other interests, I couldn’t imagine being cursed by Java again.

If you can sit somewhere for 8 to 10 hours each day, doing something that isn’t fun and separate yourself from it, not going insane, all the power to you. I also get that not everyone has the luxury of picking their favorite toy and making it their job, but I firmly believe there are options that are not Java.

Now, if you’re one of the rare types that actually enjoys Java, meet me in the closest Denny’s parking lot, I need your cranial measurements.

Please note: this post contains hyperbole and humor. I don’t hate any of you, I just hate Java

My personal recommendation:

• Pick up Python, it’s easy to learn and highly productive. If you also learn fastAPI, you can benefit from highly validated, declarative models to build REST APIs in the backend, well fast. It will yield quick results, you won’t become demotivated and you can pick up a paid project soon.

• Pick up Rust. It’s “in” right now and I get requests from marketing people that know nothing about programming, asking if their project could be implemented in Rust

• Go with memorizing the shell commands first, try to understand git later. Get productive, try to get where you were with e. g. svn or cvs. If you are comfortable, look at something in depth if you have a problem that you can’t solve with the knowledge you have.

• Fuck Java, seriously.

• You have commercial interests, so it is probably wise to look into becoming a fullstack dev to maximize the kind of projects you can do. Look into React, vue.js, svelte. React is probably still the most widely used framework, you’ll quickly do a project with vue.js and svelte is a super interesting look into things to come.

It is, probably. But I did a check before I posted and it did display content from Lemmy. Just pointing out alternatives here.

I think Fedilab should do both:

https://fedilab.app/projects/fedilab/

I share all those opinions, so your rant saved me some potential typing in the future.

On the 8 Pro, the bump is recessed relative to the Otterbox case (given the “tough” Otterbox model for the 8 Pro, no idea what it’s called)

Do you use the phone without a protective case? I find that most cases are designed so that the bump is flush with the back of the case.

That being said, I prefer thicker cases like the Otterbox oder Spigen Tough whatever series, so I could see how such a case would be “too much” for someone.

Based on this comment*, I’ll migrate a large project to bazel now. I’ll report how it goes.

• disclaimer: the comment just pushed me over the edge

No idea where you’d like to use live captions, but n maybe this helps:

https://github.com/abb128/LiveCaptions

I think you’re falling into a bit of a trap here: perfect is the enemy of good. Not everything has to be automated, instead of growing pains, there can also be gains.

Remember, we are currently aiming to get these vehicles on the road, alongside regular drivers. They use sensors and computer vision to read street signs, detect people etc., all with the reaction speed of a machine. What if the in-between product is simply a better driver with faster reaction times? That is the current goal, really - no one wants to automate everything, simply because that wouldn’t be feasible anytime soon.

Yes, again, we’re not there yet and these things are far from perfect. But let’s first just aim to get them good enough, and then maybe just a little better than your average driver.

As for the your proposed business model: we have capable drivers now, why do these business models don’t exist right now? Why is there no fast lane that allows me pay to get to my destination faster? What would the technology of driverless cars introduce that would enable these regulations?

It’s not about everything being automated. We also have to differentiate between early incarnations of autonomous vehicles and the desired, final state.

A manual override will of course be part of early models for the foreseeable future, but the overall goal is for the machine to make better decisions than a human could.

I don’t have any quarrel with life or death decisions being made by a machine if they have been made according to the morals and ethics of the people who designed the machine, and with the objective data that was available to the system at the time, which is often better than what would be available to a human in the same situation.

It’s the interpretation of said data that is still not fully there yet, and we humans will have to come to terms with the fact that a machine might indeed kill another human being in a situation where acting any different might cause more harm.

I don’t subscribe to the notion that a machine’s decision is always worth less than the decision of another entity participating in the same situation, just because it so happens that the second entity happens to be a human being.

Yes, you probably are. Please don’t forget that the current available technology constantly improves, and that we actually don’t see any good examples of self - driving cars that much - the most prominent displays are from Tesla, and they arguably build the worst cars we’ve seen since Ford came up with the assembly line.

The technology used in autonomous vehicles, e. g. sensors, have been used in safety critical application for decades in other contexts, and a machine is capable of completely different reaction times. Also, if autonomous vehicles cooperate in traffic sticking to their programmed behavior, observing traffic rules etc., you will get less reckless driving, with traffic flow becoming more deterministic. These benefits will particularly increase once self-driving cars don’t have to share the road with human drivers.

I would always trust a well-engineered, self-driving car more than one driven by a human.

Disclaimer: I used to work on these things in a research lab. Also, we’re not quite there yet, so please have a little patience.

This comment would be much better if it featured an explanation of your concerns with that particular opt setting.

Hey, much appreciated!