That looks weird. I am guessing that someone knows about the mismatch between ccTLDs (where the UK is .uk) and ISO codes (where the UK is GB and Ukraine is UA) and tried to correct something and got it wrong.
Having done just a small to moderate amount of automation in CI/CD pipelines around GPG tools I know this pain. Back then I was waiting for https://sequoia-pgp.org/ which recently (Dec 2024) released its v1.0 of the sq CLI which seemed to have a lot of promise of fixing the strange and inconsistent ergonomics of using the gpg tools.
It's one of those projects where it really doesn't matter what language it's in, all of them will accomplish the job roughly the same. I'm happy for the dev to rewrite in whatever language motivates them to work on it, because with such a small codebase the chance it will affect functionality is low enough for it to not matter.
Most of the gripes about Go could've been apparent before a single line was written, with just some preliminary research. The packaging issues are valid for 2016, even though they are now resolved with Go modules.
Then the rewrites in ClojureScript, Elixir, and now Rust... Sheesh. All this tells me is that the authors are trend chasers rather than solid engineers, which erodes any trust I had in this project.
When a project has thousands of users it's irresponsible to use it as a testing playground. If there is a legitimate benefit from rewriting something in another language, which is rare to begin with, the decision should be researched thoroughly and committed to. Doing it this often signals that authors easily latch on to shiny new tech, and value their experience over their users'. When the next modern language comes along, will we see a similar post explaining why they chose to abandon Rust?
I value both my experience and the users, and every asciinema release was backward compatible with the earlier ones (with few exceptions, where language change was not a factor), changing nothing in terms of UI/UX/API. The language is an implementation detail.
Did asciinema hurt you? Because you seem to be on a vendetta here.
I’m not sure if you’re an asciinema user or not, but I am, and I’m happy to see the rewrite — it signals to me that the author is still passionate and invested in the project. And he added new features (live streaming) with the rewrite.
It’s people like you who make maintaining open source projects exhausting. Find a more worthwhile hill to die on.
There's so many things wrong with your comment that I'm not sure where to start.
First of all, nobody is on a vendetta or "dying" on any "hills" here... I'm just pointing out shoddy engineering as I see it.
Deciding to rewrite a project in another language rarely has any practical merits. If it's worth considering, then at the very least it should be thoroughly researched, and not done because the author "feels like it", as they've done multiple times already. If this was brought up in any technical meeting for a project with thousands of users, the person would be laughed out of the room, and for good reason. And, yet, because the project happens to be open source, it should be excused, or even celebrated? That is absurd.
The idea that providing the software gratis and with the freedoms to use and modify it should protect the authors from any criticism with how the project is managed is also absurd. Software should be held at the same levels of scrutiny regardless of its license or business model. There's always a contract between developers and users whether it is made explicit or implicit. Using a project with an established user base as your personal technical playground is irresponsible no matter how you look at it.
> And he added new features (live streaming) with the rewrite.
Ah, yes, I'm sure that would be impossible with any other language but Rust.
> It’s people like you who make maintaining open source projects exhausting.
And it's people like you who don't understand open source and only use it because they get something for "free". See? It's easy to villify someone without engaging with any of their arguments.
> When a project has thousands of users it's irresponsible to use it as a testing playground.
Well, what about motivation? If the author has left behind the original language and rewriting it provides them with motivation to continue then it's not "a testing playground", it's a viable way towards continued maintenance.
There are many ways to write code and maintain a project. Just because they don't align with your preferences doesn't make them shoddy.
Developer motivation is important, but the choice of language shouldn't be a primary factor in that. Being passionate about the domain and solving a problem for users should be the primary motivators. Otherwise it signals that once the developer gets bored of their chosen stack, which might include Rust and Elixir (omg BEAAAMM!!!) a few years from now, they will be compelled to abandon the project unless they're allowed to experiment with some other shiny new tech.
But everyone is ignoring the bigger picture here: this project has been written in 5 different languages over the course of its existence, including reversing to a previously used language. That is an insane and unprecedented statistic. Changing a language even once is rarely done, let alone this many times.
> Just because they don't align with your preferences doesn't make them shoddy.
These are not my preferences. Avoiding total rewrites, especially in another language, is a core principle of software engineering, not unlike, I don't know... using testing and version control. Developers may choose to disregard it, but at the very least they should be challenged for it. The fact this person hasn't for such a long time is another signal that this project is mismanaged.
In any case, I'm done defending what would be an uncontroversial opinion in any other setting.
"Rewrites should always be avoided" is not a core principle of software engineering. History has shown that rewriting large, monolithic applications often fails, and so rewrites of large applications often require extra effort to ensure the changes actually ship (like rewriting single views and proxying requests to a new service, for example). If a project is small enough that it can be rewritten and still shipped that extra effort is unneeded, and the fact that this project was rewritten and released makes that clear.
I don't understand why you're so hung up on the history of this project. If we were talking about software being used to send people to space I could see your point, but this is largely a single person project which is obviously being used to learn and have fun.
> "Rewrites should always be avoided" is not a core principle of software engineering.
Why are you misrepresenting what I said? I never claimed that rewrites should always be avoided. But that in most cases they're not a good idea, for various reasons that should be obvious to most developers.
> I don't understand why you're so hung up on the history of this project.
I'm not hung up on this project at all. I have come across it, but I'm not a user. I simply stated an opinion that shouldn't be controversial at all, yet for some reason, I keep having to defend it. So it seems that it struck a nerve with fans of the project who would rather attack me personally than acknowledge the poor decisions made by its author.
> If we were talking about software being used to send people to space I could see your point
It's a very popular project that many projects depend on. Lives don't need to depend on it for it to be managed responsibly.
Anyway, I think we both have better things to do than waste anymore of our time on this discussion, so let's just drop it.
OK, so why in this specific case is it a bad idea, other than you being personally offended by the number of languages used in the project's history?
You keep saying your opinion should be uncontroversial but you've offered no evidence other than an appeal to authority, and I think THAT should not go unchallenged.
My most popular project is maintained solely by me and is downloaded >1.3 billion times a year. That usage does not create a responsibility out of thin air. It got popular because people like it, it's fast, and it has excellent test coverage. I could decide to rewrite it in a compile-to-JavaScript language tomorrow for any reason I like and no one using it would be negatively affected in any way.
I think you are much too rigid on your views about software engineering and they don't comport with the reality of building and releasing projects to the world, for fun or profit.
On this note I would check out the Universal Blue project[1] which uses a combination of technologies to implement an immutable OS desktop environment.
Great thread! I noticed a bunch of the comments are from Sandia/LLNL/LANL all of which are mostly focused on the National Nuclear Security Administration side of the Department of Energy which is focused on the various aspects of maintaining the nuclear stockpile of the US.
I worked at Oak Ridge National Laboratory in High Performance Computing and did not work with anything directly nuclear at all. The HPC efforts of the DOE are under the Office of Science (separate and at the same level as the NNSA) which is focused on more wider scientific impact and application than just nuclear. The Office of Science has a number of program offices that focus on all different kinds of science from basic energy sciences/physics to biological/environmental and scientific computing (where HPC is funded in DOE).
I agree that the work/life balance is great and it is definitely a slower pace than what you would find in industry. The lab system is huge and there are plenty of opportunities but on the Office of Science side I like to break it down between what I think of as a research group and a user facility.
Working in a research group is much like academia, they mostly require a PhD and from what I could tell performance is judged on publication output. These folks also write grant proposals that come from DOE program offices for funding their own research. In some cases I have seen these groups employ non-PhDs to be computational scientists and write code.
The user facilities are long-running projects funded by the DOE at the labs to provide specific capabilities to researchers, sometimes just for DOE scientists but a number of them are open to scientific researchers all over the world. This is where I have the most experience where I worked at ORNL's National Center for Computational Sciences on the Oak Ridge Leadership Computing Facility (OLCF). These projects are generally well funded and have all kinds of interesting challenges to solve. For example, the OLCF has consistently deployed the number one supercomputers on the Top500 list and it offers those computational resources to anyone through their allocation program INCITE which supports many different computational modeling and simulation experiments. Other examples of user facilities at ORNL are the Spallation Neutron Source and the High Flux Isotope Reactor.
One thing I have noticed since moving from ORNL to industry is that the sense of shared purpose does not extend as far in the lab system as it does in company. What I mean is that with the small research group and with a user facility like the OLCF there is shared purpose with the people in those groups but it does not go much beyond that. A lab is generally made up of lots of different research groups and a few facilities but beyond the drive for "Science!" there is not a lot of shared purpose or collaboration at a macro level. The analogy I use is that a lab is a bunch of small dinghy boats that are all generally moving in a similar direction but a company is a single ship with a specific purpose driving it forward.
Overall I loved my experience at ORNL, I learned so much working with so many smart people and made friends that I will have for life.
I think KubeVirt fits better in an environment that is already running Kubernetes. We have found it useful for running some of our heavyweight CI jobs that have virtualization requirements because we can manage the VMs in the same way that we manage our containers.
In general though we have only used KubeVirt for ephemeral workloads.
