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

Why you should, actually, rewrite some of it in Rust

unhandledexpression.com

Post reply on HN
Print view View original

211–220 of 300 posts

Re: Why you should, actually, rewrite some of it in Rust

#211

Post by steveklabnik »

cyphar wrote: post #192
marcosdumay wrote: post #128

Earlier quoted context omitted.

Is it really harder than making autotools work? Anyone releasing software in C, Python, Haskell, Ruby, Lisp, or whatever language has extra work to do. I don't think there's any sizeable difference between any of them.

The biggest problem is that distributions have their own build systems and cargo just doesn't fit in a variety of different ways (not to mention projects that pin nightly compilers). Distributions such as Fedora and openSUSE need to have a package for everything installed on the system (and everything required to build said packages). Now take into account the you can have multiple versions of the same library in a s…

> The biggest problem is that distributions have their own build systems and cargo just doesn't fit in a variety of different ways

Fixing that is a big focus of this year https://github.com/rust-lang/rust-roadmap/issues/12

Re: Why you should, actually, rewrite some of it in Rust

#212

Post by AnimalMuppet »

tomjakubowski wrote: post #101
RcouF1uZ4gsC wrote: post #39

Earlier quoted context omitted.

Basically exception safety is a solved problem in Modern C++. If you use RAIIike it was meant to be used, exception safety is not that big a deal.

True, I guess, for "business logic"-y classes. Not true at all for data structures, particularly those that are templates.

How is it not true for data structures? Even templated ones?

Re: Why you should, actually, rewrite some of it in Rust

#213

Post by anarazel »

jeffdavis wrote: post #196

I am a fan of rust, but this article overstates the simplicity of C/rust integration. A few examples: * You may need to use PhantomData in your struct definitions to properly track lifetimes. Not sure I fully understand. * C functions don't always return. Sometimes they longjmp (c.f. PostgreSQL). Calls into C code need to prepare for this and it's not trivial nor does it generalize to all projects. * Integrating with…

Btw, are you planning to work on a thin integration layer between rust and postgresql? Sufficient to be able to write UDFs in rust? That's imo the most realistic start to get some experience w/ rust in the postgres community, and it provides value on its own.

Re: Why you should, actually, rewrite some of it in Rust

#214

Post by naasking »

falcolas wrote: post #19

Sigh. This again. Not all security vulnerabilities are due to pointer arithmetic or out of bounds execution or pick-your-rust-is-better-idiom. Heartbleed is a great example. It wasn't caused by an error with how C handles memory or strings or anything else. It was caused by failing to validate untrusted input. Rust isn't going to help you with that. Could the affected parts be re-written in a way where the boundary c…

> Heartbleed is a great example. It wasn't caused by an error with how C handles memory or strings or anything else. It was caused by failing to validate untrusted input. Rust isn't going to help you with that.

I think you'll want to check your facts again:

https://tonyarcieri.com/would-rust-have-prevented-heartbleed...

Re: Why you should, actually, rewrite some of it in Rust

#215

Post by steveklabnik »

GrayShade wrote: post #197
steveklabnik wrote: post #147

Earlier quoted context omitted.

As of the most recent release, that's now const USAGE: &str = "usage string"; and there's talk of maybe making it const USAGE = "usage string"; > The part I hated the most was the Rust macro language. We don't like it either; there's a replacement coming. We reserved the "macro" keyword before 1.0 and made the current one use the less-good "macro_rules" to help ease the eventual transition.

> We don't like it either But.. but.. Scheme macros are so nice!

Totally! It's not about the fundamentals, it's about things like "macros are global" and "almost entirely hygienic but sometimes not", stuff like that. Stuff that would be backwards incompatible to just fix.

Re: Why you should, actually, rewrite some of it in Rust

#216

Post by thephyber »

_dcwr wrote: post #139

As someone who really likes C and C++ I feel like the biggest reason for me not even thinking of Rust as a viable language right now is the community attitude. It seems so damn hostile to C and C++. Anyone who thinks C and C++ is viable is a misguided idiot, bad programmer, writing unsafe software, etc. to these people. Some badass below even just said that "writing C++ code longer than a few lines without UB is huma…

> I feel like the biggest reason for me not even thinking of Rust as a viable language right now is the community attitude

Kinda reminds me of the "coal vs. renewable energy" feud. The first tier arguments are formed around {economics, externalized costs, existing infrastructure, base load vs intermittent load} and then second-tier arguments align around {culture, history, identity, momentum, geography, political party}. You are making a second-tier argument against Rust when the article is making a first-tier argument for Rust.

I would argue that you are attributing to "the Rust community" the more outrageous attitudes which are a minority of the Rust community and ignoring the majority which have much more rational and banal attitude. And likely you are attributing the inverse to the existing C/C++ attitudes towards Rust (conveniently ignoring lots of the best arguments for Rust). It's exactly what happens in those feuds you described and in modern US politics (Democrats vs. Republicans, liberals/progressives vs. conservatives, secular vs. religious, etc). By focusing on the strawman arguments, you are missing the potential benefits of using a newer generation language.

