The Case for Rust (in the base system)

[cracauer@]

I ran into this when I first started using Java back in the late '90s. I remember measuring 40-second GC pauses when the heap got into the gigabyte range. Fortunately Sun sunk likely hundreds of millions of dollars into it, and it's much, much better now. There are even GCs that guarantee maximum pauses in the millisecond range. I haven't tried them, though.

GC is a tradeoff game. Short per-GC times usually come with a CPU time cost, either in GC or in mainline code, or even in a substantially larger average resident heap.

The JVM offers a variety of algorithms (which are actually close variants of one heap management system), but none of them are silver bullets.

And you're not helpless even in a GC system. You can re-use memory you've already allocated. Sure, the language and platform will fight you every step of the way, but it's still less work than doing manual memory management. In my opinion and all that, of course.

When I was writing high performance Lisp code I was using as many preallocated buffers as I do in C, probably more. Not stirring the heap really matters. But safety is out the window, especially if you don't have array bounds checking.

 

[blackbird9]

Per that link: "Yes, Rust is more safe. I don’t really care" That's a very big thing about why anyone should consider Rust and if you DGAF about that, then I guess why is anyone who considers that important even talking to you?

Well, you CAN write high quality code in C, without buffer overflows or memory leaks, you just have to try. The team I work in has written large programs (millions of lines) in C which run reliably, with long program uptimes in production server environments. The openbsd code audit effort is another good example.

The techniques are rather well known, and apply just as much to other languages, not just to C. As Cracauer said when talking about his work in lisp, when writing high performance and/or long running code, (pre)allocate all your data structures in static memory, don't use the heap (ie, dynamic memory), which obviates the problems associated with heap fragmentation. If necessary write your own suballocation library that allows you to make guarantees about memory. Whenever you write into a buffer, assert that the size of the data about to be written will not overflow the destination buffer; if the assertion fails, the software is outside of its safety envelope and the code that called it needs to be fixed. The entire codebase should then be full of such assertions. Smart pointers are another option. These are just a few common examples, there are many other techniques you can use to make your C code safe and reliable. Of course the C compiler won't do it for you, you do have to do the work (and therein lies the appeal of languages that claim to do that work for you).

C is not blameless, of course, and is certainly far from perfect. For example I always preferred the pascal approach to strings which encoded the string length along with the string data, to the C library's null-sentinal approach. Although the problem is at least partly mitigated by later versions of the C library having added function variants that allow the length to be specified (strncpy, et al).

I'm not massively 'down' on rust, I'm sure it has some good ideas that may move software development forwards, and as it matures it may become a major language. I just don't think there is a strong case for re-writing existing reliable C code in rust. Or rather, there would have to be a very compelling reason to do so. And I do agree with many of the points that Drew DeVault made in his blog entry, he pretty much put into words what was floating around at the back of my mind on this subject.

 

[drhowarddrfine]

I've started dabbling in Smalltalk and Lisp lately. One of the things I noticed in my reading is the same thing I noticed when I dabbled in any other language. The concern gets brought up about speed and interfacing to other programs and hardware. The replies are always the same. "Don't worry. We can interface to C if you need speed!" and "Don't worry. We have a C interface if you need to connect to or work with X!"

Every language. All the time.

If you look at, perhaps, any software that needs an interface to something else, it's always to C. postgresql has whole sections in the documentation about their C interface. Smalltalk and Lisp talk about how their C interface. And on and on.

But you continue to find people wanting to create some new language that's better than C and I'm going to bet Rust has an interface to C, too.

 

[blackbird9]

"C to rust" reminds me a little of "perl 5 to perl 6" (or, dare I say it, even "C to C++"). The perl 6 team started off full of enthusiasm to create a hot new version that would fix all the hard problems they thought were wrong with the small (at least, before they kludged objects into it) and successful perl 5. They brought in some super high IQ people to work on it and set to work. Ten, twenty years later they were still discovering how hard it is to solve those really hard problems. And meanwhile, perl 5 is still the thing that gets used in production.

 

[kpedersen]

