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.
"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.
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 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. :)
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.
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.
Don't learn it. Its a terrible language, and a worse IDE. Yeah you'll learn over 6 figures with 2 years experience. But you'll waste a lot of time debugging issues with the runtime itself, also the langauge itself isn't consistent which can lead to extreme headaches/development lagging. But NI will compensate lost development time with free hardware so companies love it.
The tools for tracing/testing in Labview are annoying and kinda primitive. Hence why a separate callable logger is useful. Mainly in Labview all functions start out as heap allocated monands wrapped in a mutex. So basically every function has state initially. You then have to opt-out of this to get a pure function.
>Hmm. That's more straight-forward than most async
Well yes. We're not exactly concerned with verification of the asynchronous system. Just making sure everything happens in the right order, and each thread is actually doing what its commended to do.
At a certain level you can abuse asynchronous systems to make certain measurements easier. Just assume your input has a half-Gaussian input lag level, and suddenly a 200 sample moving average becomes sufficient for smoothing data not jumping though hoops of fire doing weird data synchronization.
WOW! I never even thought about that business angle to dealing with shoddy tech. Thanks for the warnings.
"Well yes. We're not exactly concerned with verification of the asynchronous system. Just making sure everything happens in the right order, and each thread is actually doing what its commended to do."
Glad you at least have an easy approach to dealing with that nonsense. :)
Well most companies don't supply hardware and software. Also NI's hardware is great, best in the business. Their software is complete poop.
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. ;)
That'd be nice :D
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.
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)
So it's easy to see where you get the impression that Rust is prone to breakages, but that doesn't happen anymore.
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.
It's only unreasonable due to Rust's young age. At Rust's age, none of those languages had a specification either.
This fact is the major reason behind the whole undefined behavior story in C and its derived languages.
When the standard came to be, no vendor wanted to give up on the semantics that gave their compiler some kind of advantage.
So all those little issues were tucked into undefined bucket.
So, I'm not seeing your examples as relevant or a critique. Most were in use and changing [to their benefit] before any spec was created. Three of those very publicly, one privately. Another sucked partly thanks to formalizations with lots of money driving adoption. I think you should read Gabriel's Worse is Better essays... several rather than just the first... to see why pushing a partly done or evolving system is right approach for growth & accelerated improvements. Lipner at Microsoft, inventor of successful Security Development Lifecycle, incidentally thought the same thing.
Least Rust team is trying to fix problems and evolve in a robust way. That's quite rare for mainstream stuff that I've seen.
I might have been too hasty there. Your context and this quote makes much more sense. I say something similar to them myself. Yet, they've already entered a 1.0 mode where they're not breaking stuff with much of it documented in guides. That's not formal but pretty final on language itself. Standard libraries and other tooling are where most of their work is right now.
So, I don't feel it's an accurate statement but it's close if we're talking the language. I prefer to say the core language is pretty stable or something like that.
The reason why Rust was stabilized in advance of a standard is that stabilization had an immediate practical consequence: ceasing to break code. A standard, by contrast, would have virtually no practical use.
I actually find myself pining for the simplicity of #[test] in other languages. It makes the Write->Test->Write loop so much faster.