8 ms·

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

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.

steveklabnik 12y ago
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 http://doc.rust-lang.org/std/macro.include_str!.html is what I'm thinking of here.
- Sir_Cmpwn 12y ago
  "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.
  - steveklabnik 12y ago
    This is absolutely not true. Rust has no textual substitution like the C preprocessor does, and includes a module system, which has namespacing.
    - Sir_Cmpwn 12y ago
      I put together a small demonstration for you: https://github.com/SirCmpwn/rust-poc https://github.com/SirCmpwn/rust-poc
      - steveklabnik 12y ago
        That is one, very, very tiny aspect of the C preprocessor. And https://github.com/SirCmpwn/rust-poc/blob/master/includes.rs#L1 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.
        Sir_Cmpwn 12y ago
        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.
  - phaylon 12y ago
    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.
    - Sir_Cmpwn 12y ago
      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.
    - dbaupp 12y ago
      #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.
fngegngkg 12y ago
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.
- throwawayanonon 12y ago
  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.
  - oldmanjay 12y ago
    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.
  - hga 12y ago
    Definable not entirely true. I might be a language hipster (http://xkcd.com/297/ 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.
    - throwawayanonon 12y ago
      >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.
arthursilva 12y ago
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.
mushishi 12y ago
That's saddening to hear. Can you point out the discussion, so we can get a better idea what you mean?
- kibwen 12y ago
  I've linked it from my comment here: https://news.ycombinator.com/item?id=8741113 https://news.ycombinator.com/item?id=8741113
zcdziura 12y ago
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.
- steveklabnik 12y ago
  > 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 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.
kibwen 12y ago
> 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. :)
- Sir_Cmpwn 12y ago
  > 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.
  - kibwen 12y ago
    Ah, found them, logs are here: https://botbot.me/mozilla/rust/2014-12-10/?msg=27250537&page=27 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.
    - Sir_Cmpwn 12y ago
      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.
kzrdude 12y ago
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.
- Sir_Cmpwn 12y ago
  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.
  - kzrdude 12y ago
    I don't think it's unfounded, but you don't know Rust well enough to solve it in a way compatible with Rust.
scythe 12y ago
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.
- pcwalton 12y ago
  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.
ww520 12y ago
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.
- bjz_ 12y ago
  What was poor about it? Could you cite instances?
  - ww520 12y ago
    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.
    - bjz_ 12y ago
      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.
coldtea 12y ago
>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.
frowaway001 12y ago
Also, the whole cargo thing is a disaster. One namespace for all libraries? This will work out great. Totally. Not.
- dbaupp 12y ago
  It seems to work fairly well for PyPI, NPM and RubyGems (to name a few).
  - frowaway001 12y ago
    If that's the standard Rust is aiming for, than I'm very sad about it.
  - kybernetikos 12y ago
    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.

steveklabnik 12y ago

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 http://doc.rust-lang.org/std/macro.include_str!.html is what I'm thinking of here.

Sir_Cmpwn 12y ago
"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.
- steveklabnik 12y ago
  This is absolutely not true. Rust has no textual substitution like the C preprocessor does, and includes a module system, which has namespacing.
  - Sir_Cmpwn 12y ago
    I put together a small demonstration for you: https://github.com/SirCmpwn/rust-poc https://github.com/SirCmpwn/rust-poc
    - steveklabnik 12y ago
      That is one, very, very tiny aspect of the C preprocessor. And https://github.com/SirCmpwn/rust-poc/blob/master/includes.rs#L1 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.
      - Sir_Cmpwn 12y ago
        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.
- phaylon 12y ago
  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.
  - Sir_Cmpwn 12y ago
    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.
  - dbaupp 12y ago
    #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.

fngegngkg 12y ago

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.

throwawayanonon 12y ago
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.
- oldmanjay 12y ago
  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.
- hga 12y ago
  Definable not entirely true. I might be a language hipster (http://xkcd.com/297/ 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.
  - throwawayanonon 12y ago
    >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.

arthursilva 12y ago

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.

mushishi 12y ago

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

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

zcdziura 12y ago

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.

steveklabnik 12y ago
> 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 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.

kibwen 12y ago

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

Sir_Cmpwn 12y ago
> 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.
- kibwen 12y ago
  Ah, found them, logs are here: https://botbot.me/mozilla/rust/2014-12-10/?msg=27250537&page=27 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.
  - Sir_Cmpwn 12y ago
    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.

kzrdude 12y ago

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.

Sir_Cmpwn 12y ago
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.
- kzrdude 12y ago
  I don't think it's unfounded, but you don't know Rust well enough to solve it in a way compatible with Rust.

scythe 12y ago

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.

pcwalton 12y ago
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.

ww520 12y ago

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.

bjz_ 12y ago
What was poor about it? Could you cite instances?
- ww520 12y ago
  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.
  - bjz_ 12y ago
    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.

coldtea 12y ago

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

frowaway001 12y ago

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

dbaupp 12y ago
It seems to work fairly well for PyPI, NPM and RubyGems (to name a few).
- frowaway001 12y ago
  If that's the standard Rust is aiming for, than I'm very sad about it.
- kybernetikos 12y ago
  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.