Hacker News Reader

Comment by Sir_Cmpwn | Hacker News Reader

I'm getting less optimistic about Rust. At first, I liked that they were willing to make breaking changes pre-1.0 to get the language right. However, leading up to 1.0 they've decided to leave cruft in, in the name of getting the release out.

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.

View on HN

I'm genuinely curious what you mean by "leaving the cruft in". I haven't been following the release discussions very closely, so I don't know exactly what "crufty" things there are in the language/standard libraries.

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.

> I wish the process was explained a little bit better in The Guide,

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"

Can you cite a source? If it was on IRC, I'm willing to sift through logs to find it for you if you give me your IRC nick.

  > I've heard other stories about poor management of the 
  > project

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. :)

> Can you cite a source? If it was on IRC, I'm willing to sift through logs to find it for you if you give me your IRC nick.

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.

Ah, found them, logs are here: https://botbot.me/mozilla/rust/2014-12-10/?msg=27250537&page...

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.

Thanks for looking that up. I was under the impression that at least kmc is a part of the core team from my chats outside of there (and because he was +o), but it seems like I was mistaken. He was certainly in a position to ban me to shut the discussion down ;)

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.

Heck, I'm +o in there too, but they'd be crazy to put me on the core team. ;) Imagine waking up in the morning to find all their precious semicolons, vanished...

(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.)

Well, operators have the power to direct the discussion and silence people they disagree with, which kmc has done. Whether or not that's abuse is up to you but it does put them in a position of power among decision makers in the Rust world.

kmc is paid by moz to work on Servo using Rust

>I also see that your proposal seems to be to add header files to Rust

That kind of proposal should rightly be laughed out of IRC...

At the risk of repeating some arguments you've heard, does that really need to be in 1.0? Incremental compilation doesn't destroy backwards compatibility (unlike, e.g., moving threads out of the stdlib), and it isn't a "showstopper" feature (e.g. unboxed closures), it's a convenient trick that can be tacked on later. It's hardly the sort of thing that needs to delay stability for the majority of users.

If it's about incremental compilation, this is indeed correct. We've talked about doing incremental compilation post 1.0 and the module system is irrelevant to whether that is possible.

From the discussion, it sounded like you wanted Rust to copy C's compilation model with objects per file, but no reason why apart from mimicing C.

Nah, there are plenty of reasons other than "mimicing C" to use a similar model. One example is incremental compilation - right now, you have to recompile an entire Rust project every time you change even one file. Like I've said before, I don't want to rehash this argument here on HN, so let's not get too far into it. I just want to make it clear that I'm not just pulling this out of my ass.

I don't think it's unfounded, but you don't know Rust well enough to solve it in a way compatible with Rust.

I'm... not sure what you mean by this. Something like #include technically exists, but is absolutely not used everywhere, and is certainly not the 'default build system'.[1]

Where was this discussion held?

1: http://doc.rust-lang.org/std/macro.include_str!.html is what I'm thinking of here.

"Functionally equivalent" to, not identical to. I'm talking about the module system. You could literally replace any instance of:

    mod mod_name;

With:

    #include "path/to/mod_name"

and then run it through the C preprocessor and it'd work exactly the same.

The discussion was held on IRC.

This is absolutely not true. Rust has no textual substitution like the C preprocessor does, and includes a module system, which has namespacing.

I put together a small demonstration for you:

https://github.com/SirCmpwn/rust-poc

That is one, very, very tiny aspect of the C preprocessor.

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.

Well, you could move the mod { } to the included file to accomplish the same result (like the `namespace` keyword in C#), but that'd break the example I'm trying to give. I don't really want to rehash this argument on Hacker News, I'm just providing context. There are numerous flaws in the module system that derive from this basic point.

I'm not really a C guy, but isn't #include about using a module in the current scope? Because Rust's mod is for project structure definition.

I can't really effectively explain how all of this works without providing a lot of background on systems languages in general, especially background on how linking works. Sorry.

#include in C is just textual substitution of the contents of the specified file in place of the #include statement, there is not a concept of namespace in C.

>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

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.

I too felt the management of the community contribution in the project was kind of poor. At least that's what I saw last year; now sure how it's now since I didn't follow it after my enthusiasm waned and moved on. I still believe Rust is a very promising project and wait for its final release before doing anything.

What was poor about it? Could you cite instances?

Unclear design/coding/development guidelines on contribution submission resulted in effort wasted in developing the contribution. Slow review process. Took more than a month and repeated requests to get a resolution. Arbitrary rigid design decision that couldn't be circumvented even when resulted in bugs. No channel for design decision escalation in the event of a disagreement.

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.

Dang, that's a shame. I've generally had a good experience, and been impressed with the speed at which changes are reviewed and merged, but it only takes several instances to tarnish everything. If you can link to a specific issue/PR, I can pass it on. The team has been generally very good at fixing governance issues when they arise.

This isn't necessarily all bad, as people use it more this and OTHER problems will show up and will be worked out. As long as we don't get into HUGE breaks (like Py3) it's fine.

That's saddening to hear. Can you point out the discussion, so we can get a better idea what you mean?

I've linked it from my comment here: https://news.ycombinator.com/item?id=8741113

Also, the whole cargo thing is a disaster. One namespace for all libraries? This will work out great. Totally. Not.

It seems to work fairly well for PyPI, NPM and RubyGems (to name a few).

If that's the standard Rust is aiming for, than I'm very sad about it.

Well, it's been irritating for NPM to at least me. And presumably all the projects that have reinvented namespacing using dashes in their project names.

Agreed. At this point Rust is already looking rusty. A solution desperately searching for a problem. We need something to replace C (so we are told), but maybe Rust won't be that tool.

The C and C++ hate comes mainly from web developers and language hipsters. They dominate the echo chambers of HN and /r/programming.

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 hit the nail on the head but you didn't drive it far enough. You forgot to mention how those poor stupid little web programmers also secretly want to be awesome like you and that's why they keep doing this.

Definable not entirely true. I might be a language hipster (http://xkcd.com/297/) but I'm definitely not a web developer, except for back ends. The first time sharing system I used was a UNIX(TM) Release 6 system in the summer of 1978, and I started learning C after that, programming professionally in it starting in 1980. C++ in 1995, and I did several intense projects in it.

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.

>1978 >1980 >1995

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.

C++ is not a solution to anything I'm interested in (aside from the special case of perhaps wanting to use LLVM). If I was doing e.g. VLSI stuff that might be different.

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 take it you haven't programmed in Rust.

> 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 not replace C. Rust will merely exist.

Sure, Rust's goal isn't to convert all users of C everywhere. C is immortal; that'd be unrealistic. Our goal is indeed to exist alongside C—and to provide a more productive, more secure alternative. :)

> Rust will not replace C.

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 hate cowards behind throwaways.

Wanna say something stupid? Do it with your real nickname.

I do high performance systems software research and development. I mainly code in C++, and spent quite a bit of time in pure C.

I think Rust is awesome.

> " A solution desperately searching for a problem. We need something to replace C (so we are told), but maybe Rust won't be that tool."

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.

The whole comment is trollish. What does "We need something to replace C (so we are told)" even means?

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").

For what it's worth, I've been using Rust for over a year in my product (http://skylight.io) and it matched my needs pretty closely. Our product is a performance monitoring tool that runs inside of Rails apps, so it's important to us to keep the overhead of our "agent" small and controllable.

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.

I'm using Rust at my startup. The prototype version was written in F#, but that means you're anyways fighting memory allocation, which was the single biggest performance issue in my program. My system works on network traffic at line rate, so every allocation per packet is noticeable.

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.

Reply on news.ycombinator.com