5 ms·

I know it is about rust but I just don't see the point. If you want for whatever reason small binaries, rust is just wrong, take c (or asm). The closest you go

by _o_ 9y ago

I know it is about rust but I just don't see the point. If you want for whatever reason small binaries, rust is just wrong, take c (or asm). The closest you go to processor instructions, the smaller the binary is and rust is compleatly wrong lang. for that. Actually I think go has beaten rust at anything relevant... (I am c/c++ fan so I have no preference to either. Rust has become hacker news click bait.)

buster 9y ago
Can you explain why? How is C closer to processor instructions then Rust?
- ShroudedNight 9y ago
  My experience with using C was that, while it isn't necessarily closer to processor instructions, the instructions it does generate are far more predictable than the ones generated by Rust. And when it does surprise you, it's usually either a pleasant occurrance, or a compiler defect. This is a combination of many things, the big ones being: 1) My temporal experience with C dwarfs my temporal experience with Rust by at least an order of magnitude 2) The Rust ABI is [still - last I checked] opaque. 3) Every operating system environment I have interacted with has been deeply C-oriented, so the platform utilities for exploring the C to ELF / PE transition are much more accessible. I would love to be able to have the same familiarity, predictability, and indegenous feeling with Rust that I have with C, but each time I attempt to interact with the ecosystem, I come away feeling alienated and like I've just interacted with a 'the compiler knows best' cult.
  - _o_ 9y ago
    The only problem is that for some, rust is a silver bullet that is going to bridge lack of system dev. by learning another language. Sorry it does not work this way. C is just fine, we don't need rust, it can probably be implemented as another preprocessor layer of c. And quite frankly, I am failing to see, what benefits it provides if I throw c++ in equation.
    - ohazi 9y ago
      Rust is a systems language for people who prefer strongly typed languages. It has some relatively unique features that make learning and using the language a little quirky, but for many who end up liking it, C and C++ often no longer seem "just fine." Rust ends up being a genuine improvement for a lot of people. Also, unless you mean "write an essentially new language that happens to compile to C rather than machine code" -- you're delusional if you think you can recreate some of the nicer features of Rust as a new C preprocessor.
      - deleted 9y ago
        [deleted]
  - buster 9y ago
    - "the instructions it does generate are far more predictable than the ones generated by Rust." I am wondering how that might work? Isn't this extremely depending on the compiler and flags? To be honest, i would assume that a modern compiler with many optimizations would generate a very different list of instructions then some simple compiler. C has a large list of available compilers.. - "I would love to be able to have the same familiarity, predictability, and indegenous feeling with Rust that I have with C," To be honest, all that seems to be mostly time and experience. Surely you won't get the same familiarity with Rust compared to C in a fraction of the time. It just sounds like you feel comfortable enough with C and see no reason to change, which is good for you in a way :)
    - ShroudedNight 9y ago
      The best I can come up with is examples: enum State { UNINITIALIZED, STARTING, RUNNING, SLEEPING, STOPPING, TERMINATED }; struct Thread { State state; int32_t threadID; MemoryMap * memoryMap; LockTable * lockTable; }; The memory layout of a Thread object is highly predictible: +0 state, +4 threadID, +8 memoryMap, +(12/16) lockTable I can predict the symbol name for a function: Thread * createThread(void *stackArea) I know that stackArea is going to be in RDI, and the resulting Thread* is going to be in EAX (or their well-specified equivalents on another platform) switch (thread->state) { case UNINITIALIZED: case STARTING: error("Not ready yet"); break; case STARTED: sleep(thread); break; case SLEEPING: error("Already asleep"); break; case STOPPING: case TERMINATED: error("Thread is terminating"); break; default: critical_error("The world is on fire"); break; } Given a compiled set of instructions, I can link the compiled instructions corresponding to the switch statement (like a jump table) back to the C code. for(size_t i = 0; i < SOME_MAXIMUM; ++i) { unsigned char const working_value = input1[i]; unsigned char const mask = ((unsigned char) -1) - (working_value >> 7); output[i] = input2[i] &= mask; } I've probably screwed that up, and I don't claim that it's doing anything useful here, but assuming it was doing something useful, I would be able to identify the instruction associated with it, figure out if there was some deficiency present (like say, a conditional) and have a decent idea of how to fix it. Rust, on the other hand, does a bunch of things that are (so far) opaque to me. One example is passing a borrowed slice of something, and somehow, not just a pointer to the thing itself is getting passed, but also seemingly, potentially one or more boundary indices, as well as a lifetime (maybe?) Another example is a match on the type of an object, clearly [on second thought, perhaps not] there's some run-time state being kept around along with the explicitly declared fields inside that object, what does that object look like in a memory dump? As final example: generics, how and when do they get expanded into discrete functions? What do the symbols get named? How do I know if a generic expanion is likely going to overly prolific? Inlining and templates can do wonderous things for performance, but they can also drown it. Anyway, hopefully that wasn't too overwhelming, or ranty. You asked nicely twice; I felt compelled to give you a real answer.
