GUI git clients are amazing in the hands of expert users, but terrible for any newcomer that has to actually use Git (and it's not like a designer checking out the source once or twice a month).
The gripe I have is that unless you expose people to CLIs early on, they will just not learn how to use a CLI at all. Whenever something inevitably breaks badly due to GUIs abstracting away how git really works in favour of a nicer UX, they'll end up asking someone that know Git how to fix their mess. And then, it's too late - they already know how to be productive-ish with git and how to deliver something. They can't justify investing time into learning the CLI (especially if they're not that great with Powershell or UNIX shells) so they constantly keep leaning on a colleague instead of learning.
This is not an hypothetical scenario - this really happened regularly at a place I worked at. Innumerable internal training lessons on Git went wasted due to people forgetting everything immediately by using Fork instead of the shell, and then pestering a handful of senior devs. Once IT banned Fork people were forced to use the terminal more often, so they had to learn how to use git for good and actually retained that knowledge via muscle memory.
The adage I've learnt over the course of the years is that the majority of people will go to any length to avoid learning new stuff. It's mentally less tiring to either waste their time doing stuff in an unproductive way than learning new things. IMHO it's better to force people to learn stuff the "right way" early on than let them pick up bad habits and then having to correct them later.
As a decade-long user and as a professional C++ developer, I'm so happy they've managed to successfully port the shell to Rust. While I have a lot of fun writing C++ (and Rust), I must admit that Rust is vastly nicer to use.
People can complain as much as they want about the borrow checker, but you basically have to be as strict as Rust is in C++ if you want to really avoid use-after-free issues, ... I've been writing "Rusty C++" since before Rust was a thing, because that's the only sane approach to memory safety. I'd rather have a program check that I don't fumble up instead of running sanitizers when things go awry (often years later). The best bug is a bug that can't happen at all.
Static analyzers are sadly too limited compared to what a borrow checker can do in my experience. Some bad stuff will always slip in in C/C++.
I still do LAN parties every once in a while with a group of friends. Meeting in the same room with laptops and bulky desktop PCs to play old 00s games is still a lot of fun!
C++, especially before C++11, was a total mess. Even today, it's super easy to shoot yourself in the foot and you literally can't learn the entirety of the language due to how massive it is. This still doesn't justify doing the absurdity of macro magic and garbage I've seen people pumping out in C over the years though.
IMHO if you deliberately use C it's because you want to keep things simple. Sometimes C++ will inevitably lead to overcomplicated designs nobody needs; there's a reason why 90's C++ feels massively outdated, while 90's C is still (mostly) accessible.
C is a great way to keep the urge people have to shovel in OOP even when it doesn't really make sense. When I see some bullshit C++ code at work, I often think, "if people had to write this in C, they wouldn't have overthought this this much"...
My 2 cents is that there was a Java craze back in the '90s that basically infected all code designed in that time period, and that's how we got some very weird nonsense that in hindsight was poorly thought out. Just look at stuff like GTK+ and GObject...
The GObject system for all it's faults serves a purpose. Similar to COM in Windows it allows mapping of higher level languages to libraries. Without it there wouldn't be all the bindings we have to Python, JavaScript, Vala and Rust today. I wouldn't say it was poorly thought out so much as mismatched with it's user's typical uses and expectations.
Yeah but it made literally zero sense to write GObject in C. They've reimplemented inheritance and the like with macro BS while the GNU project literally had both a C++ and Objective-C compiler - Objective-C warts and all was a perfect fit for GObject.
It makes sense if you consider that it was created for making c libraries bindable to higher level languages. That's more a flaw in it's design rather than implementation. If they were to design such a system now I'd hope it would be designed as a language independent ABI, Runtime and IDL like the Wasm Component Model.
I have been guilty of this if only in school. A class assignment could be completed in java or c and I knew c++ and c and my teammates knew c. I really wanted to do oop because I was ignorant, but none of us knew java so we did OO in c. It was horrible. I like the simplicity of c. I wish there was a zig that was immutable by default, and had a borrowchecker, but I think that road inevitably leads to a GC jitted language or to something as complicated as rust. Well almost as complicated, at least macros would still be written in the same syntax as normal runtime code.
Macs in CI are an absolute nightmare. For some reason (well, I do have a reason, they want to sell you more Mac Minis) macOS is the only modern OS that has no real container solution builtin. Windows has Docker and true containers, FreeBSD has jails, Linux has a bajillion solutions, Darwin (macOS)? Nothing. They've ripped half of FreeBSD already, just pull jails too!
It at least has the virtualization framework now. There’s a product called Anka that plugs into Jenkins and lets you deploy macOS VM images as build agents on top of physical Apple hardware. While slower than containers, and limited to 2 VMs (?!?) you can have reproducible and sane build environments via VM images.
to install, use and run up to two (2) additional copies or instances of the Apple Software, or any prior macOS or OS X operating system software or subsequent release of the Apple Software, within virtual operating system environments on each Apple-branded computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use.
Apple just really doesn't care about you, and as a developer, you're just a sucker to extract money from.
Realistically you can run more than 2 VMs with some work[0], but legally companies that provide CI and other virtual solutions can't buy 1 mac then get a license to run 100 virtual macs.
(insert name of any corporation ... listed on any stock market) just really doesn't care about you, and as a developer, you're just a sucker to extract money from.
Don't worry, as soon as this becomes production grade enough to justify buying less Mac Minis in data centres, Apple with shut it down faster than the speed of light. They could have done this themselves if they wanted, the reasons were never technical to begin with
If Linux drops BCacheFS, it's dead. Let's be honest, nobody would be using anything but ZFS if it was in tree - not having it first-party is what keeps Btrfs alive. If you have to install it from external sources than you're probably better off simply installing ZFS to begin with.
> nobody would be using anything but ZFS if it was in tree
I'd pick xfs anytime.
I don't know if it was already fixed, but ~1y ago had a really miserable experience using ZFS on my NVMe drives, zfs is like 100x slower in random read. And hey, I have fancy SSDs for a reason!
Yeah, but XFS has literally a fifth of the functionality ZFS has. If you need ZFS features you're basically forced to pick between ZFS or Btrfs, the former being vastly more stable.
That's EGLFS, it's used quite a bit in automotive AFAIK. It's slowly getting replaced by Wayland and Weston though.
reply