If you follow the best practices for using Cargo you don't have a Cargo.lock file for libraries.
This means your library tests will not be deterministic.
Using the Cargo.lock file for libraries does solve this, but then every binary package you build that references your library will have to be specifically tied to the versions in the library.
We do this internally because it's the only way to provide deterministic builds over time.
Over time I suspect it will get harder and harder to keep this rigid web of dependencies working.
One thing we might try is to enforce the rule 'no library will contain any tests'. At first glance this kinda makes my skin crawl, but maybe if we could find a way where every project that used a library could somehow share the tests for that library it could actually work.
git submodules might actually be able to provide these tests for each binary package. If only git submodules would stop corrupting our git repos... :-(
What we do currently is we lock everything to an explicit version - even libraries.
At least it's possible to get deterministic builds if you are willing to do a bit of work carefully / manually updating all of your dependencies at once.
The first day in radar class the instructor put a piece of steel wool in front of a small dish and it instantly melted white and dropped molten metal onto the floor.
It always made me nervous when the class goofballs turned the horns on other people so you could feel the microwaves.
Goofball 1: 'accidentally' radiates goofball 2
Goofball 2: What? What are you doing? Oh, I'll show you - just watch me increase the power on this baby...
It turns out your testicles and eyes are a bad place to receive microwaves.
I submit to anyone thinking of attempting this: you are probably going to get the power calculations wrong and cooking human cells is not fun at all.
2 people bet each other a dollar they could take a fundamentally simple concept and wax poetic insanity around it until the text was so insane no one could actually read through it - so people just shrug, wash the virtual slime off and move on. Their will power so drained by reading the BS they can't even be bothered to complain.
Then comes the fake accounts to gush how 'serverless' and 'function-as-a-service' are completely new and different and awesomer bra.
The next bet will probably be "mathematicsless": how we solve collision detection without math - and you should too!
As part of a recent project I had to:
- build an AST from a large and complicated DSL
- transform the AST into something that could be compiled into a DSO.
I chose to write both parts in Rust. Fwiw the semantics of the language really didn't match Rust at all (though, I suspect you weren't thinking of DSLs when you wrote your paragraph).
In the end I had all the benefits of _safe_ Rust when compiling the transformed code into the DSO.
This DSO is a critical component and can not fail. I can't imagine transforming the AST into C or LLVM - I wouldn't be able to sleep at night. I'm only human; I know I'd fall into a number of traps that humans fall into when coding in C - especially when I am _generating_ C from an AST...
Where I work client auth is used for a good (and growing) number of internal services.
Client auth is simple to use - our internal services are given the username from the CN, which they use to perform authorization checks. For a lot of simple internal services that don't require two-factor auth it works great.
Am I missing something better?
(We already have the infrastructure in place to deal with client keys)
I'm just now completing a rather large event-driven system in Rust. It's also callback-based and has to interoperate with C.
I do struggle with the ownership rules sometimes but it's pretty much always because I'm clashing with the bad habits I learned coding in C/C++, or I'm shooting my future-self in the foot because my limited cognitive capabilities can't always keep all code paths in memory perfectly all the time.
The borrow checker came with an upfront cognitive cost that ultimately saved me from multithreaded async I/O madness later on. I can sleep at night knowing my multithreaded async system is more sound and easier to safely extend/maintain than it would have been had I created it in C/C++.
I can see why some people might give up on Rust. In C++ you can take the easy way out (use mutable aliasing etc.) and you can quickly get things 'working'. You don't have it so easy in Rust because you have to carefully think about end-end ownership.
Also in Rust I found that when I did make bad design decisions it was sometimes a lot more work (redesigning structs, shifting ownership responsibility) than it would have been in C/C++ (because I probably would have laid land-mines for my future self by mutably aliasing things etc.).
Memory is terribly expensive and I have to fight all of the other developers/product folks/upper management for every byte in my environment (hundreds of thousands of servers).
I have no choice but to use DSOs for our Rust code.
I've always felt that if I had done all of my calculus with Mathematica I would have left college with an excellent grasp on how to use higher level functions provided by Mathematica that would have largely abstracted away all of this.
Of course, the higher level functions might get covered in cobwebs - but I suspect not the same way; I would have kept these higher level skills up to date because:
- I recently went though a couple of books on Bayes and computer vision. I would have used Mathematica - refreshing my memory.
- I sometimes need to do some stats / analysis - Refresh...
- I recently picked up a Student's guide to Maxwell's equations - Refresh...
- I need to help my children with Calculus...
If I had been using a high level tool my whole life I think I actually would make use of calculus and other mathematics.
I randomly lie about my gender, age, and anything that could be used to identify me. I learned this from others, and have also encourage my spouse/children/etc. to do the same (which they seem to do).
There is no compelling reason for me to provide any real information about myself online.
This means your library tests will not be deterministic.
Using the Cargo.lock file for libraries does solve this, but then every binary package you build that references your library will have to be specifically tied to the versions in the library.
We do this internally because it's the only way to provide deterministic builds over time.
Over time I suspect it will get harder and harder to keep this rigid web of dependencies working.
One thing we might try is to enforce the rule 'no library will contain any tests'. At first glance this kinda makes my skin crawl, but maybe if we could find a way where every project that used a library could somehow share the tests for that library it could actually work.
git submodules might actually be able to provide these tests for each binary package. If only git submodules would stop corrupting our git repos... :-(