- _o_ 9y ago
  Just go and compile hello world with this: https://bellard.org/tcc/ https://bellard.org/tcc/ And then with rust. Open your favorite decompiler and decompile both. C has again and again shown that less is more and it is going to stay that way. (Btw, it is really sad that you get downvoted based on your opinion.) Rust has become some PR stunt here, it is new hipster topic, but it has a long way to reach proficiency that developer is able to pull out from c. But knowlidge of programming is not enough, power of c is due to knowlidge that developer has and no tool is going to solve that (or he, he... garbage collector - pointing finger to java direction ;) )
  - jjnoakes 9y ago
    > it is really sad that you get downvoted based on your opinion That's not really what is happening. I'm guessing you are getting downvoted for a few specific things: * "If you want [...] small binaries, rust is just wrong" * "[Rust is not close to processor instructions]" * "I think go has beaten rust at anything relevant" * "Rust has become hacker news click bait" The general tone of your comment is a bit inflammatory, you make some claims with no reasoning, and you aren't contributing much to the discussion (even if some of these are just "opinions", not all opinions are relevant or useful in the context of any given discussion). I'm also a little surprised that you insult the folks who are reading this thread (folks probably interested in Rust, since it is a Rust thread) and then wonder why they aren't interested in seeing your comment.
    - _o_ 9y ago
      My opinion is right to the spot. The amount of posting for rust is inapropriate to the amount of posts every other language has while it seriously doesn't offer something revolutionary to developers. All fans are having c++ to be able to do same things or more, AFTER they have figured out their limits. c/c++ problem is not type safety but rather that it allows people doing anything. But this is also a huge bonus. (Btw, I don't care about downvoting, but it was somehow strange to see it)
      - jjnoakes 9y ago
steveklabnik 9y ago
The Rust team doesn't share this opinion, FWIW. We care about binary size and being able to do things like this to make your code as small as possible.
pjmlp 9y ago
Lots of languages are as close as C to processor instructions, unless you are thinking of targeting PDP-11 systems.
vardump 9y ago
> ...take c (or asm). The closest you go to processor instructions... Modern C isn't particularly close to processor instructions. 20-40 years old C is reasonably close to that benchmark -- or more like 20-40 years old C compilers.
littlestymaar 9y ago
Well, there are some people on the demo scene using Rust (and even winning[1]). I guess they disagree with you. [1]: https://www.pouet.net/prod.php?which=68375 https://www.pouet.net/prod.php?which=68375

by _o_ 9y ago

buster 9y ago

Can you explain why? How is C closer to processor instructions then Rust?

ShroudedNight 9y ago
My experience with using C was that, while it isn't necessarily closer to processor instructions, the instructions it does generate are far more predictable than the ones generated by Rust. And when it does surprise you, it's usually either a pleasant occurrance, or a compiler defect. This is a combination of many things, the big ones being: 1) My temporal experience with C dwarfs my temporal experience with Rust by at least an order of magnitude 2) The Rust ABI is [still - last I checked] opaque. 3) Every operating system environment I have interacted with has been deeply C-oriented, so the platform utilities for exploring the C to ELF / PE transition are much more accessible. I would love to be able to have the same familiarity, predictability, and indegenous feeling with Rust that I have with C, but each time I attempt to interact with the ecosystem, I come away feeling alienated and like I've just interacted with a 'the compiler knows best' cult.
- _o_ 9y ago
  The only problem is that for some, rust is a silver bullet that is going to bridge lack of system dev. by learning another language. Sorry it does not work this way. C is just fine, we don't need rust, it can probably be implemented as another preprocessor layer of c. And quite frankly, I am failing to see, what benefits it provides if I throw c++ in equation.
  - ohazi 9y ago
    Rust is a systems language for people who prefer strongly typed languages. It has some relatively unique features that make learning and using the language a little quirky, but for many who end up liking it, C and C++ often no longer seem "just fine." Rust ends up being a genuine improvement for a lot of people. Also, unless you mean "write an essentially new language that happens to compile to C rather than machine code" -- you're delusional if you think you can recreate some of the nicer features of Rust as a new C preprocessor.
    - deleted 9y ago
      [deleted]