But you continue to find people wanting to create some new language that's better than C and I'm going to bet Rust has an interface to C, too.

Yep, this is pretty much my main concern with any new language. The future "default language" needs to be evolution, not something new from scratch with a hack to access C.

If they bolted on a C compiler frontend to Rust and vaguely integrated it into the language (perhaps unsafe{} tags). I think it might stand a chance. Until then, it is just another dependency store (NPM, CPAN, PIP) fetching tool.

C++ is not pretty but was definitely the right direction being able to directly interface with 99.999% of C. Possibly this has contributed to its success.

 

[Crivens]

I am really getting the impression that rust is being pushed forward for cool points. I for one don't want to be cool - that would mean I have a tag on my toe. As for what the future default language would be - how about D?

 

[blackbird9]

I am really getting the impression that rust is being pushed forward for cool points. I for one don't want to be cool - that would mean I have a tag on my toe. As for what the future default language would be - how about D?

Walter Bright (of C++ compiler fame) created 'D' two or three decades ago Sadly it never seemed to get mainstream traction. Perhaps it was overshadowed by Java and the continual evolution of C++ around the same time-frame. You can still get a D compiler nowdays, it's good to see that some real companies are using it too.

Home - D Programming Language

D is a general-purpose programming language with static typing, systems-level access, and C-like syntax.

www.dlang.org

 

[drhowarddrfine]

As for what the future default language would be - how about D?

I worked for a company that used an infrared controller. The frequency of data transfer for our competitors was 18khz. My boss was trying to figure out what frequency our IR transfer should be to which I asked, "Why be different?"

That's the problem with most of these new languages. They try to be different for the same of being different in the disguise of improvements. I see this all too often with questions on Stackoverflow where people are using all kinds of tools for HTML and CSS where the final produced code is..........HTML and CSS! Then they struggle to make it fit into their scheme of things and I ask "Why?" Why didn't you just start there instead of these grand and glorious things which are supposed to make your job easier but all it does is cause problems you have to fix later.

If you're looking for something else, you'll find something else, whether you need it or not.

 

[Crivens]

Well, D reads almost as a sane version of C++. That is where my vote would go if I was asked. Which I won't be.

 

[blackbird9]

I've started dabbling in Smalltalk and Lisp lately. One of the things I noticed in my reading is the same thing I noticed when I dabbled in any other language. The concern gets brought up about speed and interfacing to other programs and hardware. The replies are always the same. "Don't worry. We can interface to C if you need speed!" and "Don't worry. We have a C interface if you need to connect to or work with X!"

Every language. All the time.

If you look at, perhaps, any software that needs an interface to something else, it's always to C. postgresql has whole sections in the documentation about their C interface. Smalltalk and Lisp talk about how their C interface. And on and on.

But you continue to find people wanting to create some new language that's better than C and I'm going to bet Rust has an interface to C, too.

"Swig" is a useful tool for this kind of thing, I have used it myself and found it pretty good. https://swig.org/

 

[cracauer@]

I am really getting the impression that rust is being pushed forward for cool points.

At least for me it isn't pushed because of anything special about Rust as such. It is just that C is not enough for me and that C++ has jumped the shark. Rust is left as the only popular language offering more than C while keeping some basic properties. It almost doesn't matter what Rust does, specifically, as long as it offers what I miss about C and isn't C++>=20.

 

[cracauer@]

I've started dabbling in Smalltalk and Lisp lately. One of the things I noticed in my reading is the same thing I noticed when I dabbled in any other language. The concern gets brought up about speed and interfacing to other programs and hardware. The replies are always the same. "Don't worry. We can interface to C if you need speed!" and "Don't worry. We have a C interface if you need to connect to or work with X!"

Every language. All the time.

If you look at, perhaps, any software that needs an interface to something else, it's always to C. postgresql has whole sections in the documentation about their C interface. Smalltalk and Lisp talk about how their C interface. And on and on.

But you continue to find people wanting to create some new language that's better than C and I'm going to bet Rust has an interface to C, too.

You shouldn't need to go to C to write fast Lisp code when you use SBCL and know enough about it.

