That's what's happening with 99% of Rust projects out there. In the end they get lots of stars in GitHub but nobody uses them. It's crazy how the engineering world just became a world of hype/fashion in the past decade. Or maybe people are simply more vocal about it.
People have all sorts of hobbies, and it really is one of those "there's no discussing taste" topics. This ultimately isn't much stranger than, say, rubbing dirt until it shines, or going for the full old school runescape grind, or solving sudokus.
What’s the point of porting it to Rust if you’re just going to make everything unsafe? Generally, the point of a rust port is to make the code as safe as possible, reserving unsafe for stuff that is impossible to achieve in safe rust code.
First, it's important to realize that "unsafe Rust" is very usually still far more safe than C code. My understanding as a newbie Rust user is that unsafe doesn't actually disable any checks -- what it does is enable additional operations that you can't normally do. Obviously you lose guarantees, but strictly speaking you don't lose checking, if that makes sense.
That being said, with the original C2Rust version... I don't actually think that this applies directly, as at a quick glance with my pretty-lay understanding of Rust, that version does look like it was likely pretty much thoroughly unsafe. This may still be true in the current version as well. However, even if it is, this point still plays into the next one.
Second, TFA directly answers this question: "The next goal is to convert the codebase to safe Rust."
This feels to me of the same flavor of taking a codebase in JavaScript or untyped Python, and gradually introducing type annotations as you convert to TypeScript or typed Python. It's not something you can do on a tens-of-thousands-of-lines code base right from the get go, because it's something that will need a ton of manual work.
Back when I was in school, “pair programming” was all the rage, (and yes, I coexisted with stegosaurs, thanks for asking) and I had a classmate who loved writing documentation. He was a competent programmer, and I say that not to damn him with faint praise, but it was definitely all science and no art to him, if that somehow explains it.
Whereas, while I do enjoy code that has some form of explanation (because I early on discovered that later-me’s greatest nemesis is, in fact, earlier-me’s failure to comment expressively), it’s all science and no art to me.
We divvied our assignments 100% him documenting and me coding, and we had a delightful time breezing through everything.
The hilarious thing is that in thirty years, another language, say, xyz, will take over Rust, and some people will praise for rewriting everything in xyz.
Of course you're free to quesion the usefulness, but it's honestly a bit douchy. Let people spend their time however they want. I bet lots of different tools were created by some people working a hobby project that someone else probably thought was a waste of time.
So, is it now impossible to express disapproval without sounding like a jerk or risking downvotes from the people's Court?
Again. I’m not questioning the right to rewrite projects, but I’m questioning the usefulness of their very existence.
Ten years ago, I would probably have encouraged that approach to rewrite things (I was young and naïve), but we’ve seen many other projects like that over time that have ended up in the tech graveyard, that I can no longer support it.
Yes, definetly only a douchebag thing to express disapproval over someone spending time on a personal hobby, especially one they learn a lot from and that does not harm anyone.
If someone is playing football as a hobby its also douchbag to have the urge and need to disapprove of them playing football as a hobby. Same with any other hobby. I'm sure you have your own hobbies.
You can do whatever else. If you dont like it, dont do it. If you dont want to run things rewritten in rust then dont.
You can loudly disapprove of your favorite distro using a rewrite for example, as that is more than a hobby, that actually affects you or people in general.
I mean, legacy softwares will virtually be there forever.
Banks still rely on COBOL codebases and they pay you way more than any python script kiddy importing 837388214 dependencies to find even numbers could dream of, to fix and upgrade their COBOL codebases.
If you're paying of course you can get COBOL programmers. But tmux is open-source, it relies on volunteers. I'm certain the open source COBOL scene is not very vibrant. In fact I'd be surprised if you could find a single open-source COBOL project.
My point is that you'll have an easier time getting contributors if you use a modern programming language than if you're stuck with some antediluvian abomination.
And one day, just like COBOL in banks, almost noone will be able to fix and upgrade those antediluvian abominations the whole world relies on, and bad things will happen.
All the rewrites which are actually serious and big projects and not just hobby rewrites (which have been done for about as long as software has existed) do aim to improve either the featureset or the security of whatever is being rewritten. It's just that saying "it's a sudo rewrite" is a lot more concise than describing the exact, often loosely tied together, featureset of what you are trying to replace. For suso that would need a whole explanation of how sudo does more than just running something as a superuser for historical reasons but if you only implement the core feature set then people won't want to switch because they use some of the edge cases etc etc
As I said a lot easier just to say "hey it's like that old software you already used but we have done work to improve it."
This one is explicitly a hobby project, with no real goals. It's not like they intend to replace tmux.
You might be asking: why did you rewrite tmux in Rust? And yeah, I don’t really have a good reason. It’s a hobby project. Like gardening, but with more segfaults.
Yeah, but it seems the c2rust people are interested in the feedback, so some good might come of it. I just hope the dude doesn't wind up feeling like an pure mathematician after someone found a way to apply their work to the real world, c.f
It’s a hobby project. Like gardening, but with more segfaults. […] I started this project as a way of trying out C2Rust, a C to Rust transpiler.
To be fair, the author explicitly calls out the first snippet conversion as the mangled and unreadable output of a transpiler he wrote. The rest of the snippets are all simple examples and are pretty readable.
shevy-java@reddit
But ... why!
zackel_flac@reddit
That's what's happening with 99% of Rust projects out there. In the end they get lots of stars in GitHub but nobody uses them. It's crazy how the engineering world just became a world of hype/fashion in the past decade. Or maybe people are simply more vocal about it.
syklemil@reddit
People have all sorts of hobbies, and it really is one of those "there's no discussing taste" topics. This ultimately isn't much stranger than, say, rubbing dirt until it shines, or going for the full old school runescape grind, or solving sudokus.
lachlanhunt@reddit
What’s the point of porting it to Rust if you’re just going to make everything unsafe? Generally, the point of a rust port is to make the code as safe as possible, reserving unsafe for stuff that is impossible to achieve in safe rust code.
evaned@reddit
A few thoughts.
First, it's important to realize that "unsafe Rust" is very usually still far more safe than C code. My understanding as a newbie Rust user is that
unsafedoesn't actually disable any checks -- what it does is enable additional operations that you can't normally do. Obviously you lose guarantees, but strictly speaking you don't lose checking, if that makes sense.That being said, with the original C2Rust version... I don't actually think that this applies directly, as at a quick glance with my pretty-lay understanding of Rust, that version does look like it was likely pretty much thoroughly unsafe. This may still be true in the current version as well. However, even if it is, this point still plays into the next one.
Second, TFA directly answers this question: "The next goal is to convert the codebase to safe Rust."
This feels to me of the same flavor of taking a codebase in JavaScript or untyped Python, and gradually introducing type annotations as you convert to TypeScript or typed Python. It's not something you can do on a tens-of-thousands-of-lines code base right from the get go, because it's something that will need a ton of manual work.
calrogman@reddit
Imagine my shock when they didn't even bother to steal the manpage.
theother559@reddit
call me crazy, but writing a good manpage is kind of fun...
omgFWTbear@reddit
Back when I was in school, “pair programming” was all the rage, (and yes, I coexisted with stegosaurs, thanks for asking) and I had a classmate who loved writing documentation. He was a competent programmer, and I say that not to damn him with faint praise, but it was definitely all science and no art to him, if that somehow explains it.
Whereas, while I do enjoy code that has some form of explanation (because I early on discovered that later-me’s greatest nemesis is, in fact, earlier-me’s failure to comment expressively), it’s all science and no art to me.
We divvied our assignments 100% him documenting and me coding, and we had a delightful time breezing through everything.
gimpwiz@reddit
You're hired
willrshansen@reddit
Zellij competitor
lkajerlk@reddit
Days since last Rust rewrite: 0
AttilaLeChinchilla@reddit
The hilarious thing is that in thirty years, another language, say, xyz, will take over Rust, and some people will praise for rewriting everything in xyz.
lkajerlk@reddit
I mean yeah, it’s called progress and it’s necessary and good for humanity. Still, it can be a bit funny sometimes
AttilaLeChinchilla@reddit
You’re right, but the “problem” is the need to rewrite everything, even what works, in Rust.
Perhaps I’m a bit old-school with my “if it ain’t broke, don’t touch” approach.
UltraPoci@reddit
People are free to do what they want in their free time
AttilaLeChinchilla@reddit
And so I'm free to question the usefulness of the approach.
Zahand@reddit
Of course you're free to quesion the usefulness, but it's honestly a bit douchy. Let people spend their time however they want. I bet lots of different tools were created by some people working a hobby project that someone else probably thought was a waste of time.
AttilaLeChinchilla@reddit
So, is it now impossible to express disapproval without sounding like a jerk or risking downvotes from the people's Court?
Again. I’m not questioning the right to rewrite projects, but I’m questioning the usefulness of their very existence.
Ten years ago, I would probably have encouraged that approach to rewrite things (I was young and naïve), but we’ve seen many other projects like that over time that have ended up in the tech graveyard, that I can no longer support it.
MatthewMob@reddit
This relies on the assumption that every project people make should be useful.
Jolly-Warthog-1427@reddit
Yes, definetly only a douchebag thing to express disapproval over someone spending time on a personal hobby, especially one they learn a lot from and that does not harm anyone.
If someone is playing football as a hobby its also douchbag to have the urge and need to disapprove of them playing football as a hobby. Same with any other hobby. I'm sure you have your own hobbies.
You can do whatever else. If you dont like it, dont do it. If you dont want to run things rewritten in rust then dont.
You can loudly disapprove of your favorite distro using a rewrite for example, as that is more than a hobby, that actually affects you or people in general.
UltraPoci@reddit
Usefulness... to whom? It doesn't need to be useful if it's something they enjoy doing.
legobmw99@reddit
The thing is, a pretty large chunk of software is broke, we’re just waiting for the next CVE to tell us how so
AttilaLeChinchilla@reddit
Then shouldn't we bring new solutions, build better softwares with evolutions and new usages, instead of rewriting (just like zellij does?)
Or, on the other hand, shouldn’t we just fix the original instead of splitting workforces?
Kind of reminds me of remacs.
araujoms@reddit
Should we keep fixing and updating the original forever? Why? We have learned a lot about programming since the 70s. We can do better.
And working with legacy codebases suck, which is a problem if you want to attract volunteers.
AttilaLeChinchilla@reddit
Well…
I mean, legacy softwares will virtually be there forever.
Banks still rely on COBOL codebases and they pay you way more than any python script kiddy importing 837388214 dependencies to find even numbers could dream of, to fix and upgrade their COBOL codebases.
guepier@reddit
This isn’t the argument against rewrites that you apparently think it is. On the contrary.
AttilaLeChinchilla@reddit
And I think you didn't understand my argument. On the contrary.
araujoms@reddit
If you're paying of course you can get COBOL programmers. But tmux is open-source, it relies on volunteers. I'm certain the open source COBOL scene is not very vibrant. In fact I'd be surprised if you could find a single open-source COBOL project.
AttilaLeChinchilla@reddit
Of course.
But my point here was that even in OSS, legacy softwares will virtually be there forever.
C will never disappear. Badly designed C++ will always be there. Assembly will still be in use when I'll be dead. And so on.
araujoms@reddit
My point is that you'll have an easier time getting contributors if you use a modern programming language than if you're stuck with some antediluvian abomination.
AttilaLeChinchilla@reddit
And one day, just like COBOL in banks, almost noone will be able to fix and upgrade those antediluvian abominations the whole world relies on, and bad things will happen.
araujoms@reddit
If no one can fix them it means nobody relies on them. The ones we need will have long since been rewritten in Rust.
AttilaLeChinchilla@reddit
Ahah. Good joke!
Jan-Snow@reddit
All the rewrites which are actually serious and big projects and not just hobby rewrites (which have been done for about as long as software has existed) do aim to improve either the featureset or the security of whatever is being rewritten. It's just that saying "it's a sudo rewrite" is a lot more concise than describing the exact, often loosely tied together, featureset of what you are trying to replace. For suso that would need a whole explanation of how sudo does more than just running something as a superuser for historical reasons but if you only implement the core feature set then people won't want to switch because they use some of the edge cases etc etc As I said a lot easier just to say "hey it's like that old software you already used but we have done work to improve it."
orangejake@reddit
Ah yes, these are all the goals of all hobby projects, and so are very relevant to the discussion at hand.
jaskij@reddit
This one is explicitly a hobby project, with no real goals. It's not like they intend to replace tmux.
deviled-tux@reddit
It seems more work to do it this way instead of a straight up rewrite
syklemil@reddit
Yeah, but it seems the c2rust people are interested in the feedback, so some good might come of it. I just hope the dude doesn't wind up feeling like an pure mathematician after someone found a way to apply their work to the real world, c.f
Antagonin@reddit
I like how the snippet instantly became unreadable mess with thousands of brackets and extra keywords.
Inkdrip@reddit
To be fair, the author explicitly calls out the first snippet conversion as the mangled and unreadable output of a transpiler he wrote. The rest of the snippets are all simple examples and are pretty readable.