Have you tried updating and rebooting your system? I have had this happen a few times and almost always that is what fixes it for me (more so the rebooting but it is generally good to have your system up to date). Other times it is typically something missing on your host system (like properly installed drivers), though if the game was running before then this is less likely to be the issue and a reboot is typically enough - so start with that.

a hearing doc won’t be much help with anything aside from hearing

Irrelevant to my argument. All I mean is because they go to visit someone for one problem can mean they visit other people for other problems they have - rather than ignoring things and staying at home. And I am not claiming what I said to be the actual cause - at least no more than what the study can claim. There could be many other factors at play here as well. My only point is to not confuse causation for correlation and that these types of studies are almost useless in what they tell us.

Hell, even spurious correlations happen all the time. You cannot use two graphs looking similar to prove any point without a lot of control for all the other variables that might be at play and not go looking at large amounts of data for anything that might seem interesting.

“We found that adults with hearing loss who regularly used hearing aids had a 24% lower risk of mortality than those who never wore them,” said Janet Choi, MD, MPH, an otolaryngologist with Keck Medicine and lead researcher of the study. “These results are exciting because they suggest that hearing aids may play a protective role in people’s health and prevent early death.”

While the study did not examine why hearing aids may help those who need them live longer, Choi points to recent research linking hearing aid use with lowered levels of depression and dementia. She speculates that the improvements in mental health and cognition that come with improved hearing can promote better overall health, which may improve life span.

This is the classic causation vs correlation problem with these studies. I can also speculate: Did the hearing aid actually do anything at all - or do the people that go to the doctors for a hearing aid also go to the doctors for other problems they might have and so get more treatment for other conditions? That seems far more likely to have a bigger effect IMO.

I suspect the answer for most people is habbit. It is what they are used to and have always done.

Personally I lean towards more linear history as it creates a cleaner commit graph and is close enough to what really happened and the exact details of small meaningless commits and merges that were created during development of something don't matter that much. If anything they add a lot of noise to commit graphs that make it harder to see what actually happened and when. I have seen code bases where the git commit graph takes up more than a full screen to render because of all the merging and it is not fun to navigate to understand what happened at some point.

Far nicer to just step back in a mostly linear history that jump around back and forth on various difference branches and merge commits. Even if it is not technically what really happened during development - as generally I only care what happened when something was merged into master, not on individual branches.

But I also prefer to work on small feature sets at a time and frequently merge back into master and not spend weeks or months working on a different branch that contains loads of changes not yet in master. My goto command for pulling from upstream is git pull --rebase=interactive --autostash origin master (no need to fetch with a pull, though my local master tends to get behind origin - not that it matters) and I will quite often git commit --amend or squash/reorder/edit things to give a simpler history before creating a PR.

But at the same time, on smaller projects it really does not matter that much. Follow the conventions of the projects you work on and do whatever you want on your own projects.

TBH, I find the whole premise a bit silly. The one use case the original video talks about there this might be a good idea is when you have something like a MonsterId(String), and argues for MonsterId(Arc<str>) instead - which I think is an anti-pattern. Use MonsterId(usize) and it becomes far cheaper to clone than even an Arc<str>. There is no need to lug around strings as ids - which are presumably going to be used to look up values in a hashmap or similar (which again, I would suspect it is faster to has a usize than a string of any type).

Most of the rest of the time cloning a string is not a huge issue or if it is &str is often good enough. I find it rare that you would ever need the clone performance and multiple ownership of a Arc<str>.

There are also crates like smallstring, smallstr etc, that are stack allocated strings up to a certain limit before they start allocating. Which would be worth a look at and see how they preform compared to Arc or String. Since most things I bet they were using Strings for would fit inside these types just find without the extra allocation.

It is a neat trick to have in your toolbag - but not the first thing I would jump for when dealing with strings.

We spent much of the year fighting these dangerous “child safety” bills, while also pointing out to legislators that comprehensive data privacy legislation would be more likely to pass constitutional muster and address many of the issues that these child safety bills focus on.

Because they don't actually care about child safety. massive online censorship and surveillance is the goal here - kids are the excuse they are using to try and get it to pass as it has no hope in hell without some sort of mask on it. The only things they ever do for children is banning abortions and erode privacy. Never anything that would actually help, like feeding them in school, or better prenatal support and leave at work, or medical insurance for everyone. Instead they fight against these measures and for things that won't help children in the slightest.

