You can buy a lot if the price is zero.
3,858 karma · joined March 31, 2009
We will also run a training course next month just based on the Rust book plus some workshop examples.
If anything my experience is that it's quite productive to work in Rust. For example, compared to Python (which you mention) we catch bugs earlier (with the compiler) rather than later (system test) and so development is faster. Shift left.
It's particularly important for races because they are some of the most difficult bugs to find and fix.
Does Go offer similar guarantees for concurrency?
We've actually bootstrapped relatively easily. We have a some developers who have picked it up quite easily, perhaps with some pairing. We run an hour session every week where all the Rust developers get together to share production code and present on Rust topics. The discussion focusing on Rust production code has been particularly helpful.
We evaluated several frameworks and liked the model that Actix has and also its relative maturity (for example documentation / examples). It has been pretty straightforward to work with - including doing things like custom authentication and REST endpoints that dynamically exist.
For the drama, I guess you are talking about the situation that used to exist where Actix had hundreds of unsafe blocks. That's pretty much resolved now, with perhaps a handful of performance critical unsafe blocks left.
Developers who could get by professionally in Python, but were not particularly good, have struggled with Rust.
However, we have several developers who joined us directly from their undergraduate degrees who have picked up Rust extremely easily.
Of course, you can write hard to read code. But that's not typically what comes out of a process of writing production software.
That's not to say that someone with no experience will fully understand the ownership transfer & borrowing that's happening, but that's just stuff you need to do for the compiler. Reading code that already compiles, you can mostly ignore that and focus on the program logic.
For us, the safety is the critical reason to choose Rust - particularly the thread-safety. Also the relatively small memory footprint compared to something like Java. Performance hasn't driven our decision at all - the number of requests per second is very low. It's correctness that matters.
We are a bit unusual because customers have locally deployed servers rather than servers managed by us, so bugs are harder to fix.
We haven't hired any developers specifically for their Rust experience, but have instead trained internally and now have a group of about 10 Rust developers working across a couple of projects. I would say that training like this has been relatively straightforward. One of our hires, a recent graduate, had some existing Rust experience with personal projects, and this was particularly beneficial in helping the team to bootstrap.
The ecosystem is surprisingly mature. Async is probably still shaking out somewhat, but that's moved on hugely in the last couple of years, and we haven't had any particular problems.
Overall the experience has been hugely positive.
The biggest barrier to adoption, in my opinion, is that people are scared of learning Rust because it has a reputation as being difficult. I don't think it's any harder to master than some other major languages such as C++ or Java - although perhaps you have to understand more at the beginning: ownership and borrowing are right in your face.
But this is partly the reason why libraries might be more inclined to support async rather than blocking calls.
Sure, you can stop polling the future at any time, but that doesn't mean that you left the system state consistent.
Careful thought is needed on every call to await in an async function. It might be the last thing that async function ever does.
That's probably something that should be true in a well-implemented system anyway. After all, processes could be killed at any point.
So just use the async functions from the library synchronously if you want.
You could have two executors with no problem.
What might cause issues is if code running on one executor needed close interaction with the other - such as running a task on the other executor.
Most of the time this is just avoided by using only one executor. But that's not the only way.
Enforcing a contract is often not worthwhile.
Some sort of principal component analysis to determine your "cohort".
An advertiser isn't that interested that you are you. They care that you are, for example, 55 with an interest in gardening and have been looking at lawnmower review sites.
There was essentially no security on those Econet networks. If you had a copy of the executable that could read and write the memory of a remote computer, you were good to go.
I remember I had a print-out of a hex dump of the REMOTE command and used it with exactly that key capture attack. I just typed in the executable then told the teacher I'd forgotten my password and needed it reset. I watched remotely as he logged on to his admin account.
The next day, all the BBC micros in the lab played Captain Pugwash when they started: very beep-heavy given the ability of a BBC to create sound.
Eventually I was caught re-entering the hex dump and my printout was confiscated. I didn't have another copy.
To be truly Turing complete requires infinite memory. That clearly doesn't hold for any current programming language.
Mathematical proofs are only applicable where their assumptions are valid. So why would we believe that the where memory isn't infinite (everywhere in practice) that Turing's halting analysis is applicable?
Sure, automated program analysis might not be easy, but that doesn't mean we should just give up. Indeed I have a simple algorithm (although relatively inefficient) to solve the halting problem where memory size is fixed and finite: enumerate every state until either a state is repeated or the program halts. This completes in O(2^N) time where N is the size of the memory.
But I'm sure someone clever will come up with a more efficient algorithm than that. I already have several ideas that this margin is too small to contain.
For me the tricky bits are where a loop terminates if and only if Goldbach's conjecture is true (or similar) - but perhaps a compiler could require an "unsafe" block for such code (in the vein of Rust).
If you bid the most you would be prepared to pay for something - you don't pay that price - you just pay enough to beat everyone else.
If you bid in a genuine way there's no pipped at the post situation - you just weren't prepared to pay more.
Now there are some secondary psychological effects, like a high price bid so far might increase bidders willingness to pay more, so there may be some advantage to bidding later, but overall there's less of a problem than it initially appears.
Perhaps bidders just need to be more honest with themselves about how much they were really prepared to pay.
There's a trivial implementation of a halting oracle when memory is a fixed size - run until a state is revisited or the program exits.