You must have an interface to C on Unix like OSes since you need to use system calls.

 

[blackbird9]

There has been a gap in the market place for a long time, and there have been many attempts. Objective C, C++, D, Go, Swift, Rust, etc etc. At least part of the problem is that some of these are tied to particular corporate sponsors, and hence to those sponsors' platforms. The acceptance of some rust code into the linux kernel (I think something has actually gone in now?) has given rust a boost towards mainstream acceptance recently, which probably means that redhat and ibm are backing it.

I remember when C++ first came out, in the commercial world MS were pushing it as the answer to the GUI development problem, which it did seem a good fit to; there was heady talk of "class library factories", "software IC's" and visual programming, and it took off; at the time they needed something to replace VB. But nowadays the C++ feature bloat is both overwhelming and adversely effects productivity, at least IMHO.

 

[blackbird9]

Well, D reads almost as a sane version of C++. That is where my vote would go if I was asked. Which I won't be.

I'm sure they won't take any notice of me either! I'm neither "grey beard" nor "prominent" (thankfully!) ??

 

[blackbird9]

Rust might have a place in the base system at some point in the future. But I would find it more interesting to improve what already exists than doing a rewrite.

Having more people pushing for changes to C to improve for the next standard seems a better choice.

I started with rust in 2018 after having already put a good couple years into C++ then C then python & ruby. P.S. I'm actually realizing now it's more like over a decade and that I'm old lol.

Rust is both lovely and at the same time absolute garbage somehow. The ecosystem and tooling around Rust can be downright maddening to deal with. Delving into no_std for embedded systems can be somewhat of a nightmare. To be honest I would trust code I've built in C with a certed compiler against misra or certC more than rust and all the dependencies it tries to pull in for most embedded work.

I don't doubt that rust for the most part removes entire classes of bugs/issues; but the mental load for it's use is crazy high compared to almost anything else. It becomes very easy for one to have logic mistakes or bad assumptions. This only gets worse with the verbosity of the language and the number of keywords making readability absolute (excuse my french) shit.

Things that seem like great and wonderful ideas in rust often seem to become unused and neglected in favor of easier alternatives in code bases. Iterators are a good example of that. I don't see them in use for a lot of peers/coworkers code; I think a large reason for why that's the case is down to it being less readable to most programmers. Same with error handling and unwrap statements all over the place, even if there is a reason why.

Trying to decode some bastardized single line multi mapped and iterated statement over generics that use some magical sealed traits you don't have access to readily is a joke even as a concept. If there was a change I could force upon all rust code bases in the world it would be to force a 80char line limit and to have a stable ABI.

Suppose it's a bit of a long winded way to say I don't think rust has a place in FreeBSD yet.

It's good to hear someone's real-world experience with using rust for real work.

 

[msplsh]

The reason Rust and not D or anything else is that anything else has never obtained the momentum Rust has, thereby imparting the vibes that Rust has solved the problem where the others have failed and as this thread has shown, everyone operates off vibes.

 

[bakul]

You shouldn't need to go to C to write fast Lisp code when you use SBCL and know enough about it.

You must have an interface to C on Unix like OSes since you need to use system calls.

For some reason I thought you were a CMUCL user, not an SBCL user. I see there are more recent cmucl releases but no FreeBSD port for a few years.

 

[cracauer@]

For some reason I thought you were a CMUCL user, not an SBCL user. I see there are more recent cmucl releases but no FreeBSD port for a few years.

I took CMUCL from a university project to an open source project. When SBCL was forked off it I didn't want to make the tradeoff (drop "10% of the optimizations" in exchange for easier build and bootstrapping). I was wrong and the bigger community from the easier build quickly overtook CMUCL. By the time amd64 came along CMUCL only had an advantage in some floating point work (enabled by Raymond T., although I never learned what exactly he did with that FP).

 

[Jose]

I am really getting the impression that rust is being pushed forward for cool points. I for one don't want to be cool - that would mean I have a tag on my toe. As for what the future default language would be - how about D?