I shouldn’t expect remote accessing some random server will allow me to use Helix, right? Is there any other way to make this work? Or…, should I just learn both Vim and Helix’ Vim + Kakoune amalgamation?

That all depends on the server in question and if you can install things onto it or not. Some points to consider though:

• If the server is restrictive on what you can install then you likely are stuck with basic vim or worst only vi - and without all your configs it is a very different beast of an editor anyway and something you will need to get used to everytime you jump on the server.
• If you can install stuff to your home drive then it is quite easy to get helix running - it is a single binary with some language assets (requires one env var to point to them). So is trivial to get working from your home dir without a package manager.
• IMO you should not be editing things on a server often enough to worry too much about what editors it has on it. Ideally with things like ansible you should not need an editor on it at all.

Vim is literally ubiquitous and plugins that enable its features can be found on almost any ‘platform’. It’s unrealistic to expect Helix’ adoption to be at that rate (yet). However, would you happen to know if at least the likes of VS Code and/or Jetbrains’ IDEs support it? And if so, how good their support/implementation is?

Do you mean vi input mode in other editors? That is one downside - you wont find it anywhere yet. Though since learning it I have not needed to go back to other IDEs like VS Code or Jetbrains, WIth inbuilt LSP support its language integration is just as good as VS Codes as it is working off the same essential language servers. Though it does seem that at least vscode has a plugin for kakoune keybindings which are more similar to helixs.

Though what you will find is a lot of the keys are very similar between vi and helix, so apart from the big action > movement vs selection > action and a few other things they dont feel too dissimilar from each other (things like basic movement, ie w for word, e for end of word, or text objects are essentially the same).

deleted by creator

Interesting. Though I can definitely see where you’re coming from. Uhmm…, have you used any of the Neovim distributions to make maintenance easier?

I have, but dont like them. They all have weird install processes and need to manage their own set of configs on top of vim in your home dir. This makes them very hard to properly package or integrate with config management tools and require a different flow to keep them up to date from the rest of your system. They combine sometimes hundreds of plugins, of which only a few are designed to work together and while a lot don't try to step on each others toes that many I often find issues in niche use cases. And when you do find an issue, or something you want to tweak you have 100s of plugin configurations that you need to learn about to figure out just what is doing what and which options you need to tweak.

It is all just far more hassle then I want out of my editor these days. Helix just works out the box and has basically everything I want from a editor nicely integrated into it.

As you’ve touched upon it; Helix’ keybindings and ‘sentence-structures’ are different to those found on Vi(m).

They are a little different and take a bit to get used to. But IMO I find them far nicer way to work. It is very nice being able to see what your action is going to effect before you do it - unlike in vim when you just hope you have hit the right movement keys. And it also pops up a small window for leader keys (like space) which show you what you can do with it making it far more discoverable then vim/neovim without needing to pour though hundreds of pages of manuals to even get a glimpse of what it can do or needing to go back to them to remember something that you dont use very often. It is not trying to be a 100% vim compatible layer, it is trying to give you the best experience it can out the box. And I think it does that quite well (at least once you get used to the new way of working - which does not take that long).

Furthermore, neither of the two have existed long enough to be able to profess any statement regarding their longevity. Like, there’s no guarantee that I can keep using either of the two 20 years into the future.

20 years is a long time. I can see it existing for the next 5 years at least, and looks to be on the trajectory to be a long lasting product. Though no one can say for sure. But, the more people using it the more likely it is to stick around for the long term. Just about everyone that I have seen use it over vim have highly praised it and it has quite a few contributors already (700+ on github), which is very impressive compared to vim (about 300), and neovim (more then 1100).

And keep in mind that vim has been around so long thanks to a single maintainer, Bram Moolenaar, who passed away this year. Which is not a great sign for vims future for the next 20 years.

I appreciate the input, but I simply don’t want to invest in a program whose future is very unclear to me at this point in time.

The investment in helix is far less then that you need to put into vim/neovim due to all the configuration you need for them. Well worth it for how active it currently is and how many people are putting effort into it.

I have used vim/neovim for years and cannot go back to a non-modal editor. But TBH I got sick of its configuration. You need far too many plugins and config to get things into a sane working order to be usable on a day to day bases for any type of development. It takes ages to learn and become as productive as you were before and a lifetime to refine.

