5 ms·

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

by 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. :)
    - valarauca1 11y ago
      > There's only a few articles in my collection on asynchronous systems (outside I/O) because they're so hard to verify. GRR isn't hard just time consuming. Yes its not fully verified >I also figured you were forced to use aging crap that motivated you to try alternatives. I'm actually a polygot programmer trying to pay the bills. Working in aging tester frameworks pays a lot more then web development. I like Rust b/c its basically C-With-A-Type-System. Its still very easy to reason about how the Cee-LangVM will handle your code. But yes. Working in a code base from the 80's and switching to Rust is lovely. :.:.: The core purpose is exception logging. A lot of the exceptions will get mutated/modified before being reported. "Servo drive failed." is a lot less useful then "Servo communication fault 0x274077343" which I've memorized to tell me that a power surged knocked a comport off line.
      - nickpsecurity 11y ago
        Oh shit, replied to you at exact time you replied to me here: https://news.ycombinator.com/item?id=10954970 https://news.ycombinator.com/item?id=10954970 "GRR isn't hard just time consuming. Yes its not fully verified" I believe it now after pulling papers. I even know exactly how hard it is and what parts are decidable. " Working in aging tester frameworks pays a lot more then web development." Makes sense. It's why I advise against commodity jobs. The niche or unpopular stuff usually pays better. Not always, but usually. "The core purpose is exception logging. A lot of the exceptions will get mutated/modified before being reported. "Servo drive failed." is a lot less useful then "Servo communication fault 0x274077343" which I've memorized to tell me that a power surged knocked a comport off line." Hmm. That's more straight-forward than most async. Just detail-oriented work as you said. The taint idea of tracking exact sequence of mutations combined with design-by-contract tracks of function call contexts would certainly help that. How much I can't say as your combination of tech obscures it. Don't know enough Labview mainly. Microsoft has things like Spec# and verifiers for C# part with VB6 easy to ignore if you keep logic out of it. So, you're in better shape than many doing multi-language, legacy work. At least as far as verification concerns.
        valarauca1 11y ago
  - nickpsecurity 11y ago
    OK. So, thanks to your comment, I looked up a bunch of CompSci and stuff on asynchronous verification to see what old and cutting edge methods are. Looks like it's a mostly solved problem at the conceptual level. Even found a method from NASA for Globally-Asynchronous, Locally-Synchronous (GALS) which I keep stumbling into in hardware. So, good news, there's a number of techniques for various aspects of this at a range of mathematical abilities. Might be able to make an informal, knock-off of one or more for your use case. The bad news is that I found more papers than I wanted to thoroughly read. Not filtering them myself. If you want, I'll drop you a link to an archive or links to individual papers for you to skim at your own pace. If not, that's cool too as I needed them in my collection anyway for high-assurance, asynchronous systems. Especially given all the uptake on async in mainstream. So, it was great you replied with those details regardless. Might have inspired a future, bullet-proof system in an unusual instance of the Butterfly Effect. ;)
    - valarauca1 11y ago
      >Might have inspired a future, bullet-proof system in an unusual instance of the Butterfly Effect. ;) That'd be nice :D

by erickt 11y ago

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. :)
  - valarauca1 11y ago
    > There's only a few articles in my collection on asynchronous systems (outside I/O) because they're so hard to verify. GRR isn't hard just time consuming. Yes its not fully verified >I also figured you were forced to use aging crap that motivated you to try alternatives. I'm actually a polygot programmer trying to pay the bills. Working in aging tester frameworks pays a lot more then web development. I like Rust b/c its basically C-With-A-Type-System. Its still very easy to reason about how the Cee-LangVM will handle your code. But yes. Working in a code base from the 80's and switching to Rust is lovely. :.:.: The core purpose is exception logging. A lot of the exceptions will get mutated/modified before being reported. "Servo drive failed." is a lot less useful then "Servo communication fault 0x274077343" which I've memorized to tell me that a power surged knocked a comport off line.
    - nickpsecurity 11y ago
      Oh shit, replied to you at exact time you replied to me here: https://news.ycombinator.com/item?id=10954970 https://news.ycombinator.com/item?id=10954970 "GRR isn't hard just time consuming. Yes its not fully verified" I believe it now after pulling papers. I even know exactly how hard it is and what parts are decidable. " Working in aging tester frameworks pays a lot more then web development." Makes sense. It's why I advise against commodity jobs. The niche or unpopular stuff usually pays better. Not always, but usually. "The core purpose is exception logging. A lot of the exceptions will get mutated/modified before being reported. "Servo drive failed." is a lot less useful then "Servo communication fault 0x274077343" which I've memorized to tell me that a power surged knocked a comport off line." Hmm. That's more straight-forward than most async. Just detail-oriented work as you said. The taint idea of tracking exact sequence of mutations combined with design-by-contract tracks of function call contexts would certainly help that. How much I can't say as your combination of tech obscures it. Don't know enough Labview mainly. Microsoft has things like Spec# and verifiers for C# part with VB6 easy to ignore if you keep logic out of it. So, you're in better shape than many doing multi-language, legacy work. At least as far as verification concerns.
      - valarauca1 11y ago
- nickpsecurity 11y ago
  OK. So, thanks to your comment, I looked up a bunch of CompSci and stuff on asynchronous verification to see what old and cutting edge methods are. Looks like it's a mostly solved problem at the conceptual level. Even found a method from NASA for Globally-Asynchronous, Locally-Synchronous (GALS) which I keep stumbling into in hardware. So, good news, there's a number of techniques for various aspects of this at a range of mathematical abilities. Might be able to make an informal, knock-off of one or more for your use case. The bad news is that I found more papers than I wanted to thoroughly read. Not filtering them myself. If you want, I'll drop you a link to an archive or links to individual papers for you to skim at your own pace. If not, that's cool too as I needed them in my collection anyway for high-assurance, asynchronous systems. Especially given all the uptake on async in mainstream. So, it was great you replied with those details regardless. Might have inspired a future, bullet-proof system in an unusual instance of the Butterfly Effect. ;)
  - valarauca1 11y ago
    >Might have inspired a future, bullet-proof system in an unusual instance of the Butterfly Effect. ;) That'd be nice :D