I had a serious crush on D at the turn of the millennium. And then he added a garbage collector. I remember reading a blog post by Bright where he described seeing the light and adding variadic templates or some such. Some C++ dood helped him see the light, of course.

Yeah, I got plenty of that with Java or C++, both of which have much larger communities around them and therefore many more high-quality libraries available. There was no point for me once D lost its simplicity.

 

[bakul]

I had a serious crush on D at the turn of the millennium.

Mistaking a crush for true love is a common human condition! You were lucky to snap out of it and not let it develop into limerence — a state of infatuation or obsession with another person that involves an all-consuming passion and intrusive thoughts

What Is Limerence? Everything to Know About This Intense Psychological State—And How It Differs From Love

You might be asking yourself, "What's the meaning of limerence?" We asked relationship experts to unpack this psychological state, discuss how it compare to love, and share their top tips for managing it. Here, learn everything you need to know about the meaning of limerence.

www.brides.com

 

[astyle]

"Swig" is a useful tool for this kind of thing, I have used it myself and found it pretty good. https://swig.org/

So, take a swig from one language, then another...

 

[Jose]

Trying to decode some bastardized single line multi mapped and iterated statement over generics that use some magical sealed traits you don't have access to readily is a joke even as a concept. If there was a change I could force upon all rust code bases in the world it would be to force a 80char line limit and to have a stable ABI.

This pretty much sums up my tiny bit of experience with Rust. I tried to write a trivial program that queried a database and did something with the results. "Multi-line mapped and iterated" is what I wound up with.

That OTW being FreeBSD, right ? ?

The One True Way is that there is no One True Way. Yeah, I did that on purpose.

 

[blackbird9]

I had a serious crush on D at the turn of the millennium. And then he added a garbage collector. I remember reading a blog post by Bright where he described seeing the light and adding variadic templates or some such. Some C++ dood helped him see the light, of course.

Yeah, I got plenty of that with Java or C++, both of which have much larger communities around them and therefore many more high-quality libraries available. There was no point for me once D lost its simplicity.

Oh dear; it seems Walter was seduced by the dark side, and didn't choose wisely Once you start down the dark path, forever will it control your destiny!

My first programming encounter with a GC was on an Oric home micro, which was a british 6502-based home micro sold in the early 80s. I wrote a contouring program in a mix of basic and assembler to take geophysical survey data and produce contour maps of it on the oric printer, which was a nice little 4-color pen plotter (ALPS mechanism) that you could connect to the oric micro. It was a pretty nice system at the time, and half the price of the BBC micro that was out of my reach financially. The IBM PC was still a remote dream. I discovered that when generating my contour maps, every five minutes or so the oric would hang for a couple of minutes while the little 2 MHz 6502 chugged away doing something, and then resume printing again from where it had left off. Mystified by what was happening, I read through the various books and magazines I had at the time (this was pre-internet) and discovered that the ROM basic interpreter had something called a garbage collector built into it, and that if you called a certain ROM entry point periodically from your program, you could force garbage collection to occur more frequently and thus avoid the periodic hangs that occurred when the interpreter called the GC itself.... ?

 

[blackbird9]

Mistaking a crush for true love is a common human condition! You were lucky to snap out of it and not let it develop into limerence — a state of infatuation or obsession with another person that involves an all-consuming passion and intrusive thoughts

What Is Limerence? Everything to Know About This Intense Psychological State—And How It Differs From Love

You might be asking yourself, "What's the meaning of limerence?" We asked relationship experts to unpack this psychological state, discuss how it compare to love, and share their top tips for managing it. Here, learn everything you need to know about the meaning of limerence.

www.brides.com

Ha, never heard of that before!

 

[Alain De Vos]

I had a serious crush on D at the turn of the millennium. And then he added a garbage collector. I remember reading a blog post by Bright where he described seeing the light and adding variadic templates or some such. Some C++ dood helped him see the light, of course.

Yeah, I got plenty of that with Java or C++, both of which have much larger communities around them and therefore many more high-quality libraries available. There was no point for me once D lost its simplicity.

Nim & F# have it's applications...