For the past year or so I have switched to helix and don't plan on going back to vim/neovim as my main editor ever again. It is a modal editor that is a mix between Neovim and Kakoune editors. It comes with batteries included, and supports an IDE like experience out the box with treesitter syntax highlighting and LSP language integrations out the box. My whole config is like 6 lines long yet it works far better then my old neovim setup with a multitude of plugins and hundreds of lines of config. It is like what AstroNvim, LazyVim, LunarVim and NvChad etc are trying to do to vim/neovim but instead has built in support for all the things they rely on plugins for. Which means there is no need to constantly keep them up to date nor weird edge cases where one plugin does quite integrate with another smoothly. It is all built in so things are designed to work well together.

But it currently does lack any plugin support. So if something is not built in that you want you have to make due without it (well, except language support, adding new LSPs is not too hard). And plugin support is being worked on so even this will be a non-issue hopefully in a year or two.

Yup, a big excuse I used to see a lot was

I would like to run Linux, but I want to game more so will stick to Windows

And this has changed a lot with what valve has done which opens Linux to a much larger market of people that can now use it for their usecases.

Rust, it is a pleasure to work with and far more flexible in where/what it can run then a lot of languages. Good oneverything from embedded systems to running on the web. Only really C and C++ can beat it on that, but those are farlesss pleasant to work with. Even if it is not as mature in some area quite yet, it just gets more support for things as time goes on.

No it is not ment to be empty. You will need to reinstall it to fix that.

Best to not think of files as modules. Instead a rust crate is just a tree of modules with the src/main.rs or src/lib.rs being the main entry point.

Inside these files you define the module structure you want like:

mod foo {
    mod bar {}
}

This creates two modules, crate::foo and crate::foo::bar. Now, because you don't want to have all your code in main.rs/lib.rs rust lets you move the module contents to separate files. But the location of the file needs to match its location in the module structure - from the crates root (not the file it was declared in).

So when you call mod foo; from src/main.rs it will look for src/foo.rs or src/foo/mod.rs (and you can only have one of these). And the foo::bar - no matter if that is declared in src/main.rs (as above) or inside src/foo.rs or src/foo/mod.rs, it will always look for the bar module contents inside src/foo/bar.rs or src/foo/bar/mod.rs as it is nested inside the foo module - not because the file is next to the current one.

This means if you had this inside main.rs/lib.rs:

mod foo {
    mod bar {
        mod baz;
    }
}

Then it will look for the baz module contents inside src/foo/bar/baz.rs or src/foo/bar/baz/mod.rs - even though those might be the only two files you have.

8,000 characters in five hours is 1,600 characters per hour, or 27 characters per minute.

This is irrelevant. Typing when coding is not evenly spaced out over those 5 hours. It is sporadic with most of the time thinking or reading documentation or reading source code and trying to figure out what you want to type. No good conclusions can be drawn from this logic and makes that whole part of the argument irrelevant.

If I were typing that slowly I would quickly forget what the hell I was even trying to do in the first place. Which is the bigger part - when you do need to type you want to quickly get the ideas you have down as fast as you can think them. Going too slow can cause your mind to wander and that can really hamper your productivity.

There is also the cost of context switching. And it is a context switch to go from writing ideas down to making sure I have all the boiler plate and syntax correct. The less of the need for doing that the better IMO.

And TBH I don't really understand the rest of their arguments. They introduce two bits of code, one very short simple class then one with lots of helper methods to set various things while creating a new object. And then concludes with a short paragraph on some real benefits without really explaining why. With the whole paragraph being more of an argument about immutable code being better rather than longer vs shorter code. Then follows up with an entire section on why his code increases maintenance as refactoring requires more points to update with his immutable code and thus prefers languages like F# where the immutable version is a one liner... Which defeats the whole argument that typing is not the bottleneck? I really don't follow his logic here.

Apparently, it has to be explicitly stated: Programmer productivity has nothing to do with typing speed.

I feel they have completely failed to convince me of this fact. Despite me already thinking it is not one of the more important factors of productivity and there are better things to optimise around.

My opinion is that code length is not that important a factor, but you should not go hog while and write the longest things you can either. Every extra bit of code should add some value somewhere. Like taking his examples, spending a bit of time writing the immutable version here lets you reduce the amount you need to write when using that code. Which is a trade-off that can be worthwhile - increasing typing now for reducing typing later. But also the reduced typing makes the where the code is used easier to read and clearer as to what is happening, get a copy of the object with one field updated. That is a nice concept to have and read. Without the need to refer to all the fields every time you want a copy.

for larger or more intricate shell scripts

Those are call applications. Use any language you like. If go/rust is what you know use them. I use rust all the time for things beyond run a bunch of commands and tends to be my go to when I need to process data in any way.

