We've been using PyO3 and Maturin at Spring for a while now, and happily. The smooth Python interop means we can call out to Rust without much pain for performance-critical codepaths. But the other side-effect is that we can use Rust across the org more broadly, even when Python interop isn't a consideration -- e.g., for isolated services, or applications that need to compile to Windows, or whatever else -- since we're building up the cultural knowledge and shared libraries to do so.
Thanks for the thoughtful feedback--I think these are very fair comments.
When we first designed Jasper, it was just for us to hack around with, so regex matching, the priority system, the single-instance configuration, etc.--these all made a lot of sense for our use case (and the use cases that we foresaw w/r/t casual hackers). Our goal was just to make things simple and accessible (hence our focus on documentation). Since our initial release, Jan Holthuis has taken over much of the development, and he's put a big emphasis on abstracting out the STT and TSS libraries (as you mentioned) and improving the design more generally. My hope is that Jasper will continue to grow and mature, and that the suggestions and possibilities you mention become realities.
That's entirely fair. I realise my use case wasn't the same as your intended goals so I was trying to not be too critical -- also half remembered ;)
You've done some really great stuff in terms of documentation and platform support and it's been designed perfectly for people to start hacking on, which I hope will bring in more interest and in turn bring in faster development.
I took the course this semester (and loved it--hope the materials can be helpful to all).
We had one assignment that focused on achieving consensus in the face of adversarial nodes, similar to the systems used in Stellar and Ripple, so those were included in the course, to a degree.
Can't speak highly enough of the Khan Academy internship experience--I interned with Kasra last summer and it was a pretty incredible few months. From the team to the mission to the culture to the work itself, it's A+ all around. If you're looking for a software internship, I highly recommend applying.
(By the way: the Khan Academy iPad app actually shipped _today_. Congrats to everyone back at Khan HQ!)
We've been pretty insistent on colocation for internships in particular, just because we think synchronous and serendipitous interactions are really important in these kind of apprenticeships.
But I'd love to be wrong and discover a way to achieve the same quality of results remotely and asynchronously.
True, but there's a decent case to be made that (1) transaction fees will have to increase (in general) as the block reward decreases, and (2) transaction fees will have to increase (for these centralized services) if they want to eat the cost of fraud [1].
I'm a little confused--the article mentions that letters of recommendation must be turned over, but I believe that's only the case if the writer explicitly waived confidentiality (see http://www.naceweb.org/public/ferpa0808.htm).
"I think the technology used to implement the Bitcoin payment system is fascinating - public ledgers and crypto and block chains will all be game changers. Bitcoins themselves? More of a necessary component to creating a new financial system."
Another article that seems to suggest that the blockchain has value with Bitcoin. I've heard others (pmarca in particular) promote this view, and I think it's far from validated. At the moment, BTC is the most important incentive to mine, and mining is the most important factor in establishing the blockchain's security.
It's true that, in the future, we might be able to come up with other incentive structures to encourage mining (the Bitmessage protocol is one such example). But if we want one blockchain, and we want it to be as secure as possible, how could we ever come up with an incentive that is as universally desirable and infinite as money?
There's a common view that Bitcoin's proof of work is the only way to maintain a secure blockchain. That view is the product of a herd mentality of people who have bought bitcoins and want them to increase in value, so anything that could prevent that must be wrong. This Bitcoin maximalism leads to false conclusions, and it should be avoided.
What I worry about is the effect that market price can have on the security of the network (via global hash rate).
The system will reach equilibrium when the revenue generated by mining is equal to the amount spent on mining. When the value of BTC goes down, mining generates proportionally less revenue (if miners are valuing BTC at market price, which they may not be), and the global hash rate will drop.
Imagine if the price plummeted, the hash rate dropped, and someone launched an attack on the network. At that point, consumer confidence in Bitcoin would possibly never recover, and its long-term viability would be severely damaged.
There is an incentive for miners to not have confidence in bitcoin damaged. It's a bit of an interesting Nash equilibrium kind of game.
In general, I think these things will balance out assuming rational actors.
Yes there could be a crisis of confidence but I can't see it spinning out to completely cancel out its utility e.g. usefulness in international remittances. At the very least it will replace or significantly threaten the Western Union business model.
Where I think there may be cause for concern might be the irrational actors. People or organizations prepared to invest and lose money with the aim of bringing bitcoin down.
It gets a bit tinfoil hat to suggest that e.g. the Federal Reserve or world governments would want to spend billions on killing bitcoin, but it's at least an interesting thought experiment. I'd love to hear a defence from a strong bitcoin proponent against the 'irrational' actors. Irrational meaning not obviously acting in the interests of their own holdings. I've raise it before but not heard convincing arguments of how bitcoin would be safe against 51% attacks like that.
This is awesome. I've played around with React's server-side rendering [1] and was really impressed once I'd hooked it all up. To see React hook up the event handlers and render nothing at all was really satisfying.
I haven't had a chance to use react-router, but it's great to hear that they've put in the work to make server-side rendering a reality. I only hear positive things. Kudos.