- buster 9y ago
  - "the instructions it does generate are far more predictable than the ones generated by Rust." I am wondering how that might work? Isn't this extremely depending on the compiler and flags? To be honest, i would assume that a modern compiler with many optimizations would generate a very different list of instructions then some simple compiler. C has a large list of available compilers.. - "I would love to be able to have the same familiarity, predictability, and indegenous feeling with Rust that I have with C," To be honest, all that seems to be mostly time and experience. Surely you won't get the same familiarity with Rust compared to C in a fraction of the time. It just sounds like you feel comfortable enough with C and see no reason to change, which is good for you in a way :)
  - ShroudedNight 9y ago
    The best I can come up with is examples: enum State { UNINITIALIZED, STARTING, RUNNING, SLEEPING, STOPPING, TERMINATED }; struct Thread { State state; int32_t threadID; MemoryMap * memoryMap; LockTable * lockTable; }; The memory layout of a Thread object is highly predictible: +0 state, +4 threadID, +8 memoryMap, +(12/16) lockTable I can predict the symbol name for a function: Thread * createThread(void *stackArea) I know that stackArea is going to be in RDI, and the resulting Thread* is going to be in EAX (or their well-specified equivalents on another platform) switch (thread->state) { case UNINITIALIZED: case STARTING: error("Not ready yet"); break; case STARTED: sleep(thread); break; case SLEEPING: error("Already asleep"); break; case STOPPING: case TERMINATED: error("Thread is terminating"); break; default: critical_error("The world is on fire"); break; } Given a compiled set of instructions, I can link the compiled instructions corresponding to the switch statement (like a jump table) back to the C code. for(size_t i = 0; i < SOME_MAXIMUM; ++i) { unsigned char const working_value = input1[i]; unsigned char const mask = ((unsigned char) -1) - (working_value >> 7); output[i] = input2[i] &= mask; } I've probably screwed that up, and I don't claim that it's doing anything useful here, but assuming it was doing something useful, I would be able to identify the instruction associated with it, figure out if there was some deficiency present (like say, a conditional) and have a decent idea of how to fix it. Rust, on the other hand, does a bunch of things that are (so far) opaque to me. One example is passing a borrowed slice of something, and somehow, not just a pointer to the thing itself is getting passed, but also seemingly, potentially one or more boundary indices, as well as a lifetime (maybe?) Another example is a match on the type of an object, clearly [on second thought, perhaps not] there's some run-time state being kept around along with the explicitly declared fields inside that object, what does that object look like in a memory dump? As final example: generics, how and when do they get expanded into discrete functions? What do the symbols get named? How do I know if a generic expanion is likely going to overly prolific? Inlining and templates can do wonderous things for performance, but they can also drown it. Anyway, hopefully that wasn't too overwhelming, or ranty. You asked nicely twice; I felt compelled to give you a real answer.
_o_ 9y ago
Just go and compile hello world with this: https://bellard.org/tcc/ https://bellard.org/tcc/ And then with rust. Open your favorite decompiler and decompile both. C has again and again shown that less is more and it is going to stay that way. (Btw, it is really sad that you get downvoted based on your opinion.) Rust has become some PR stunt here, it is new hipster topic, but it has a long way to reach proficiency that developer is able to pull out from c. But knowlidge of programming is not enough, power of c is due to knowlidge that developer has and no tool is going to solve that (or he, he... garbage collector - pointing finger to java direction ;) )
- jjnoakes 9y ago
  > it is really sad that you get downvoted based on your opinion That's not really what is happening. I'm guessing you are getting downvoted for a few specific things: * "If you want [...] small binaries, rust is just wrong" * "[Rust is not close to processor instructions]" * "I think go has beaten rust at anything relevant" * "Rust has become hacker news click bait" The general tone of your comment is a bit inflammatory, you make some claims with no reasoning, and you aren't contributing much to the discussion (even if some of these are just "opinions", not all opinions are relevant or useful in the context of any given discussion). I'm also a little surprised that you insult the folks who are reading this thread (folks probably interested in Rust, since it is a Rust thread) and then wonder why they aren't interested in seeing your comment.
  - _o_ 9y ago
    My opinion is right to the spot. The amount of posting for rust is inapropriate to the amount of posts every other language has while it seriously doesn't offer something revolutionary to developers. All fans are having c++ to be able to do same things or more, AFTER they have figured out their limits. c/c++ problem is not type safety but rather that it allows people doing anything. But this is also a huge bonus. (Btw, I don't care about downvoting, but it was somehow strange to see it)
    - jjnoakes 9y ago

steveklabnik 9y ago

The Rust team doesn't share this opinion, FWIW. We care about binary size and being able to do things like this to make your code as small as possible.

pjmlp 9y ago

Lots of languages are as close as C to processor instructions, unless you are thinking of targeting PDP-11 systems.

vardump 9y ago

> ...take c (or asm). The closest you go to processor instructions... Modern C isn't particularly close to processor instructions. 20-40 years old C is reasonably close to that benchmark -- or more like 20-40 years old C compilers.

littlestymaar 9y ago

Well, there are some people on the demo scene using Rust (and even winning[1]). I guess they disagree with you. [1]: https://www.pouet.net/prod.php?which=68375 https://www.pouet.net/prod.php?which=68375