I suppose pretty much everyone here already knows, but when making this specific type of comment ("I'm far more productive in Rust than C"), can you please disclose that you are one of the core people involved in Rust/Servo?

It's almost like Chuck Moore coming on HN and saying he finds Forth to be the most productive language. Of course it is, for you. (Nothing against the productivity of Forth or Rust.)

I'm a relative beginner in both Rust and C and I'd like to say that, as much as the learning curve for Rust could be better, even for a beginner, Rust is light years ahead of C, especially if you've used a more modern language. And using a hash table as an example is actually pretty sharp. Someone used to python might not know how much of a pain any type of container is in C. You could reasonably make the case it's easier to use hash tables in assembly -- the C language does you essentially no favors.

Rust is quite amazing, though. Very slick, to the point where I use it and I don't care that much about things running fast or with low memory requirements, I just want something with the syntax and comprehensibility of python/ruby/etc (at least compared to erlang/elixir, which I'd otherwise use -- not having local mutable variables makes things a bit more puzzling for no reason like three times a day) and the sweet tools from haskell, and Rust fits the bill.

I've personally experience very tangible productivity gains once I got past the (very steep) learning curve.

The compiler will catch many errors that other languages consider logic errors; if your source code compiles, it tends to run as expected.

As for the disclosure: I'm a normal software programmer, and haven't written a single line of code for rust's compiler and tooling.

people write better c than c++ because they are less tempted to over-architect. We've all come across terrible meta-templated c++ code with abuse of OOP all in the name of "information hiding". The main problem against c is the puny standard library. It would be nice to have a few more built-ins.

I think c++ without inheritance would be a very nice language.

C has so many design flaws, from the lack of reasonable iterators to null pointers to the preprocessor to bizarre type syntax to switch fall through to terrible error handling to no generics, etc. The attempts to patch the more broken parts of its design (e.g. ergonomics favoring signed induction variables in for loops) have resulted in more problems (e.g. signed overflow being undefined behavior). As a language from 1978, it was good in its day, but it's not worth saving anymore. It should become a respected piece of history.

I am always startled by people who hate inheritance "lock stock and barrel". I have long-running memories of being utterly appalled by multiple inheritance - all the way back to having to learn how to answer those damn "how many pure virtual base classes can dance on the head of a pin?" type questions in my 3rd-year C++/soft-eng class.

But single inheritance, used judiciously, has really led to some vastly better designs in my experience and doing away with inheritance would generally mean those designs would just be redone with a clumsy "let's fake up inheritance" interface.

I think you can write bad code in any language. Bad C++ is especially egregious, as it's possible to make the bad code practically incomprehensible even at a surface level. However, I suspect that carving feature after feature away from C++ leaves a language that is now just as good for writing toy programs ("hey, look how elegant the language is now that pesky inheritance/template/exception/<insert hated feature of choice> is gone"), but will now allow you write verbose and shitty (but shallowly more understandable) code in place of the C++.

I do find the sheer size of C++ objectionable (the usual arguments about how nearly all C++ programmers seem to program in subset "house styles" of the language). I am generally very suspicious of efforts to replace C++ that come from people who don't seem to understand it at all, however. Generally I like Rust in this regard as the Rust approach seems to display a mature understanding of what was actually good about C++ (constrast: Go).

What do you want to use inheritance for? In my experience, it is usually better to use composition and sum types.

Inheritance is usually really great when you want to extend the type outside the context it was created in. GUI is a very clear example of that where composition may work but is greatly tedious (reimplementing the whole interface, exposing it, and rewiring), and sum types are right off the bat inapplicable.

C was already quite poor in 1993 when I got to compare it with Turbo Pascal 6.0 for MS-DOS, my main tool at the time.

With all these years the amount of UB, memory corruption issues and security exploits only got bigger.

We need a major IoT meltdown to get rid of it, unfortunately it won't happen until the industry lets UNIX clones go.

> We need a major IoT meltdown to get rid of it, unfortunately it won't happen until the industry lets UNIX clones go.

Rust isn't going to stop IoT makers from leaving ports open and default passwords set.

No, but it may protect (to some degree) those that do use good authentication practices from also being exploited from exploitable libraries.

Bad defaults is a problem with IoT devices, but far from the only problem.

No, but there is a whole class of errors related to UB, memory corruption and data conversions that just by avoiding C will never happen.

You don't even need Rust, Algol 68 would be enough.

> unfortunately it won't happen until the industry lets UNIX clones go

Redox is a Unix-like system.

UNIX like is not the same as being UNIX.

UNIX is married with C by design, just how browsers are with JavaScript.

Actually you are right in one thing, if Redox offers POSIX support then it needs to sandbox them.

In the context you said "Unix clones", it sounded pretty obvious you were including Linux in there. Linux is a "Unix-like" rather than an Unix.

I was including Linux there, as it follows a standard UNIX architecture.

There is a big difference in having POSIX support and being a UNIX.

Windows, IBM i, IBM z/OS, Unysis MCA ClearPath, Green Hills INTEGRITY OS, Genode and many other OSes have POSIX support, yet their architectures have nothing to do with UNIX.

But absolutely no one forces you to use inheritance.

Not using a feature X yourself means you might still need to deal with code written by somebody who uses the feature.

In lesser languages this tends to translate to "you need to deal with code using bizarre pre-processor coding and/or external code generators". glib*-stuff is a neat example for the former (although a lot of it's code and most of the architecture is overall bizarre, not just the pre-processor parts), things like Qt and some libraries parsing stuff using generated parsers / lexers are typical examples of the latter.

> The amount of time I spend writing for loop boilerplate alone is worth the price of admission.

This can be solved with a templating system, not a new language.

A templating system is a new language.

An extremely minimalist one that will transfer to an language, including creating rust boilerplate.

Obviously, I wasn't implying for loop boilerplate is the only problem with C.