TechNom (nobody)
- Lack of privacy
- Arbitrary cancel culture with no recourse
- Corruption and bloating of open standards like web
- Non consensual logins (android, chrome)
- Sabotage of federated services (email, xmpp)
- Suggestion of new tracking methods (like FLoC) when old tracking methods (like 3rd party cookies) are phased out
- Centralization of information flow (eg: AMP)
- Bait and switch tactics (like YouTube ads)
- Support for horrible laws (like illegitimate DMCA strikes)
- Locking down devices (with remote attestation, safetynet api, etc)
- Geolocking apps unnecessarily
- Invasive use of credit card information to prove location (why not just use GPS or cell info?)
- Incompatibility with open standards to achieve user lockins (eg: IMAP, caldav, carddav)
- Riding the open source wave with projects that don’t behave like one (AOSP, chromium)
- Untrustworthiness when it comes to long term presence of services
I found Jim Blandy’s Programming Rust to be quite easy to follow. On the other hand, The Rust Book is free. Anyone with C or C++ background will find it quite easy to get started in Rust with any available resource.
this appears to be a very reasonable move
There are a few problems with this:
- The company wasn’t ready for the concessions it had to make when they started the project as open source. This though, may be the most forgivable issue. They couldn’t have predicted that big parasitic SaaS and LLM players would make their business unviable.
- There may be some contributors who wouldn’t have contributed if they knew this was going to happen. Generally speaking, never sign away your rights. CLA and copyright assignments should be avoided like plague. The maximum you should settle for as a contributor is a DCO.
- Hashicorp is still trying to pass this off as open source of sorts. They say nothing has changed. But this change puts them squarely outside the definitions put forth by either FSF or OSI. This will cause their ejection from several software repositories. They should just be honest about it.
Stay off Tmux for a couple of months and try again. I’ve been through that exact scenario. It doesn’t feel intimidating, but you still need to brush up.
One thing that zellij does correctly is discoverability. You don’t need to even read their documentation to become productive.
Zellij is also reaching feature parity with tmux. But its development seems to be accelerating. Zellij might become the dominant multiplexer soon.
GUI just doesn’t give you the level of control or keyboard driven workflow that CLIs can. You can even use plain kernel terminals or bootloaders if you know CLI. Text config files are also extremely easy to configure. There are only a few legitimate cases where CLI isn’t enough. That includes gaming, 2D and 3D graphics design and CAD/CAM. And almost all of them implement their own GUI anyway.
So many praises for Windows and Mac about ‘premium features’, ‘corporate environment’ and ‘device support’. But not enough talk about how they treat customers like crap and cash cows. Windows is replete with spyware and ads. It doesn’t respect the user’s choices, like when not to do an update or opening the links with a browser of user’s choice. Heck! Some versions don’t even allow you to register users without a cloud account. And now they are taking definite steps towards ensuring that you can’t do anything they don’t approve - with TPM and pluton non-sense. Praising windows is like being in an abusive relationship and finding justifications for it.
Mac is on the other extreme. They lock down their platform more and more in every revision in the name of security. It’s getting harder to side-load apps. Why? For security, of course! No mention of how security comes primarily from platform design. Then there is the hardware, where everything is glued, soldered, riveted, digitally locked, etc, etc. Any small issue, and it’s garbage. Not even parts from another genuine Mac can be used. Macs also have the strange distinction of needing calibration and signing of any part that can be replaced at all. It’s deliberately designed to extract more money from you and create a tonne load of e-waste (iWaste?). Mac fanbois have a habit of justifying it in the name of ‘miniaturization’ and progress. Honestly, that’s just hand-wavy and completely wrong technical argument. And Apple says it is all for ‘privacy’ and ‘security’ while their actual reason is the pursuit of double-digit growth (not just profits). So, in effect, Apple is saying to their customers “Oh honey! You’re are just too stupid to take care of it. So let me just decide for you” - all the while squeezing you for money. Does it end there? Oh no! They need developers to pay a yearly fee and want to take a huge cut from their profits. All that for “providing the engineering, platform and services”. As if the exorbitant price they extract from their customers isn’t enough.
The hardware situation on Linux distros and frankly even BSDs isn’t as bad as it is projected by some. Most devices just work even on a live installation medium. Even Nvidia works. (Have you considered the possibility that if any device doesn’t work, it’s the manufacturer’s fault and not the OS’s? There are plenty of devices for which the community maintains the drivers, just because the device manufacturer isn’t an utter trashbag). There are tonnes of games too - thanks to Valve and Proton. And as for the ‘corporate env’, you are probably just locked in or too used to them. There are users who have been on these platforms for decades now without complaints. And there are companies built entirely on them. Can you say the same about any of the company that makes your OS/devices? Is there one among them that doesn’t use Linux or BSDs?
Look! I’m not claiming that everything is rosy on the Linux and BSD side of things. Sometimes you have to find an alternative way of doing things (there are plenty of options). Sometimes, you have to configure a lot. Sometimes, you have to carefully choose your hardware so that your life is easier with Linux and BSDs. But there is one thing they don’t ask you to do- and that is to surrender your self-respect. You don’t get treated like cash cow. You don’t get spied on as if you are a thief. You don’t get restricted like a school kid. You’re not told that your choices are wrong. Your choices are not disrespected. You don’t get treated like you owe them after you paid your hard earned money on the devices they make. Ultimately, it’s up to you to decide if the little conveniences are bigger than your self-respect.
Most of the “automation” work that I do involves parsing data with regex, restructuring the data, converting the data into a modeled format and transforming something with that data.
These are the highlights of rust - regexes (the regex library that powers ripgrep), serialization/deserialization (serde, nom, pest, capnproto, etc), data manipulation (too many. perhaps apache arrow deserves a mention), etc. The language is designed for this sort of stuff.
Has anyone used Rust for network automation tools?
I’m in the same boat as you. I use python to manage an LXD cluster. I didn’t choose Rust because Python has an API binding, but Rust didn’t. It wouldn’t have been too hard, considering that the API is mostly just JSON.
With familiarity, can Rust’s intuitiveness match Python’s “from idea to deployment” speed?
Unfortunately no! (in my personal experience). I have been using Rust for a decade (since before 1.0) and am more or less comfortable with it. I no longer fight with the compiler as most beginners do. Still, the compiler complains a lot and you have to think about why. This is not bad, IMO - all that thinking make you design better programs. There is always a sweet satisfaction of writing excellent code when you finish a Rust program - probably the reason why Rust developers love it so much. But you have to sacrifice some speed for that.
Intuitiveness is also subjective. My introduction to programming and computers was from the hardware side - from ALUs, DRAM, hardware pipelining etc. Rust’s rules are very well defined, but is obscurely related to real problems you encounter in the hardware. In other words, Rust rules look confusing at first, but it makes sense once you see the error messages. You know what problem could have happened on the hardware if Rust didn’t stop you. It’s as if Rust’s simple rules magically cover the problems you dread on the hardware.
All this means that Rust is easy to grasp for people who are already using C - OS, game engine, web engine and embedded system developers. For others who are mostly used to GC languages, it’s an uphill battle with the compiler, until some day it clicks somehow. With Rust, it’s very important to start right away with the (c lang) memory model and Rust’s aliasing rules.
Or should I only learn Rust if I intend to create applications that need tight performance?
I wouldn’t say no to learning a new language. But I always recommend a few languages because they introduce a radically different idea. Rust is one of them. My rant above probably gave you an idea why I would recommend Rust. The first is that Rust forces you to design programs properly - even though the rules are meant only to enforce memory safety. Second is that Rust gets you very close to the soul of the hardware. Python and even Go has some opaque layers in between you and the hardware. With Rust, you’ll get every opportunity to get the best the hardware can offer. You get the same in C and C++ - but they also allow you to screw up.
I use Rust for even trivial tasks where a shell script would suffice. Besides the language features, Rust has excellent tooling and a rapidly growing library ecosystem. In many ways, it’s easier to package Rust programs than Python ones. So Rust will work for your use case. But if development speed is more important to you than performance, then Go (similar to Python), Nim (much more similar to Python) and Zig are probably better choices. Repeating something here - Go is designed for the web. Numerous web backends are already on Go. And almost the entirety of Kubernetes is written in Go.
The main issue for me is the syntax, specifically generic types, traits, and lifetimes.
After working almost exclusively with Go for years, reading it seems unnecessarily demanding.
Like someone else said, this is a complex subject to answer. The syntax looks perplexing and frustrating, until it doesn’t. These days, Rust syntax is nowhere in my thought while coding - it like when you drive, you are thinking about where you want to go rather than about manipulating the controls.
Why should I learn and use rust?
Rust’'s rules are about enforcing memory safety. But it also ends up forcing you to write better programs than what you imagined you could. It’s hard to describe that feeling - you have to experience it. That alone is a good reason to learn it - even if you end up not using it in the future.
Rust’s unique design also leads to many design patterns not normally seen in most other languages. That’s also worth exploring.
I have fallen in love with Go. It feels like ‘home’ to me
That’s a perfectly good thing. It’s hard to find that sweet spot. However, don’t let that stop you from exploring the alternatives. You might find ideas you could use in Go.
Did you miss the part where I said they use the security argument to lock down the device and restrict the user? In addition, Linux distros in their default configuration may not be secure - but there are plenty of packages that can secure it down to a deep level. It just depends on the user’s threat level assessment. That military establishment vs homeless tent analogy is just pure hyperbole and FUD.