Newsraft: feed reader with ncurses user interface(codeberg.org) |
Newsraft: feed reader with ncurses user interface(codeberg.org) |
> "It is a rewrite in Go of the wonderful, but unfortunately now unmaintained"
Is it still working? If not, I might need to read up on the IMAP protocol... Could be cool to hack such a thing together.
One feature I would suggest is to import an OPML file to help those (like me) with insane numbers of existing RSS feeds.
Yes. Your sentence misses a comma and a word: feed2imap is (more or less) unmaintained, therefore I rewrote it in Go, resulting in feed2imap-go
> One feature I would suggest is to import an OPML file to help those (like me) with insane numbers of existing RSS feeds.
Please feel free to open an issue. Note: Import does not make that much sense, but writing a generator that spits out the yaml file (or portion thereof) could be useful.
Newsboat's authors are rewriting it in Rust. They concluded (last time I checked) that C and some early design decisions were bad for its development now and they want to rewrite it in Rust because this is something that can be done gradually (and, I think, because they liked Rust). Before they settled down with Rust, they even considered Haskell, but Rust won.
Surprising that this project is in C. Given a chance to start fresh, why not choose a better language? Even Rust, I think, is unnecessarily low-level for an applied, not performance-critical program like an RSS reader. That's why I chose Haskell. Any other high-level programming language would be a better choice than C.
> Newsboat's authors are rewriting it in Rust. They concluded (last time I checked) that C and some early design decisions were bad for its development now and they want to rewrite it in Rust because this is something that can be done gradually (and, I think, because they liked Rust). Before they settled down with Rust, they even considered Haskell, but Rust won.
There seems to be a common pattern that people believe "program that compiles to binary suffers from segfaults, therefore use Rust". Rust will not fix your poorly designed code, now it is harder to develop and runs slower. Your broken logic is still broken.
> Surprising that this project is in C. Given a chance to start fresh, why not choose a better language? Even Rust, I think, is unnecessarily low-level for an applied, not performance-critical program like an RSS reader. That's why I chose Haskell. Any other high-level programming language would be a better choice than C.
The code could do with some comments, but it's otherwise clean. It has been mostly worked on by Grigory Kirillov [1] and maybe this is a language they like [1]. Given the use of `func_name(void)` and `int64_t` it seems like somebody quite capable of writing C safely. With some regression testing this could be a fast and reliable program.
> Rust will not fix your poorly designed code
Nobody said it will. But segfaults hardly come from poor design. They come from accidental mistakes, lack of static analysis, and gotchas that your language offers.
> now it is harder to develop
Only if you're a C programmer who doesn't know Rust.
> and runs slower
This is plan false. Please back it up.
> it seems like somebody quite capable of writing C safely
Try using it for a week, and count for me how many times it segfaults on your face. (That is not to diminish Grigory's work, which I have nothing against.)
As replied in another comment, here it is. Enjoy!
Personally, I prefer using one that renders HTML and shows pictures :)
Some just prefer simple and minimalist software for their daily life, and there's no place for the Rust ecosystem there. For this reason projects like dwm, st, dmenu, bspwm, sxcs, sxhkd, nsxiv, xmenu, xplugd, fzy, nnn, xbanish, scdoc and many others will never be rewritten in Rust or adopted by users who strive for simplicity rather than colorful terminal output. memory safety is just not worth it.
Judging by this list [0] even Python or Go have more chances to align with the philosophy that encourages building simple yet functional things. And I hope this trend of fresh starts continues.
Sure it's a bit silly to rewrite a nice simple tool for because it's the new fad. However if writing a new simple tool I'd certainly consider Rust.
How is Rust incompatible with aligning with the philosophy that encourages building simple yet functional things?
Yeah I saw this after, no idea why I read that wrong. First thing I do when I see a repo is try to figure out if it's being actively developed and if that makes a difference.
> Please feel free to open an issue. Note: Import does not make that much sense, but writing a generator that spits out the yaml file (or portion thereof) could be useful.
I did think after that this might be something suitable for a small Python script. I don't know any Go (and am too busy too learn), otherwise I would hack it together myself.
This was more of a sarcastic reference to https://github.com/mTvare6/hello-world.rs But I don't think Rust fits in here: https://suckless.org/philosophy/
> How is Rust incompatible with aligning with the philosophy that encourages building simple yet functional things?
I would say it attracts different kind of developers that in turn make respective design choices, and I believe Rust, its syntax, package management ecosystem and community reflect that. Can you write simple system tools in JavaScript or brainfuck (not trying to compare here)? Sure, but the thinking process, design decisions, approaches would be drastically different compared to what I'd consider good and elegant code.
ANSI C is probably the best balance you can get between product complexity, coding complexity and usability of the output (which again, has to be simple: writing something like Kubernetes in C is probably not the best idea, hence it was implemented in a more suitable language). Though there are some very good and complex products, like the Linux kernel, Redis or Varnish. All of them are very modular, as complex products should be.
Just by having a musl library and tcc [0] you can get a lot done. I'd prefer that over complexity that Rust toolchain involves and crates ecosystem mess.
Sure, here it is. Enjoy! It can do all the basic things, but stuff like error handling is rough (it will panic if it fails to parse something).
Hi, Newsraft developer here. Not that I was offended, but I just wanted to let you know that I use it daily and don't encounter segfaults with builds from release tarballs like at all. I'm trying to leave tag commits as clean as possible, but I admit that logical bugs can slip through :)
One thing I think I missed is that Newsraft is younger and simpler (I assume, at this stage it all fits in the head of one developer). Maybe this is where my estimate fails.
Anyway, I wish you success with your project! (Even if you're building it with an unorthodox language.)
Anybody can submit a patch to the Linux kernel (which is great of course). Any big names (long term kernel development) backing it?
That said, kernel development has different constraints to userspace application development. For kernel drivers for example, sometimes you really are pulling absolutely every trick out of the book just to squeeze enough performance out.
> Nobody said it will. But segfaults hardly come from poor design. They come from accidental mistakes, lack of static analysis, and gotchas that your language offers.
Sure, but there are a few simple patterns when used throughout that are quite reliable. There are quite a few books out there on writing safe and reliable C.
> > now it is harder to develop
> Only if you're a C programmer who doesn't know Rust.
Maybe, but I'm not yet sold that the added 'dance' you have to perform with Rust is worth excluding one type of bug.
> > and runs slower
> This is plan false. Please back it up.
Every C program can theoretically [+] be compiled to be the same as a Rust binary, but not every Rust program could be compiled to be the same as a C binary [1].
> Try using it for a week, and count for me how many times it segfaults on your face. (That is not to diminish Grigory's work, which I have nothing against.)
I use it quite regularly. Even more regularly I use C++, I simply program with it in the same way one would do using Java as pure OO and no raw pointer magic (except in rare, well tested cases). The less magic used, the more reusable your code will be in the future.
[+] Not exactly, but close enough.
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Linus Torvalds is one of them. And he is a hardcore C programmer, he was strongly against C++ in the Kernel when people were suggesting that.
> Sure, but there are a few simple patterns when used throughout that are quite reliable.
And yet, C/C++ programs segfault all the time. Memory corruption vulnerabilities are some of the most severe and common ones. There was a submission here, on HN, about it. There was something about Google adopting Rust on Android precisely because of this — in case you want to find it.
I've been a C (Kernel) programmer in the past. And I've quit precisely because it took too much of my time to debug things that a good language should normally detect for you. Now, my main languages are Rust and Haskell, and the compiler helps me eliminate a huge class of bugs. If it compiles, most of the time it works correctly.
> Every C program can theoretically [+] be compiled to be the same as a Rust binary, but not every Rust program could be compiled to be the same as a C binary [1].
What should I be looking for in [1]? And what do you mean here? "Theoretically", you could implement every possible C program in Assembly, but that's hardly an argument against C. We should be thinking here in terms of things that a programmer normally would implement in reasonable amount of time. A knowledgeable Rust programmer is by orders of magnitude more productive than a C programmer with the same experience.
The discussion we're having was already had many times here. I'm just repeating the standard arguments.
Rust also has more freedom to perform optimizations on your code than C, because Rust has so much more information about it. For example, in C, a carefully placed "restrict" keyword can speed up your program a lot. But if you're not careful enough and you fail to satisfy the "restrict" invariant, you get undefined behavior. In Rust, things are "restrict" by default due to borrow checker and the invariant is ensured in compile time.
The argument for C against Rust just doesn't stand a chance if you remember C's undefined behavior. C is full of it. Can you list all the conditions when it can occur in C?
> I use it quite regularly.
I meant using the OP program, not C language.
My interpretation of his stance so far was "I'm not going to block Rust support in the kernel and I'm not fundamentally against it". I think that's different from backing Rust - although feel free to correct me with a link to his email communications for example that demonstrates otherwise.
> And yet, C/C++ programs segfault all the time. Memory corruption vulnerabilities are some of the most severe and common ones.
There's a good chance that the kernel you are currently using was written in C/C++ and is really quite reliable.
> There was something about Google adopting Rust on Android precisely because of this — in case you want to find it.
Let's see how it goes for them, it's a good experiment for whether Rust really is suitable for kernel development. I know there is some concerns about using Rust for kernel drivers as a lot of speed-up comes from making 'unsafe' assumptions, i.e. seeing io_uring that should enable ultra fast networking. I suspect Android has other significant problems that will block this though.
> I've been a C (Kernel) programmer in the past. And I've quit precisely because it took too much of my time to debug things that a good language should normally detect for you.
I've done some small kernel programming in the past in both C and assembly, this was for safety critical code that (to my knowledge) is still in use today and is required to run indefinitely without software updates. On top of static code analysis, regression testing, unit testing, black box testing (dedicated team) - I would also purposely try to force all meaningful code paths during initial development to make sure that my assumptions about memory are correct.
> Now, my main languages are Rust and Haskell, and the compiler helps me eliminate a huge class of bugs. If it compiles, most of the time it works correctly.
These days I am mostly developing in C/C++ (fast and efficient), Java (reliable cross-platform behaviour), Python (haven't really thought through the idea yet or ML) and Bash (connect several parts together). I rarely run into issues, my C/C++ server based programs run for over a year, only being restarted to pull in new features.
> What should I be looking for in [1]?
Memory, or speed. Whichever C is optimized for it tends to win in. If it doesn't, it can be re-written to do so.
> And what do you mean here? "Theoretically", you could implement every possible C program in Assembly, but that's hardly an argument against C.
It's to say that C should be at least as fast/memory efficient as Rust, in the same way that assembly should be at least as fast/memory efficient as C. Let's not pretend there is no value to speed and memory, otherwise why are we bothering compiling Rust to binary and not just running it on the JVM.
> We should be thinking here in terms of things that a programmer normally would implement in reasonable amount of time. A knowledgeable Rust programmer is by orders of magnitude more productive than a C programmer with the same experience.
In C, likely. In C++? Maybe about the same. One thing Rust has is packaging, but this is also creating massive package chains which have big stability/security issues.
> The argument for C against Rust just doesn't stand a chance if you remember C's undefined behavior. C is full of it. Can you list all the conditions when it can occur in C?
I don't need to know the entire of the C language to use it effectively. The undefined cases are quite rare unless you go looking for them. There is a standard subset of features I use, and I look up the others as and when I need them. For example it is entirely possible to use Java 11+ by just knowing Java 1 and looking up some small changes to the standard libraries since.
The one thing I never understood is why Rust was created instead of a stricter C++ compiler/standard? In some jobs I have worked some of this stuff has been enforced by purposefully making the compile crash if you try to do some black magic - I'm sure it could be done more elegantly.
I think this would have been the easiest way to get C/C++ people onboard if 99% of their code just worked as is.
I quite liked the (C#?) method where you have to strictly mark code as "unsafe" in order to use some features. I remember reading some code where in the comments there was a brief discussion about why it exists and alternatives explored.
Some of my old code even had to be robust against bit flipping (extremely safety critical). We had many code paths that could only be entered if bits were flipped in the execution triggering a reset, but also we had methods for ensuring the data memory was not tampered. I/O operations were purposefully difficult to initiate so that even if the entire execution memory was corrupted, there was an insanely low probability it would start I/O without triggering a reset.