Fish is a great shell, but whenever I SSH into another machine I end up having to do everything in Bash anyway. So the fact that Fish is so different often ends up being a detriment, because it means I have to remember how to do things in two different shells. It was easier to just standardize on Bash.
I might try daily driving it again when this release hits the stable repos, I dunno.
Same. That's why I stick with zsh, even though I know Fish has better features, and I would really like to learn fish. I log into many different VMs every day, they all use Bash, some also have zsh. None of them have Fish.
I only have to "quotes" strings that contains globs. The rest mostly work or use the newer/recommanded way to do things for posix shells.
But I must admit, I only use it interactively. For scripts I #!/bin/{,ba}sh. I will use something else once it won some/most the distro preinstalls (either nu, elvish, fish, but for now it's sadly python).
I would want to continue to write my scripts with sh or bash, but is this something worth adopting for just regular shell navigation?
I've thought about it previously but it not being a default shell makes it reasonably less appealing for me.
As long as you use bash in your shebang you won't know the difference. Fish even has conventions for applying environment variables to be available in both shells. I've used Fish for a couple years and my biggest gripe (which is still minor) is that command snippets off the Internet don't always work. In those cases I either switch to bash temporarily or fix the command to work in Fish.
Most of the time the fix is: put quotes around your strings (especially when they may contains globing patterns). Sometimes its using newer syntax available in bash but not on the snippet.
I'll check it out then. Work involves using bash exclusively because it's embedded systems but I'll see if fish suits me for personal use. Thanks for the suggestions
I felt that way too, but testing it for a few days on one device changed my mind. Their pitch rings true, it has so many basic QoL features that make you wonder why this wasn't added to bash two decades ago.
For me, the only bash->fish gripe I've had was it took me a little while to get used to having to put quotes around URLs with a ? to stop it trying to wildcard, but again, their rationale makes perfect sense and really I admit it was bad for bash to simply accept that string in the first place.
I just set Fish as the shell that my terminal emulator should launch. The actual default/system shell can stay Bash. And then, yeah, if you put Bash into the shebang, all the scripts will run with it, and you can just execute bash in your Fish shell at any point to drop into a Bash shell.
Occasionally, I'll realize some syntax discrepancy where I've kind of learned it the Fish way, but because I'm only using Fish interactively, there's really not a ton of syntax that I'm interacting with.
And yeah, ultimately I find it well worth it. In particular the history-based auto-suggestions are really useful. People will ask me what that command was again and I'll start typing into my shell and it just pulls out exactly what I wanted in quite a lot of cases.
The compiler grows on you after a bit and generally if you're fighting it, it's trying to prevent you from shooting yourself in the foot. I've heard it depends on what languages you're coming from. Most of my experience is with higher level languages like JavaScript so the issues I ran into while learning rust were opportunities to get a deeper understanding of computers in general.
I could see that being frustrating if you're coming from C/C++ and just want the dang thing to do what you already know how to do.
The way I look at it is that most of my time spent fighting with the compiler is usually made up for in time saved debugging. I'm in the process of RIIRing a hobby project and so far most of the ported code just works, and I only end up needing to fix a few dumb logic mistakes before it's fully up and running.
Yeah, Rust tries to find as many problems as it can during compilation. It's great for those of us who want the bugs to be found ahead of release, not great for those who just want something out the door and worry about bugs only after a user reports them.
Different platforms have different values, and that also affects what people consider fun. At the other end of the scale you find the triple-equals languages like js and php, which a lot of people think are fun and normal, but some of us think are so wobbly or sloppy that they're actually much harder languages than other, stricter languages.
If you value correctness and efficiency, Rust is pretty fun.
Yes, it's because it keeps track on object lifetimes and data access when sharing objects, even across threads. It means that once things compiles a whole category of common and often difficult to debug errors are gone. It means much less time debugging and fewer issues once in the hands of the end user. There can still be bugs but it's more about logical errors than difficult memory issues.
As a C++ dev for 20 years, I love Rust. Humans are fallible, even if endeavouring to use safe patterns. Might as well just let the compiler use some CPU cycles on that.
I think new projects in Rust make sense but my - uninformed - opinion is that we should be wary about porting old C/C++ software due to those other classes of bugs you mentioned. The logical type errors I see at work and in open source projects using memory safe languages can be fiendish in their own way.
Rust is amazing. I've been using it for six years now. Being strict is exactly what you want when building anything more complex than fizzbuzz. It's just that people aren't used to it so it makes them uncomfortable enough to not attempt to learn it or see how beneficial it is.
I don't want to start a holy war. but they say it should bring more contributors and a more fun programming language should mean more contributions but contribution metrics on openhub show no meaningful improvement IMO.