17 ms·
C++ design goals in the context of Rust (2010)
- actsasbuffoon 12y agoThe post is interesting, but was written in 2010. As you'd expect, some of the details have changed since then. For instance, garbage collected pointers have been moved out of the core language into a library.
- sanderjd 12y agoI didn't realize how old it was until I got to the bottom. It's cool how the project has stayed true to the goals lined out way back then. While lots of things have been changed and removed, as far as I can tell, none of those high level goals has been compromised, while some have even been reinforced.
- spelunky 12y agoComing from a modern language background like Swift it appalls me that I still have to use semicolons in Rust.
- coldtea 12y agoSwift came out less 2 weeks ago. As a beta announcement. So most certainly nobody comes from a "modern language background like Swift". Plus, it's not like semicolons are any big deal. If they are in a language, you add them and move on. Dead simple to add, minimal noise, instantly familiar to most C-derivative programmers. The only comminity that regularly complaints about them are hipster (for lack of a better term) javascript programmers.
- userbinator 12y agoIn fact I like semicolons because they give a clear delimiter to each statement or expression leaving them out and relying on whitespace like newlines is to me less readable since we're used to reading sentences with punctuation and without that everything runs together and you have to mentally separate them out while parsing not to mention it makes ambiguous cases like in JavaScript possible
- Pxtl 12y agoHonestly, if semicolons are the one feature somebody mentions when comparing modern languages, I don't want to work with them. I like Python. I think Python's whitespace-based blocking is interesting. But it is not the most interesting part of the language, and anybody who obsesses over that kind of stuff is just bikeshedding.
- JOHN_BONER 12y agoWell, semicolons have special meaning in Rust. In some contexts, like the last expression in a function or other expression block, if you don't use a semicolon it will return the value that the expression evaluates to. If you do use a semicolon, it won't return that expression's value. This is good, because it lets you avoid writing the "return" keyword all over the place, but it also lets you avoid returning a value with just a single character!
- robert_tweed 12y agoStuff like this is what currently puts me off Rust, in spite of some initial excitement about the potential it has. This is like optimising for the least readable code possible. I imagine it's going to be a nightmare in practise. Developers always seem to be complaining about having to type this or that, when they should be much more concerned with what they have to read! Really, I couldn't care less about typing a few extra characters. I can type pretty fast anyway and usually spend more time thinking than I do typing. What I do care about is being able to tell exactly what some code does by glancing at it, without worrying too much about whether someone wrote = instead of ==. Rust seems to be setting itself up for loads of those kinds of errors by trying to make the syntax terse at the expense of making it readable. I have high hopes for Rust and will reserve judgement until it is stable; from what I've seen it's still in a high state of flux. However for now, I much prefer the KISS approach taken by Go, in spite of a couple of things missing from the language (that will probably get there in the end).
- Dewie 12y ago> Developers always seem to be complaining about having to type this or that, when they should be much more concerned with what they have to read! Or maybe they find terser syntax to be more readable. If verboseness was always more readable, if not necessarily more "writable", than terseness, then no one would have a problem with Java since it has good IDE support, including autocomplete and generation of boilerplate code. But it turns out that it's not just a matter of being lazy typists.
- 12y ago
- Narishma 12y agoI was confused by the talk about keeping GC to a minimum until I noticed the article is 4 years old.
- deleted 12y ago[deleted]
- a8da6b0c91d 12y agoI don't know much about Ada but it seems like Rust vs. Ada is perhaps the more salient question than Rust vs. C++. Why was Ada not good enough in terms of a very "safe" language?
- Dewie 12y agoIsn't Ada geared more towards runtime assertions of correctness of programs (contracts and such) rather than ensuring memory safety? Can you statically guarantee memory safety in Ada when using manual memory management? It seems that one can choose to both use runtime assertions and static proofs of correctness proofs in Spark. But I don't know if that extends to statically ensuring memory safety in low-level code.
- pjmlp 12y agoAda was good enough, but it suffers from a bad reputation. On the early days it was deemed too complex to implement, although I would say C++ became even more complex. The companies that sold Ada compilers had customers with deep pockets, so Ada compilers were too expensive and required worksations to be used properly. When affordable Ada compilers became available, not many cared about it. Nowadays it has found its place where human lifes are at risk. Many avionic systems, train control systems, hospital devices are coded in Ada. I do attend FOSDEM regularly and also get the feeling its use is increasing in Europe thanks to the security exploits in languages tainted by C compatibility.
- pcwalton 12y agoAda doesn't have the same memory safety guarantees when using uniquely-owned data.
- toolslive 12y agoI want to comment on one quote from the article: """It's impossible to be "as fast as C" in all cases while remaining safe""". C is not that fast. One of the major problems is that it's close to hardware. 1970s hardware that is. Ken Thompson reportedly once said: "I'm not going to do nibbles. I have an 8 bit processor". A good example of how bad it has become is that modern processors have a rather good understanding of the 'string' concept, and offer instructions to process them. C offers a char*. Another problem is that C has strict contracts on how parameters are to be passed through, and combined with separate compilation units, this hurts compilers when they try to optimize things. I see greater potential for a safe higher level language to be able to align closer to modern day hardware than C. Some nice examples: Linear types can avoid garbage altogether, and coroutines can be expressed clearly and correctly using monads. On the other hand, raw performance is rarely needed, and most cycles are burned interpreting things like python and php.
- joelthelion 12y agoI see this comment pop back every once in a while. I'm sure your arguments have value; yet, for some reason, C is always among the winners in almost every benchmark I've ever seen, and also in my personal experience (except for numerical stuff where fortran might be a little faster). Why is that so? Do more modern languages need another twenty years before they can compete with C (and eventually beat it performance-wise) ?
- Dewie 12y agoI don't think that the OP is necessarily saying that there are ~mainstream languages that are faster than C; just that C is far from optimal when it comes to speed and how much it can be optimized. "Not that fast" doesn't necessarily mean that it isn't the fastest we have got.
- pjmlp 12y agoBecause that is where compiler vendors spent the last 30 years doing compiler backend optimization. When I started coding in the mid-80's C compilers were dog slow and no better than the alternatives (Pascal, PL/I, Modula-2, Cedar, ...). In fact, game developers would talk about high level languages the same way they talk about current modern languages vs C/C++, and use nothing else other than Assembly. However with UNIX spreading into the enterprise and bringing C along, it meant compiler vendors focused on optimizing for the language they were getting money for. The main issue when people compare languages, is that they forget although the design drives the implementation, not all implementations are alike.
- haberman 12y ago> The runtime features a separate C stack that's very quick (8 instructions) to switch to I hadn't heard of this -- is it still true now that segmented stacks are gone? If so, why does C need a separate stack?
- ehsanu1 12y agoNot sure this is up-to-date, but: http://doc.rust-lang.org/guide-ffi.html#stack-management http://doc.rust-lang.org/guide-ffi.html#stack-management tldr; C's stack is interleaved with Rust's stack.
- pcwalton 12y agoThis is out of date. Calling from Rust into C is now as fast as calling from C into C.