Re: Why you should, actually, rewrite some of it in Rust

#217

Post by Const-me »

steveklabnik wrote: post #205
Const-me wrote: post #204

Writing manually-vectorized SIMD code is the only way to approach advertised performance on any modern CPU. While there’s _some_ SIMD support in Rust nightly builds (but not in Rust stable), it’s just not good enough. For one thing, Intel only supports their intrinsics for C (C++ also gets that ‘coz compatibility) and Fortran. Another thing, Rust strong type-safety concept complicates SIMD code, especially when the c…

Yeah, SIMD is being very actively worked on; until then, you can link in an external assembly file, but that's not exactly the best UX.

Yep, assembly’s not the best UX.

When you’re coding assembly, you have to code everything in it, including code running on the scalar parts of CPU cores. With intrinsics you can code these parts the usual way, e.g. for( size_t i=0; … )

With intrinsics you can even compose your vectorized code the usual way, VC and Clang have __vectorcall calling convention for that, Intel has very similar __attribute__((regcall)).

Re: Why you should, actually, rewrite some of it in Rust

#218

Post by thephyber »

_dcwr wrote: post #139

As someone who really likes C and C++ I feel like the biggest reason for me not even thinking of Rust as a viable language right now is the community attitude. It seems so damn hostile to C and C++. Anyone who thinks C and C++ is viable is a misguided idiot, bad programmer, writing unsafe software, etc. to these people. Some badass below even just said that "writing C++ code longer than a few lines without UB is huma…

> all these FUBAR C/C++ systems (...) work well enough to transfer that kind of garbage to me

I don't think you read the article. The author specifically cites lots of different types of hyperbolic "rewrite everything in Rust!" arguments and explains how this article is not that and he doesn't advocate for that. The author of the article advocates "surgically replace weaker parts but keep most of the project intact." This is exactly how Mozilla is dogfooding Rust in Firefox.

And no one is arguing that all of those C/C++ systems you mention are "FUBAR" -- that's a strawman. Rust advocates, as well as advocates of many of the newer-generation, lesser-used languages advocate for advancing programming beyond the languages designed in the 1970s. We've had an explosion in programming language diversity over the past 30 years and we've developed some great research on how to prevent certain classes of defects. The longer those C/C++-written systems exist without a rewrite in a safer language (or thorough audits including massive amounts of fuzzing), the larger the impact of inevitable non-zero-probability of those vulnerabilities which Rust prevents.

The article's author completely admits that at their best, C/C++ developers can avoid all of the problems that Rust solves. But not everyone is a rockstar and not everyone performs at 100% all of the time. Rust is written for humans and the compiler is a strict nanny, preventing you from getting yourself into danger, the same ways you can with C/C++ memory issues. It also has tooling for unit tests, benchmarking, fuzzing, and standardizing code formatting conventions in the language. You can bolt these things onto C/C++, but that means that you have to go find them (which new developers won't do unless sufficiently motivated to).

Re: Why you should, actually, rewrite some of it in Rust

#219

Post by steveklabnik »

Const-me wrote: post #217
steveklabnik wrote: post #205

Earlier quoted context omitted.

Yeah, SIMD is being very actively worked on; until then, you can link in an external assembly file, but that's not exactly the best UX.

Yep, assembly’s not the best UX. When you’re coding assembly, you have to code everything in it, including code running on the scalar parts of CPU cores. With intrinsics you can code these parts the usual way, e.g. for( size_t i=0; … ) With intrinsics you can even compose your vectorized code the usual way, VC and Clang have __vectorcall calling convention for that, Intel has very similar __attribute__((regcall)).

Yup, absolutely. My understanding is that an RFC is currently being written, so it's gonna be a little while to get into stable, but not forever. We'd have liked to have had it sooner, but some stuff happened, that's just how it goes sometimes.

Re: Why you should, actually, rewrite some of it in Rust

#220

Post by jeffdavis »

anarazel wrote: post #213
jeffdavis wrote: post #196

I am a fan of rust, but this article overstates the simplicity of C/rust integration. A few examples: * You may need to use PhantomData in your struct definitions to properly track lifetimes. Not sure I fully understand. * C functions don't always return. Sometimes they longjmp (c.f. PostgreSQL). Calls into C code need to prepare for this and it's not trivial nor does it generalize to all projects. * Integrating with…

Btw, are you planning to work on a thin integration layer between rust and postgresql? Sufficient to be able to write UDFs in rust? That's imo the most realistic start to get some experience w/ rust in the postgres community, and it provides value on its own.

I've made some progress. Not quite as thin as I had hoped ;-)

I really need procedural macros to stabilize, otherwise it just puts too much pain on the UDF author.

Post reply on HN