Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory-safe, clean implementation of classic Posix "BC" calculator

github.com

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Memory-safe, clean implementation of classic Posix "BC" calculator

#41

Post by stefs »

majke wrote: post #38
jgarzik wrote: post #37

Earlier quoted context omitted.

Most utils are 25+ years old. It is worth revisiting, dropping old cruft, entrenching UTF-8 support, and other areas. Smaller and fresher.

Sounds like second system syndrome.

I don't think that's necessarily the case. Maybe the original version was designed around limitations and assumptions that made sense back then, which aren't there or true anymore. Maybe there were design decisions that turned out to be mistakes in hindsight but can't be dropped due to compatibility reasons.

Re: Memory-safe, clean implementation of classic Posix "BC" calculator

#42

Post by anthk »

- DC to convert between bases and if you like RPN.

- Calc it's better if you want to cover complex numbers: https://github.com/lcn2/calc

- Qalc from libqalculate in order to solve some equations in legacy machines. It's lighter and smaller than Maxima, but not as complete. - -

- Maxima for anything else, the biggie one. This will cover calculus. Gnuplot will work fine as a plotter for the previous tools.

Re: Memory-safe, clean implementation of classic Posix "BC" calculator

#43

Post by dgacmu »

uecker wrote: post #13

I am still waiting for Rust people to do something new and innovative. I acknowledge that Rust itself is innovative, don't get me wrong, But where are the true proof-of-concept projects such as the Linux kernel, qemu, git, postgresql, vim, etc. of the Rust world? Rewriting code is a waste of time of time, fragments the eco system, and introduces new bugs. And with a new focus on memory safety and analysis tools and s…

1) (new and innovative) and (safer, written in rust) are orthogonal attributes.

(2) Rewriting isn't necessarily a waste of time. There are rewrites of some wretchedly vulnerability-prone (and poorly extensible) core infra like ntpd, sudo, etc., that are sorely needed. Plus, rewriting them in a safer language will make it easier for future innovations, because it won't be as terrifying to try to have on them without introducing yet more vulnerabilities.

(3) Same applies to using rust for future components within the kernel and major browsers.

(4) Sanitizers are great, but they're not as strong as what you get from a memory-safe language. Most importantly, sanitizers only check where your tests cover.

(5) ripgrep. It's not a rewrite of grep, it's a rethink, and it's amazing.

Re: Memory-safe, clean implementation of classic Posix "BC" calculator

#45

Post by teo_zero »

jgarzik wrote: post #37
teo_zero wrote: post #11

Am I the only one who thinks we need less short-lived tools written in memory-safe languages an more system infrastructure written in said languages? Don't take me wrong, I like when someone creates a better version of something existing. For example, ripgrep is fantastic. But seeing the recent trend of rewriting whatever in Rust just because, I can't help wondering why I should bother whether bc leaks or not...

Most utils are 25+ years old. It is worth revisiting, dropping old cruft, entrenching UTF-8 support, and other areas. Smaller and fresher.

> dropping old cruft, entrenching UTF-8 support, and other areas.

I couldn't possibly disagree. My point is that focusing on ownership, lifetime, etc. (the most prominent features of Rust) shouldn't be goals for a tool that's invoked to perform a few quick calculations and shut down immediately after.

Re: Memory-safe, clean implementation of classic Posix "BC" calculator

#48

Post by Thiez »

majke wrote: post #38
jgarzik wrote: post #37

Earlier quoted context omitted.

Most utils are 25+ years old. It is worth revisiting, dropping old cruft, entrenching UTF-8 support, and other areas. Smaller and fresher.

Sounds like second system syndrome.

Adding UTF-8 support in 2024 is hardly second system syndrome. Note that these re-implementations generally try to be compatible with the original rather than starting with a completely new vision, another sign that we're not suffering from SSS here.

Re: Memory-safe, clean implementation of classic Posix "BC" calculator

#49

Post by yjftsjthsd-h »

jgarzik wrote: post #37
teo_zero wrote: post #11

Am I the only one who thinks we need less short-lived tools written in memory-safe languages an more system infrastructure written in said languages? Don't take me wrong, I like when someone creates a better version of something existing. For example, ripgrep is fantastic. But seeing the recent trend of rewriting whatever in Rust just because, I can't help wondering why I should bother whether bc leaks or not...

Most utils are 25+ years old. It is worth revisiting, dropping old cruft, entrenching UTF-8 support, and other areas. Smaller and fresher.

> It is worth revisiting, dropping old cruft, entrenching UTF-8 support, and other areas.

I certainly won't say anything against supporting UTF-8 absolutely everywhere, but "dropping old cruft" is IME usually what people say right before dropping useful features or breaking platforms that are actively in use.

Re: Memory-safe, clean implementation of classic Posix "BC" calculator

#50

Post by yjftsjthsd-h »

mrob wrote: post #32
maxbond wrote: post #22

Earlier quoted context omitted.

What is the lack of a Rust equivalent to all those projects is because they already exist and work well, and Rust programmers aren't as mad to rewrite things as the stereotype suggests?

I disagree that they work well. A quick search of the CVE database will find many vulnerabilities that could have been prevented by rewriting in a memory safe language. Ideally, it should be done. However, rewriting those large projects would be a very difficult task, so it's probably not the best use of resources when there are still relatively easy security improvements available, such as implementing OpenBSD's ple…

Oversimplifying, there are two metrics: Bugs, and features. You're pointing out that the existing ones have bugs, parent comment is pointing out that the existing ones have features. Rewrites tend to have less of both.
Post reply on HN