C is an extremely simple language.
Rust is one of the most complex languages I have worked with (most of that complexity could have been avoided with a better language design).
So no, I don't consider them related in any ways.
Rust is one of the most complex languages I have worked with (most of that complexity could have been avoided with a better language design).
So no, I don't consider them related in any ways.
Are you saying that the ownership/borrowing model for memory safety was a poor choice, or that it's possible to make a language on that model that has vastly less complexity than Rust?
Because your phrasing implies the second, but I don't think I've ever heard anyone make that claim before (presumably because there's no such language lying around anywhere, so it seems hard to defend).
If the first, then I'd point out that wouldn't be a language design flaw, but rather a flawed goal (ie a goal that proved too complex to achieve) - their goal was a memory safe language that didn't rely on a GC, and the resultant design complexity is basically the best example of a way to solve for that goal so far. I'm sure there will eventually be simpler options, but I don't think you can blame designers for not having access to undiscovered techniques. That's what most anti-Rust arguements boil down to.
If you just mean you don't like the syntax, then yeah, I agree, it's a bit alien for me too, but I hardly concider that anything beyond personal taste and the difficulty of learning something new.
For example there are multiple syntaxes for adding annotations or directives to the code. Some things are written very differently compared to other languages for no apparent reasons (e.g. derive). Some keywords have different meaning in different contexts (e.g self and type). And so on...
Basically, there are some rough edges that shouldn't really be there
> C is an extremely simple language.
It could be, however considering a language complexity in isolation is misleading. C shifts the memory management correctness to the user, which adds significant operational complexity.
Every once in a while somebody writes that 6502 assembly is extremely simple. Well, yeah, but try to do a division.
> most of that complexity could have been avoided with a better language design
Can you elaborate the specifics? I do program in Rust, and most of the complexity is due to two factors - memory management (which causes a significant proliferation of types, for starters) and low-level control (which requires extra complexity; stupid example: stack vs. heap allocation). None of them can be avoided, without shifting the level of the language (which is certainly fair; if one doesn't need lower level control, there are other languages which can be more developer-efficient).
C is simple compared to others, however it is far from "extremely simple".
The language i'd call extremely simple (while still being usable) is Wirth's Oberon-07[0]. Note the "-07" part, there have been a bunch of "Oberons", many which add a ton of additional stuff, not all Oberons are the same or even can be called simple. Oberon-07 however was designed to be simple while also being usable to create a full GUI OS on a custom architecture[1].
[0] http://people.inf.ethz.ch/wirth/Oberon/Oberon07.Report.pdf
Well, I suppose the standard library is actually, well, standard, instead of a de facto standard.
Do you have material I can read about this? Perhaps some of this can be incorporated into future editions of Rust to improve ergonomics.