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

31–40 of 55 posts

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

#31

Post by SoothingSorbet »

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…

They do, you may just not look very much into the ecosystem.

OSes - redox and many other smaller projects

git - pijul is novel, gitoxide is a pure-Rust git reimplementation

vim - Helix, based on vim and kakoune

>a lot of C code will be made memory safe in the future without needing a rewrite in Rust.

Sanitizers don't do what Rust does, and static analyzers cannot make C memory safe. You would have an easier time of bolting a borrow checker onto a subset of C++ than what you're thinking of, IMO.

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

#32

Post by mrob »

maxbond wrote: post #22
nineteen999 wrote: post #21

Earlier quoted context omitted.

Maybe we are not seeing rewrites of large OSS projects in Rust yet (eg. Linux kernel, Blender, LibreOffice) because the language is not (yet) ready for projects of that scale and complexity.

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 pledge/unveil system.

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

#33

Post by rfl890 »

mongol wrote: post #29

Seems there are multiple Rust coreutils implementation projects? I have heard about uutils, but this is another one?

Quoting the repo:

> The goal is to create clean, race-free userland utilities that are POSIX compliant, maximizing compatibility with existing shell scripts while minimizing bloat.

> It is not a goal to be compatible with GNU utilities, which are sometimes viewed as bloated and overloaded with rarely-used options.

> A similar project with the aim of GNU compatibility is https://github.com/uutils/coreutils

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

#34

Post by pmeunier »

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…

Many Rust projects have done cool new stuff. Alacritty is possibly the greatest terminal emulator on the market today. I'm not into cryptocurrencies, but Parity and ZCash are doing cool stuff in that space thanks to Rust.

I'm also the author of Pijul, a much simpler and more scalable (yes, both! why choose?) version control system, and of Sanakirja, an on-disk transactional allocator to write persistent datastructures (like B trees, ropes, radix trees, HNSW…).

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

#35

Post by jgarzik »

mongol wrote: post #29

Seems there are multiple Rust coreutils implementation projects? I have heard about uutils, but this is another one?

Just added this FAQ section to the README:

Because it is a FAQ, the major differences between this project and uutils are:

1. Wider scope: posixutils is far more ambitious than uutils from a breadth standpoint: posixutils will include bc, m4, c99 compiler, fort77 compiler, a cron daemon etc. uutils is far more limited in the scope of programs covered, mimicing GNU coreutils.

2. More minimalist: Each posixutils utility implementation is intentionally more minimalist, intending to avoid the bloat of supporting rarely-used, non-POSIX features. Our common denominator and baseline is the POSIX spec, then add non-POSIX features that users cannot live without.

3. Transportable: Each posixutils utility should look like normal Rust code, easily stand alone with little-or-no deps, and be used in another project. This project is MIT-licensed, not GPL licensed, to aid in that transportability goal.

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

#36

Post by jgarzik »

gavinhoward wrote: post #6

As the author of the default bc in macOS and FreeBSD, good luck. Also, while mine is in C, I have tried very hard to eliminate all memory safety bugs, and I think I have done pretty well. https://git.gavinhoward.com/gavin/bc/

Amazing work. Thanks and kudos. I definitely tested some early stuff vs your bc.

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

#37

Post by jgarzik »

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.

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

#38

Post by majke »

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.

Sounds like second system syndrome.

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

#39

Post by gavinhoward »

082349872349872 wrote: post #23
gavinhoward wrote: post #10

Earlier quoted context omitted.

If you're talking about the `P` command, I added an extension to my bc to do the same thing. It's the `stream` statement. But it's probably still more convenient in dc. https://git.gavinhoward.com/gavin/bc/

Exactly; also nice to see https://git.gavinhoward.com/gavin/bc/#ai-free . Lagniappe: 6581840dnP

Is that a dc quine? Cool! Thank you!

And yes, I hate AI.

Post reply on HN