Live data from Hacker News

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

github.com

21–30 of 55 posts

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

#21

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

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.

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

#22

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

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?

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

#23

bc (1) is nice to have, but —for my purposes— less useful than dc (1), because it doesn't generate arbitrary binary output.

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

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

#24
post #16

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

Rust does not guarantee absence of memory leaks, does it? I think this is the general "rewriting solves all problems" fallacy, which is rarely true, but who wants to maintain existing code, if there is something new and cool? So we get rewrites which largely just add new projects that then have to be maintained in parallel, because they rarely are to completely replace the old (if at all) and at some point the new is…

I like Zig's approach much more than Rust. When you get fixated on one aspect and sacrifice everything for that, you get things like Perl, Java or Rust.

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

#25
post #24
post #16

Earlier quoted context omitted.

Rust does not guarantee absence of memory leaks, does it? I think this is the general "rewriting solves all problems" fallacy, which is rarely true, but who wants to maintain existing code, if there is something new and cool? So we get rewrites which largely just add new projects that then have to be maintained in parallel, because they rarely are to completely replace the old (if at all) and at some point the new is…

I like Zig's approach much more than Rust. When you get fixated on one aspect and sacrifice everything for that, you get things like Perl, Java or Rust.

So, massive success ?

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

#26
post #24
post #16

Earlier quoted context omitted.

Rust does not guarantee absence of memory leaks, does it? I think this is the general "rewriting solves all problems" fallacy, which is rarely true, but who wants to maintain existing code, if there is something new and cool? So we get rewrites which largely just add new projects that then have to be maintained in parallel, because they rarely are to completely replace the old (if at all) and at some point the new is…

I like Zig's approach much more than Rust. When you get fixated on one aspect and sacrifice everything for that, you get things like Perl, Java or Rust.

Major adoption across the industry,being taught at university courses, bootcamps, shipping in commercial OSes?

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

#27

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

I’d sleep better knowing the existing bc can’t write to ~/.profile than if it’s written in rust or not.

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

#28

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

Those will take time, nobody will re-invent Linux, likely it will come with the OS systems knowledge advancements from the last 30 years.

Redox-OS is one such effort.

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

#30
post #19

Earlier quoted context omitted.

Aren't most of the standalone wasm runtimes written in rust?

No idea, but according to this site: https://github.com/appcypher/awesome-wasm-runtimes there a wasm runtimes written in all kinds of languages. This does not appear to be a very challenging thing to do, but I haven't look at this closely.

Writing bytecode runtimes is a common thing since 1958 (see UNCOL), only a novelty for those selling WASM as some great invention never done before.

Only this year I started seeing WebAssembly conference talks actually acknowledging the history of bytecode based distribution.

Post reply on HN