What? You can easily escape from it if there are better alternatives you can use. Pointing at one language and saying it is not easy to code like it is another language is a pointless argument. You can do that about any two languages. They all differ for good reasons and as long as you can solve similar problems in both, even if in different ways then what does it matter that you cannot do it in the same way?
You could do a lot of things. Rust had a gc and it was removed so they have already explored this area and are very unlikely to do so again unless there is a big need for it that libraries cannot solve. Which I have not seen anyone that actually uses the language a lot see the need for.
Not like how async was talked about - that required a lot if discussion and tests in libraries before it was added to the language. GC does not have anywhere near as many people pushing for it, the only noise I see is people on the outside thinking it would be nice with no details on how it might work in the language.
So someone that is not involved in rust at all and does not seem to like the language thinks it will get a GC at some point? That is not a very credible source for such a statement. Rust is very unlikely to see an official GC anytime soon if ever. There are zero signs it will ever get one. There was a lot of serious talk about it before 1.0 days - but never made it into the language. Similar to green threads which was a feature of the language pre 1.0 days but dropped before the 1.0 release. Rust really wants to have a no required runtime and leans heavy on the zero-cost abstractions for things. Which a GC would impose on the language.
There are quite a few places where a GC is just not acceptable. Anything that requires precise timing for one. This includes kernel development, a lot of embedded systems, gaming, high frequency trading and even latency critical web servers. Though you are right that a lot of places a GC is fine to have. But IMO rust adds more than just fast and safe code without a GC - lots of people come to the language for those but stay for the rest of the features it has to offer.
IMO a big one is the enum support it has and how they can hold values. This opens up a lot of patterns that are just nice to use and one of the biggest things I miss when using other languages. Built with that are Options and Results which are amazing for representing missing values and errors (which is nicer than coding with exceptions IMO). And generally they whole type system leads you towards thinking about the state things can be in and accounting for those states which tends to make it easier to write software with fewer issues in production.
but imagine if you have to perform this operation for an unknown amount of runtime values
This is a poor argument. You dont write code like this in rust. If you can find a situation where it is an actual issue we can discuss things but to just say imagine this is a problem when it very likely is not a problem that can be solved in a better way at all let alone a common one is a very poor argument.
Typically when you want an escape from lifetimes that means you want shared ownership of data which you can do with an Arc. Cow and LazyLock can also help in situations - but to dismiss all these for some imagined problem is a waste of time. Comes up with a concrete example where it would help. Very likely you would find another way to solve the problem in any realistic situation you can come up with that I would suspect leads to a better overall design for a rust program.
I would say this is just a straw man argument - but you have not even created a straw man to begin with, just assume that one exists.
For someone only on chapter 7, this is ok. I would not call it idiomatic but you have not gotten to the Error Handling in chapter 9 yet. I would probably hold on getting feedback on error handling until you have gotten to that point.
But the TLDR of it is rust has two forms of errors, unrecoverable errors in the form of panic and recoverable ones in the form of returning a Result. In this case you have opted for panicking which IMO is the wrong choice for something that is expected to fail - and http requests and parsing external data is expected to fail (even if only some of the time). Networks fail all the time, servers go down, send back wrong responses and many other things.
Do you really want to crash your program every time that happens? Probably not - at least not at this level. Instead you likely want to return an error from this function and let the caller deal with it instead as they will likely have more context as to what to do with it rather than in the leaf functions of where the error originates.
But all that is probably for once you have read through chapter 9. For now it is good to know that when you have the pattern
match foo {
Ok(value) => value,
Err(err) => panic!("it broke! {}", err),
}
You can generally replace that with a call to expect instead:
foo.expect("it broke")
Or just unwrap it if you dont need to add more context for what ever reason.
It doesn’t technically have drivers at all or go missing. All supporting kernel modules for hardware are always present at the configuration level.
This isn’t true? The Linux kernel has a lot of drivers in the kernel source tree. But not all of them. Notably NVIDIA drivers have not been included before. And even for the included drivers they may or may not be compiled into the kernel. They can and generally are compiled with the kernel but as separate libraries that are loaded at runtime. These days few drivers are compiled in and most are dynamically loaded depending on what hardware is present on the system. Distros can opt to split these drives up into different packages that you may or may not have installed - which is common for less common hardware.
Though with the way most distros ship drivers they don’t tend to spontaneously stop working. Well, with the exception of Arch Linux which deletes the old kernel and modules during an upgrade which means the current running kernel cannot find its drivers and stops dynamically loading them - which often results in hotplug devices like USB to stop working if you try to plug them in again after the drivers get unloaded (and need a reboot to fix as that boots into the latest kernel that has its drivers present).
I don’t get it? They seem to be arguing in favor of bootc over systemd because bootc supports both split /usr and /usr merge? But systemd is the same. There is really nothing in systemd that requires it one way or another even in the linked post about systemd it says:
Note that this page discusses a topic that is actually independent of systemd. systemd supports both systems with split and with merged /usr, and the /usr merge also makes sense for systemd-less systems.
I don’t really get his points for it either. Basically boils down to they don’t like mutable root filesystem becuase the symlinks are so load bearing… but most distros before use merge had writable /bin anyway and nothing is stopping you from mounting the root fs as read-only in a usr merge distro.
And their main argument /opt and similar don’t follow /usr merge as well as things like docker. But /opt is just a dumping ground for things that don’t fir the file hierarchy and docker containers you can do what you want - like any package really nothing needs to follow the unix filesystem hierarchy. I don’t get what any of that has to do with bootc nor /usr merge at all.
You might want to checkout rust-script which essentially does the same but also lets you use it as a hashbang line to make executable rust scripts. And works with cargo/can install deps.
There is also an RFC for this feature.
TLDR; yes it does affect security. But quite likely not by any meaningful amount to be worth worrying about.
Any extra package you install is extra code on your system that has a chance to include vulnerabilities and thus could be an extra attack vector on your system. But the chances that they will affect you are minuscule at best. Unless you have some from of higher threat model then I would not worry about it. There are far more things you would want to tackle first to increase your security that have far larger effects than a second desktop environment being installed.
So, why wait for windows 10 EOL? If you are already mostly on Linux and are planning on getting rid of the last bits anyway? If you really need to you can always reinstall windows on a second disk or in a VM later on if you really need to - no real need to preemptively do that if you dont plan on using it.
If you have everything you need backed up you can reinstall on a new hard drive and restore everything you need. So you should not be completely fucked. Just an inconvenience you might have to go through. You will lose the stuff not backed up so if any of that is a pain to get again it might be more painful to restore everything.
Others have said some thing you might want to try. But having a spare disk you can swap to is never a bad idea. Disks to fail and you should plan for what to do when they do. Backing up your data is a good first step.
I would say it is not a bad idea to just get a new disk now and go through the process of restoring everything anyway - you can treat it like your disk has failed and do what you would need to do to restore. With the ability to swap back when you need to.
This is a good way to find things you might have missed in your backups.
Not if you have backed up your data. You have a backup of your data right?
Why wait? Start using Linux friendly software in your day to day workflows. Then start to dual boot Linux with your current system and start using it more and more. By the time windows 10 reaches EOL you will know if you still need a Windows install or not.
And given some recent news about Valve working on an ARM emulator and funding Arch Linux to help them start supporting ARM as well they might be working towards that. Though if that is for the deck 2 or something else further in the future is yet to be seen.
The only other major thing for repairability/upgradability would be less glue on the battery and threaded inserts, which doesn’t add size.
The glue was reduced on later versions and especially on the OLED version which also got threaded inserts. So those are already done and I doubt the next version would regress in that regard.
And then relabel all the old standards when they create a new one so every generation you need to figure-out what al the new names mean.
I thought they both had to stop the world at some point. And the advancements were about running more of the GC steps in the background to minimize the time needed in the stop the world phase.
When people want memory safety, it’s exactly because they don’t want a garbage collector.
Everyone should want memory safety and garbage collection is a form of memory safety. A form that enforces the safety at runtime and comes with a steep cost there. People use unsafe languages not because of their lack of safety but because they don’t want to pay the costs involved.
Even rust has a cost - but that is on the compiler and developer instead of at runtime. Rusts memory safety makes the compiler and language a bit more complex so is a bit more to learn to get a program to compile - which is a cost to the developer. Though IMO it does make it easier to write correct code.
Memory safety without a runtime cost is what rust is selling.
Whaaatt!?!!? That sounds like you don’t use git? You should use git. It is a requirement for basically any job and there is no reason to not use it on every project. Then you can keep your projects on a server somewhere, on your NAS if you want else something like github/gitlab/bitbucket etc. That way it does not really matter about your local projects, only what is on the remote and with decent backups of that you don’t need to constantly archive things from your local machine.