There was that time where one dev broke the internet by deleting one simple NPM package.

Or the thousands of malicious packages that are removed every year?.

The node_modues dir also becomes massive as it needs to download hundreds of repos including readmes, tests, and other cruft for what is often only a few lines of code. And it used to need to download the same libraries many times for every dependency that needed to use it (not as big a problem now that they are flattened by NPM first).

The node_modules dir also breaks sometimes needing you to just delete and recreate it.

It automatically runs install scripts when you download a package (and all it's dependencies) by default which breaks a lot of packages if you disable them.

It has improved over the years and some of these are no longer issues, but they have all contributed towards people's dislike for NPM. The overall idea for having a file tell you what deps are needed and to download those deps is not a NPM exclusive idea and most if not all modern languages do the same thing. Even older languages have started to adopt similar tooling. Some share some of the issues NPM has, though others have improvements over it as well.

But these are developer tools design for developers and build systems to use. Not really ideal for end users. Especially for compiled language. But even for NPM, you don't want to be shipping a full node_modules dir to all your end users nor do you want them to have to install your language tooling every time. It be more ok for developers that are already working in the language or sysadmins deploying to a server, but for the average desktop user it is not a good experience.

I am not sure there is any killer feature that you cannot do in a cli application. It is just a different way of working. Slightly better at some things slightly worst at others. But the biggest difference is what you are used to more then and single feature set.

Though I don't personally use them, I also use a shell with a lot more interactive features built in then default bash does. If I where stuck with only default bash maybe I would lean more towards them. But that is just the way I work, others work differently then ai do.

All you get is a watermark in the corner

Well, that is a consequence. Just not a very big one. You also cannot change the background in the settings, though that is also a very small consequence. Yeah, they are only small and you can likely live with them, but small and tolerable are not zero.

there will be a subscription “premium” version like in any app that removes ads and enables AI features.

This makes me glad I no longer use it. An OS should not have ads baked into its core and there should not be a subscription for it.

Rust however… are Arc, Box, Rc, async, etc. fine?

Yes, these are all fine to use. When you should use them depends on what you are doing. Each of these has a usecase and tradeoffs associated with them. Rc is for when you need multiple owners to some heap allocated data in a single threaded only context. Arc is the same, but for multithreaded contexts (it is a bit more expensive than an Rc). Box is for single owner of heap allocated data, async is good for concurrent tasks that largely wait on IO of some sort (like webservers)

match or if/else?

Which ever is more readable for your situation. I believe both are equally powerful, but depeding on what you are doing you might find a simple if let enough, other times a match makes things a lot more succinct and readable. There are also a lot of helper functions on things you often match on - like Result and Option that for specific situations can make a lot more readable code. Just use which ever you find most readable in each situation.

How should errors be handled?

This is a large topic. There is some basic advice in chapter 9 of the book though that is mostly about Result vs panic. There are also quite a few guides out there about error handling in rust in a broader sense.

Typically they suggest using the thiserror crate for errors that happen further from main (where you are more likely to care about individual error variants - ie treating a file not found differently from a permission denied error) and the anyhow crate or eyre crate for errors closer to main (when you are dealing with lots of different error types and don't care as much about the differences as you typically want to deal with them all in the same way when you are near to main).

Also the fact that there is no inheritance leads to some awkward solutions when there is stuff that is hierarchical or shares attributes (Person -> Employee -> Boss -> … | Animal -> Mammal-Reptile-Insect --> Dog-Snake-Grasshopper).

I have rarly seen a system that maps well to an inheritance based structure. Even the ones you give are full of nuances and cross overs that quickly break apart. The classic animal example for instance falls flat on its face so quickly. Like, how do you organise a bird, a reptile, a dog, a fish and a whale? You can put the whale and dog under mammal, but a whale shares a lot of things with the fish, like its ability to swim. Then think about a penguin? It is a bird that cannot fly, so a common fly method on a bird type does not make any sense as not all birds can fly. But a penguin can swim, as can other birds. Then just look at the platypus... a mammal with poison spurs that swims and lays eggs, where do you put that? Where do you draw the lines? Composition is far easier. You can have a Fly, Swim, Walk etc trait that describe behaviour and each animal can combine these traits as and when they need to. You can get everything that can fly in the type signature, even if it is a bird, a bat, or even an insect. Inheritance just cannot do that with the number of dimensions at play in any real world system.

IMO it is simpler and makes more sense to think in terms of what something can do instead of what something inherits from.