Hacker News new | ask | show | jobs
by imiric 272 days ago
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.

1 comments

> 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.