> So just to be clear, is your position that the demo could have been better if it were written in C?

No. But that abusing a language to create compression, doesn't address the day to day case in any way or shape.

> Bringing up extra architectures supported by GCC/Clang is irrelevant to the discussion.

Hardly. I made more than one point. Size was not only it. C comes with the flexibility that it will compile for a lot more embedded hardware than Rust will.

LLVM is rustc's backend, and I am aware of that, but Rust has also had a lot of teething problems with actually compiling to many of those architectures. Its young enough that they don't matter yet, because Rust isn't targeted to every platform that LLVM supports yet.

Things like zinc and rfs are experimenting in this area, to see how feasable it is to have Rust replace C for embedded, but they're still experiments right now.

> And header files are not libraries!

No, they just allow you to link against them.

And the C PreProcessor is (probably, there's some debate) Turing Complete. So "header files are not libraries" is really not clear when it comes to C. Sometimes they are. Sometimes they aren't. Header-only libraries are in common use.

For example, NULL is a very useful C macro, that is used just about everywhere, that is usually accessed via <stdlib.h>

You could just add:

#define NULL (void *)0

But there isn't a need to, because of dead code elimination.

The same dead code elimination that applies to C's inbuilts, isn't yet applied against Rust's.

Which means that C gets the flexibility to use any code, and in Rust you shouldn't use the standard library?

That being a first class thing is entirely a sign that Rust is still a young language.

> Using a different malloc is as easy as "extern crate alloc_system". I do it when testing Servo when I want to make use of the platform native malloc instrumentation. It's far easier than in C, in fact.

#include <jemalloc/jemalloc.h>

And add -ljemalloc to the compile list.

I really don't see where its hard to link out to another malloc implementation.

So I can do it if I need to... But I don't for most use cases. Especially not to reduce executable size.

> Just use rustup and switch to the nightly channel.

Awesome. Try selling that to anyone developing on embedded hardware's manager, when Rust Nightly is... A nightly.

> Unstable features are only available on nightly Rust.

It comes with nearly a guarantee that something will be unstable.

> Xargo makes cross platform package management incredibly easy; in fact there's nothing like it in C land.

So its a package manager that hooks into LLVM's cross-compilation targets?

Which C does have as well, through clang.

Xargo and Cargo are nicer than make or cmake. They are. More modern technology, and they have better adoption because the language has used them since really early days. That is fantastic, and I do wish C had gone that way at some point, but its an old hat now.

My cross-platform stack is more complex:

* musl

* gcc with multiple backends (the most complex part!)

* make

But right now, today, it produces executables that:

* Are smaller than Rust's equivalents, by a large margin.

* Aren't always possible for Rust to produce.

> There are zero good reasons why, in 2016, a command line Web fetching tool should be written in C.

I'm sorry, but I highly disagree.

Maybe wget could be rewritten in Rust, for those distros where the platforms align with what Rust can produce.

But wget is just a commandline web fetching tool.

Curl isn't.

It's a library.

Used by manufacturers of devices that use SOCs and a ton of other bare-metal systems.

I'm not arguing against Rust here.

I'm arguing against Rust, today.

The progress of the language is great.

The premise of the language is great.

The tooling of the language is great.

It is fast becoming what we need, but it isn't there today.

It will be, soon.

My prediction?

All I've just said will be irrelevant in 2 years, maybe less.

And that'll be a good thing.

I'll be happy when it happens.

But today?

I can't accept Rust Nightly, I can't accept not using the tools the language gives me, and I can't accept binaries that the SOCs I've used can't even load into memory because of their size.