TechNom (nobody)
All the companies that recently switched their products from open source licenses to non-free source-available licenses (like BSL and SSPL) were companies like this that offered hosted services. Their argument was that the big cloud companies were using their product to make money and causing them to lose business. Should we worry about a similar future for gitea?
It may be premature. But this is the gitea’s second move in that direction, after transferring the project’s control to a crypto-based for-profit company. Was Codeberg e.V (the nonprofit behind forgejo fork and Codeberg) justified in doubting gitea?
It’s reported to be a declarative block list that’s already vastly powerless compared to regular ublock. Its presence shouldn’t give you a false sense of security. One thing that is sure to happen is that its capabilities will be gutted in the long run - perhaps by just bypassing the blocks.
Matrix is one option, if you just want a chatroom, similar to IRC. An online forum, like Discourse (not discord) is even better, since it creates a searchable history of past discussions. That way, most users who face any issue with your software can solve it themselves based on past discussions.
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.
Git is a lot of things at once:
- A tool to record development history - warts and all
- A tool to create a logical sequence of changes
- A tool to communicate intent and ideas to a maintainer
Meaningless messages like minor and . don’t suit any of these roles - not even 1. Even when recording development history with all mistakes, you’d still need context when you look back at the history. Matklad is a well respected developer. I wonder why he’s make such a bizarre claim.
Facebook for all its nastiness was very much incompetent in influencing the direction of the web. Look at their failed attempts like free basics.
Google on the other hand has the web tightly in its dirty grip. At this point, they aren’t even pretending to be nice. Even those plans that cause them reputational damage are brought back in some other name.
The only way to stop Google is for the regulatory agencies to put their foot down hard. They should be divided into at least a couple dozen companies that are not allowed to do business with each other.
I too use Rust for what normal people use shell scripts for. But I have a feeling that Rust is falling into the same trap that other languages with similar easy dependency management fall into (Python and NPM are good examples). You end up with a dozen direct dependencies and hundreds of indirect ones with dozens of levels of hierarchy. C and C++ programs have fewer dependencies because each additional one adds more headache for the developer. Drew Devault’s Hare language is giving language repo and package manager a skip for the same reasons. And I’m starting to think that he may have a point.
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.
I wonder what sort of problems they had with C++ that prompted them to port such an old codebase to Rust.