Also, on the subject of the build system, while I too found it a bit confusing, only passing in the "main" file and having the compiler automatically compile and link all dependencies, over time I've come to love that feature. Especially coming from a (admittedly amateurish) C background, where I had to explicitly compile all of my source files into object code before linking them together, having the compiler manage everything for me cuts down on a lot of mental overhead (in my opinion, anyway). I wish the process was explained a little bit better in The Guide, but that's a documentation problem and not an implementation problem, which is much more easy to fix.
To make sure I'm understanding, you mean the process of only compiling the crate root?
Multi-crate stuff has historically been a pretty weak area of the docs, but we do have a whole guide on it now: http://doc.rust-lang.org/guide-crates.html
Please feel free to open up issues on the repository any time you feel the documentation is lacking, I'd love to fix any problems.
> I brought this up and had a long discussion about it and
> how it might be improved with the community, but then
> when core contributors showed up, the discussion was shut
> down with the justification that "1.0 comes in a month"
> I've heard other stories about poor management of the
> project
I'm "SirCmpwn", and the chat took place a few days ago in #rust on irc.mozilla.org.
> What stories are those? We have our fair share of people who like to spread FUD, so I'm curious which one you ran into. :)
I'm not really willing to name people who criticised Rust's project management here.
At no point in there is anyone that you're engaging with a part of the core team (which is to say: eddyb, zwarich, kmc, kimundi are all community members). So I still don't see how you can argue that the devs have shut you down with the 1.0 argument.
I also see that your proposal seems to be to add header files to Rust. What everyone there failed to mention is that Rust did use to have header files (called crate files, with a .rc extension), and we removed them to a great chorus of rejoicing. Rust is unlikely to tread that path again, after having discarded it once.
As for header files, that's just one possible solution (and one that I think would work very well and was surprised to hear had been removed). The problems are there, but header files isn't neccessarily the right solution - it's just better to present a solution than to complain with nothing to suggest.
(Personally, I agree that the module system is Rust's weakest point. I have yet to come up with any concrete solution for fixing it; it's a legitimately challenging problem.)
That kind of proposal should rightly be laughed out of IRC...
Where was this discussion held?
1: http://doc.rust-lang.org/std/macro.include_str!.html is what I'm thinking of here.
mod mod_name;
#include "path/to/mod_name"
The discussion was held on IRC.
And https://github.com/SirCmpwn/rust-poc/blob/master/includes.rs... is significant: the code included from another file is under a namespace, and isn't going to clash like randomly throwing #includes around will, and you don't need to worry about things like double inclusion...
In other words, I think this is a very superficial comparison, and I'm not even sure why it upsets you so. Rust won't be a perfect language for everyone, and that's okay.
That sounds like the perfect example of something that can be imporoved later and is totally orthogonal to the language design.
Semantics and syntax are what they need to get right pre 1.0, not the build system.
At least that's what I've encountered before. May be now is better. The thing for community contributors is that we all have other jobs to do. After spent huge amount of effort in development and exhaustive testing and the review process went nowhere, I just didn't care to bother about it anymore.
As someone who works with Rust on a daily basis to implement a browser engine, I can confidently say that Rust is not a solution in search of a problem for our domain. As an example, I implemented CSS "letter-spacing" the other day, and it worked first try after compiling. The layout code I write has a remarkable resilience to crashes; in the rare cases that it panics, it aborts safely. And I get parallelism "for free" as I implement more layout features, because the compiler stops me if I'm about to do something non-thread-safe. None of this applies to C or C++, and the end result is that we can move faster and write cleaner code.
Either he has a need to a "better/safer etc" C, or he doesn't. If he doesn't, then Rust isn't for him.
And it's not like anybody tries to market Rust to people who don't need it ("so we're told").
Since the agent runs inside of a Ruby program, our only good choices are Ruby itself or a language without a garbage collector (embedding a language with a GC inside a language with GC is asking for trouble -- take a look at the bug tracker for TheRubyRacer for some color). Our initial version of the agent was written in Ruby, but carefully controlling memory usage or performance in Ruby isn't really feasible.
We prototyped a new version of the agent in C++, but I personally didn't feel comfortable shipping a binary that would run in thousands of customers' Rails apps in a language that could segfault if you're not careful. We took Rust very seriously last November, even thought it was still very young, because it gave us a language with direct control over memory with compiler-verified guarantees that our program wouldn't segfault.
TLDR: Rust is a very good choice for writing performance or memory-critical code that will be embedded in a high-level-language.
Also, because it offers compile-time guarantees about safety, I expect it to expand the number of cases where people feel justified in embedding a low-level language for performance-critical problems.
C programs doing what I'm doing have traditionally had security issues. Since our code often runs in privileged locations, that's an unacceptable risk. Plus, Rust is vastly more expressive than C and not messed up like C++. And abstractions are cheaper, too. For instance, we use Generics + Traits as a way to keep flexibility and a plugin model per frame, while keeping the performance of static dispatch. C wouldn't be able to do that in an easy way.
When you mention you are a C programmer or like coding in C, they begin to blabber about C being legacy, Rust this, and Go that (languages they think are more like Python). All in an effort to cope with the insecure feelings they have because the C programming language and C++ (read: pointers) intimidate them.
You have to know pointers and manual memory management to program in Rust. Rust isn't there to save you from having to learn about pointers. Rust is instead a reaction to the empirically observed fact that nobody [1] has ever written a multi-million-line program with a large team in C or C++ without accidentally making dangerous memory-management-related mistakes, and "just program better" is an approach that has been tried, and failed, again and again and again.
[1]: OK, maybe the Mars rover and the like are counterexamples, but the extreme amount of verification required means that this approach is far too costly to be practical for most software development.
Rust will replace C in some new development that would have been done in C had Rust not existed, and some existing projects may switch from C to Rust (presumably, by components, rather than as big bang conversions.)
But, sure, its not like C will disappear just because Rust 1.0 exists. But it's not like anyone, ever has argued that to be the case.
I loathe C++, think it's way too dangerous, and C is obviously dangerous. I really want something safer to do systems programming in, that's successful (pretty much every prior alternative has failed in one way or another). Maybe Rust will be that.
I take it you haven't programmed in C11 or C++11? Modern C exists and C is too ubiquitous to be replaced.
I'm all for new projects and new languages but I just don't understand the hype around Go and Rust as a C replacement.
C99 and C11 add a variety of nice things, but they don't make the language markedly safer.
How long have you spent tracking down wild pointer and using freed memory errors? Every have to convince your boss to spend $$$ on a hardware debugger to find one? (ATRON, back in the 8088 days.) Or look at Mozilla's very real world motivation for this project.
I think Rust is awesome.
For example, the current build system is functionally equivalent to #including a bunch of C files in your C project and only passing one file to cc. I brought this up and had a long discussion about it and how it might be improved with the community, but then when core contributors showed up, the discussion was shut down with the justification that "1.0 comes in a month". I've heard other stories about poor management of the project and I'm just not as excited about Rust as I used to be.