6 ms·

Actually managed to sneak some Rust into production. Nobody cares what language you wrote the DLL in, just that it does what the docs say it should do.

eterm 11y ago
Said no one who has to maintain others' software.
- humanrebar 11y ago
  It's a fair point, but there's a lot of write-only Perl, PHP, and C out there. Let's make sure we don't hold new Rust code to a higher standard that that stuff.
  - zenlikethat 11y ago
    Ideally we should hold all new code to a higher standard than that. All programmers spend much more time reading code than writing it. Likewise, Rust is not finalized as a language yet. That means whoever has to maintain the original commenter's code is likely to be in for a rough time if and when they ever attempt to bump the Rust version.
    - steveklabnik 11y ago
      > Rust is not finalized as a language yet. It is just as finalized as any other language. > if and when they ever attempt to bump the Rust version. If the parent is using a stable release, like this 1.6 is, then bumping the version should be all they need to do. (Unless they're relying on a safety hole for some reason; we do fix those)
      - zenlikethat 11y ago
        Fair enough- I wasn't familiar with Rust's backwards compatibility guarantees and had heard a bit about breakage, so thanks for pointing that out.
        steveklabnik 11y ago
        No worries. Every 1.x+1 is backwards compatible with 1.x, modulo some details. Usually breakage is mentioned in the context of the nightly ecosystem, which has no particular guarantee. We also reserve the right to fix soundness bugs, though we try to make upgrading easy in those situations of and when they occur (we've only had one or two so far).
        Manishearth 11y ago
        Rust development was done in public (unlike Go or Swift which started out privately), so we had a very long 0.x period which was public and had tons of breakages where the language designers tinkered with just about every tradeoff. So it's easy to see where you get the impression that Rust is prone to breakages, but that doesn't happen anymore.
      - dasfasf 11y ago
        Rust is not as finalized as any of the languages whose semantics are completely defined by a standard document. There is no definitive answer to the question of what a great many pieces of Rust do beyond checking out rustc from the commit date and examining the LLVM IR.
        steveklabnik 11y ago
        There are a very small number of languages which have those things. They are useful and we want them, but I think it's _generally_ an unreasonable standard overall.
        dasfasf 11y ago
        Not if you weight by use. C, C++, Java, Javascript, and C# all have specs. Among the most popular languages, it's really only the scripting languages that have the "as our implementation does" perspective on specification. I've always used languages that have standard documents, and communities that think those standard document are very important, so rather than being unreasonable, I think of complete language documentation as the natural state of the world. Incidentally, this isn't really a criticism, but it's precisely because I don't see Rust as finalized that it isn't. A language that's finalized but not specified is just poorly documented.
        steveklabnik 11y ago
        Yes. Those are all old, established languages. And while they do have a _lot_ of use, there are also a significant number of languages which see heavy amount of use that have no spec. And as you mention, it's not exactly a criticism; it depends on where you fall on the maturity scale of languages you wish to use. It's only unreasonable due to Rust's young age. At Rust's age, none of those languages had a specification either.
        kibwen 11y ago
        In fact, C didn't have a specification for the first 17 years of its existence. :)
  - awwaiid 11y ago
    Don't forget Python and R and C++ and JS and ... hmm. Almost like the language doesn't have much to do with it so much as the writer. But I digress!
- deleted 11y ago
  [deleted]
- jeffdavis 11y ago
  He said it's documented. That tells me it's probably easier to maintain than many other approaches.
  - valarauca1 11y ago
    There is also a test suite b/c cargo makes it stupidly easy to write tests. I actually find myself pining for the simplicity of #[test] in other languages. It makes the Write->Test->Write loop so much faster.
blantonl 11y ago
This is where grey-bearded consultants make their bank....
erickt 11y ago
Wonderful! Are you able to say which company you deployed this in, and if you've run into any trouble? And by DLL, was this in Windows? I can't recall if we've heard of any Windows users putting rust into production yet. We're quite interested in making sure our production users don't run into any problems. If you'd prefer to not speak in public, you could reach out to our private channel, community-team@rust-lang.org. Best of luck!
- deleted 11y ago
  [deleted]
- nickpsecurity 11y ago
  "Are you able to say which company you deployed this in?" "Actually managed to sneak some Rust into production." "...sneak some Rust..." "...sneak..." There's your answer on that one. ;) Others might be quite useful, though.
  - valarauca1 11y ago
    Truth is its a developer tool that just provides basic logging for debugging. Its not sexy, and its not actually shipping out of the shop. Just a few members of my dev team have adopted it. And it was written on company time, so the company technically owns it. I Work in an aging framework for electronics testers written in a combination of C#/VB/LabVIEW its highly asychronous nature make debugging the system an issue.
    - nickpsecurity 11y ago
      "And it was written on company time, so the company technically owns it." I figured this and you possibly breaking the rules were the reasons for discretion. I also figured you were forced to use aging crap that motivated you to try alternatives. A painful, but common, thing in industry. Hence, me reminding the other commenter not to expect a source reference on it. ;) "I Work in an aging framework for electronics testers written in a combination of C#/VB/LabVIEW its highly asychronous nature make debugging the system an issue." I usually try to drop papers or articles at moments like these but have nothing relevant. There's only a few articles in my collection on asynchronous systems (outside I/O) because they're so hard to verify. I did find a few resources. Would have to know if the problem is communications, data, what before I could attempt suitable references for you. You probably already do one of my base recommendations here: tracing flows and input validation on them. The equivalent of asserts on input and/or monitors with read access to global state comparing data/states against ranges or rules in a policy. Taint-methods are also helpful where you tag data in the datatype with details about where it's been and whats happened. That's more advanced and I'm not sure there's libraries available for those platforms. The other technique they can easily handle: I did it in VB long ago. "Screw diamonds: legacy systems are forever." That's friggin' great. Need to make a meme image out of that with some COBOL or RPG on it. :)

