jamwt

14 ms·

121.
Rust: A modern programming environment(alexgaynor.net)
7 points by jamwt 11y ago|0 comments
122.
by jamwt 11y ago
Referral trees let you control abuse; if someone suddenly spawns lots of accounts via nested referrals for abuse, you can just cleave off the appropriate subtree.
123.
by jamwt 11y ago
Depends on what you mean by safety. "People may die" safety, no; but "data may be lost, existential risk to business" safety, yes. Dropbox is writing a block storage engine in it.
124.
by jamwt 11y ago
Yes, the first few weeks of Rust, I wanted to strangle the borrow checker. Now, it seldom gets into the way b/c it's a seamless part of my thinking when I'm writing Rust. I rarely hear from it because I wrote/structure
125.
by jamwt 11y ago
I spent.. a lot.. of my life in dustbowl. I still know dustbowl better than actual houses I've lived in.
126.
by jamwt 11y ago
We're using eventual (and syncbox and mio) at Dropbox in our rust stack. All of Carl's stuff is awesome.
127.
by jamwt 12y ago
Uhh... no, no we are not. s/probably //
128.
by jamwt 12y ago
We still have tons of Python code, and likely always will. Therefore, Pyston is still really interesting to us. Only specific, common, core services (storage etc.), are being written in golang; the "long tail" of application code
129.
by jamwt 12y ago
Dropbox uses Phabricator extensively for all our projects. Integrations into CI and deployment systems, etc. Great project. I've used trac, redmine, bugzilla, github/github enterprise, over the last ~10 years, and taken across
130.
by jamwt 12y ago
> The sync heavy lifting in Dropbox is handled by librsync, or at least was at one point. Nope, highly custom process that involves librsync very little. The sophistication of what has to be done to solve this problem well would probabl
131.
by jamwt 12y ago
That and the fact that they will inevitably lose their data when they mishandle or misplace their keys. In the rare case that they are the sophisticated type of user who will most likely (and even that likelihood could be debated) safely h
132.
by jamwt 12y ago
Oooh yes they do. GP and I both happen to work for one. :-)
133.
by jamwt 12y ago
Dowski still works with it routinely at GOOG. I'm knee deep in golang at Dropbox myself these days, so I don't get around to working with diesel much.
134.
by jamwt 12y ago
That would have helped a lot, yeah. Also, dealing with exceptions in an intuitive way when you have a "fake" stack you're managing yourself is a drag. The performance of of managing your own stack also sucks. But probably t
135.
by jamwt 12y ago
file, err := os.Open("file1") // complains if you don't check err file2, err := os.Open("file2") // no problem, no need to check err.
136.
by jamwt 13y ago
Not if you want to parameterize the exceptions. This kind of "matching" requires that you compare your exception "types" by exception "values", so you cannot provide parameterized information about what exactly
137.
by jamwt 13y ago
Quite a few apps change their behavior post-review, quite a few. :-)
138.
by jamwt 13y ago
They are different, but Dropbox does have some "P2P" behavior with LAN sync: https://www.dropbox.com/help/137/en Note: Dropbox employee, but this is public information.
139.
by jamwt 13y ago
This is not quite correct. libev is a wrapper around the best available of select/epoll/kqueue (the same syscalls libuv uses), and it provides nice timers, thread wake (eventfd/pipe), etc. What it doesn't provide that l
140.
by jamwt 13y ago
I said in my comment: > So, maybe this project is betting on our lives transforming into everyone paying more for their hardware, and everyone using a lot more small/local/boutique type stuff created by small hardware teams. Th
141.
by jamwt 13y ago
> ultimately there is always a market below that point - people are selling arduinos now for surveillance or monitoring simply because the market is too small for anyone skilled enough in C to bother. I agree, and this could be interesti
142.
by jamwt 13y ago
And yet our operating systems are still written in C(++). Javascript web code epitomizes the "long tail" of random ideas being articulated. The code is written quickly, needs to change a lot in response to user behavior and desig
143.
by jamwt 13y ago
Can't elaborate, but there's quite a bit more to it than that. The rabbit hole is pretty deep.
144.
by jamwt 13y ago
A bit pedantic, but I think you mean "pneumatic lifts". Unless you have something very exotic, there's no fluid in your chair!
145.
by jamwt 13y ago
Yes, I really feel like aspen is exactly this, and very well done too. Already has real-world things running on it, like http://gittip.com .
146.
by jamwt 13y ago
The runtime is somewhat immature. It locks up oddly sometimes under heavy load. Dealing with latency and queuing issues around gc pauses is much less understood/documented than in the JVM world. The set of best practices in genera
147.
by jamwt 13y ago
Most of these questions can be solved by a little "cookbook" that maps these use cases onto pieces of NaCl (and maybe scrypt). I understand we could then argue over the cookbook (though I don't know in practice how much we
148.
by jamwt 13y ago
Let's just all use ( http://nacl.cr.yp.to/ ) and stop arguing.
149.
by jamwt 13y ago
I'm late to the party on this, but unless I'm misreading things... the author used Riak the wrong way and it failed, and then he used it the right way, and it succeeded. Granted, as the author says, Basho tries to delay the necessity of "br
150.
by jamwt 13y ago
I recommend dreadlock: https://github.com/jamwt/dreadlock It will release the lock when the client dies (disclaimer: I wrote it). Or you can go whole hog and use zookeeper + ephemeral nodes. More robust but quite a bit more complex.

More ›