eterm 11y ago

Said no one who has to maintain others' software.

humanrebar 11y ago
It's a fair point, but there's a lot of write-only Perl, PHP, and C out there. Let's make sure we don't hold new Rust code to a higher standard that that stuff.
- zenlikethat 11y ago
  Ideally we should hold all new code to a higher standard than that. All programmers spend much more time reading code than writing it. Likewise, Rust is not finalized as a language yet. That means whoever has to maintain the original commenter's code is likely to be in for a rough time if and when they ever attempt to bump the Rust version.
  - steveklabnik 11y ago
    > Rust is not finalized as a language yet. It is just as finalized as any other language. > if and when they ever attempt to bump the Rust version. If the parent is using a stable release, like this 1.6 is, then bumping the version should be all they need to do. (Unless they're relying on a safety hole for some reason; we do fix those)
    - zenlikethat 11y ago
      Fair enough- I wasn't familiar with Rust's backwards compatibility guarantees and had heard a bit about breakage, so thanks for pointing that out.
      - steveklabnik 11y ago
        No worries. Every 1.x+1 is backwards compatible with 1.x, modulo some details. Usually breakage is mentioned in the context of the nightly ecosystem, which has no particular guarantee. We also reserve the right to fix soundness bugs, though we try to make upgrading easy in those situations of and when they occur (we've only had one or two so far).
      - Manishearth 11y ago
        Rust development was done in public (unlike Go or Swift which started out privately), so we had a very long 0.x period which was public and had tons of breakages where the language designers tinkered with just about every tradeoff. So it's easy to see where you get the impression that Rust is prone to breakages, but that doesn't happen anymore.
    - dasfasf 11y ago
      Rust is not as finalized as any of the languages whose semantics are completely defined by a standard document. There is no definitive answer to the question of what a great many pieces of Rust do beyond checking out rustc from the commit date and examining the LLVM IR.
      - steveklabnik 11y ago
        There are a very small number of languages which have those things. They are useful and we want them, but I think it's _generally_ an unreasonable standard overall.
        dasfasf 11y ago
        Not if you weight by use. C, C++, Java, Javascript, and C# all have specs. Among the most popular languages, it's really only the scripting languages that have the "as our implementation does" perspective on specification. I've always used languages that have standard documents, and communities that think those standard document are very important, so rather than being unreasonable, I think of complete language documentation as the natural state of the world. Incidentally, this isn't really a criticism, but it's precisely because I don't see Rust as finalized that it isn't. A language that's finalized but not specified is just poorly documented.
        steveklabnik 11y ago
        Yes. Those are all old, established languages. And while they do have a _lot_ of use, there are also a significant number of languages which see heavy amount of use that have no spec. And as you mention, it's not exactly a criticism; it depends on where you fall on the maturity scale of languages you wish to use. It's only unreasonable due to Rust's young age. At Rust's age, none of those languages had a specification either.
        kibwen 11y ago
        In fact, C didn't have a specification for the first 17 years of its existence. :)
- awwaiid 11y ago
  Don't forget Python and R and C++ and JS and ... hmm. Almost like the language doesn't have much to do with it so much as the writer. But I digress!
deleted 11y ago
[deleted]
jeffdavis 11y ago
He said it's documented. That tells me it's probably easier to maintain than many other approaches.
- valarauca1 11y ago
  There is also a test suite b/c cargo makes it stupidly easy to write tests. I actually find myself pining for the simplicity of #[test] in other languages. It makes the Write->Test->Write loop so much faster.

blantonl 11y ago

This is where grey-bearded consultants make their bank....

erickt 11y ago

Wonderful! Are you able to say which company you deployed this in, and if you've run into any trouble? And by DLL, was this in Windows? I can't recall if we've heard of any Windows users putting rust into production yet. We're quite interested in making sure our production users don't run into any problems. If you'd prefer to not speak in public, you could reach out to our private channel, community-team@rust-lang.org. Best of luck!

deleted 11y ago
[deleted]
nickpsecurity 11y ago
"Are you able to say which company you deployed this in?" "Actually managed to sneak some Rust into production." "...sneak some Rust..." "...sneak..." There's your answer on that one. ;) Others might be quite useful, though.
- valarauca1 11y ago
  Truth is its a developer tool that just provides basic logging for debugging. Its not sexy, and its not actually shipping out of the shop. Just a few members of my dev team have adopted it. And it was written on company time, so the company technically owns it. I Work in an aging framework for electronics testers written in a combination of C#/VB/LabVIEW its highly asychronous nature make debugging the system an issue.
  - nickpsecurity 11y ago
    "And it was written on company time, so the company technically owns it." I figured this and you possibly breaking the rules were the reasons for discretion. I also figured you were forced to use aging crap that motivated you to try alternatives. A painful, but common, thing in industry. Hence, me reminding the other commenter not to expect a source reference on it. ;) "I Work in an aging framework for electronics testers written in a combination of C#/VB/LabVIEW its highly asychronous nature make debugging the system an issue." I usually try to drop papers or articles at moments like these but have nothing relevant. There's only a few articles in my collection on asynchronous systems (outside I/O) because they're so hard to verify. I did find a few resources. Would have to know if the problem is communications, data, what before I could attempt suitable references for you. You probably already do one of my base recommendations here: tracing flows and input validation on them. The equivalent of asserts on input and/or monitors with read access to global state comparing data/states against ranges or rules in a policy. Taint-methods are also helpful where you tag data in the datatype with details about where it's been and whats happened. That's more advanced and I'm not sure there's libraries available for those platforms. The other technique they can easily handle: I did it in VB long ago. "Screw diamonds: legacy systems are forever." That's friggin' great. Need to make a meme image out of that with some COBOL or RPG on it. :)