stuhood

I think that that makes it fairly similar to Rust's approach then... compiler support for suspension, and cooperative scheduling.

The thing that makes it safe to use mutation in the context of a transient is that you can know with certainty that you have exclusive access to the value (because no other viewer has observed it yet). This is also what borrow checking can guarantee: except in significantly more positions in the code, and at compile time rather than runtime.

Borrow checking allows even structures that support mutation to be safely (checked by the compiler) treated as immutable, and thus as values.

Clojure also recognizes the connection between ownership and mutability in its "transients": https://clojure.org/reference/transients ... compile time borrow checking extends that idea to an entire language.

> When immutable values (whether it's the number 5 or a record, or whatever) are used with a pure function then the returned value can be essentially a direct replacement for the function invocation, making the operation essentially take zero time (i.e. there aren't intermediate mutation states, locks, or any other coordination).

The same can be said of any variable in Rust that is passed to a function via immutable reference. Borrow checking guarantees (at compile time, with no runtime overhead) that even if a user passes something that supports mutation (such as a BTree or an array) to a function, that that function may not mutate unless it has permission to.

This means that if you have an immutable reference to something, it can be treated as a value. For example: a Vec or BTreeMap (structures that supports mutation) can safely and easily be used as Map keys in Rust, because borrow checking guarantees that once the Map has taken ownership of the structure, it "is a value": ie, is immutable.

Immutability is very helpful, and the connection between values and identity is illuminating.

But there have been very important developments in programming languages since this post/page was written: notably, the introduction of "borrow checking" (exemplified by Rust's implementation). Borrow checking has a very significant positive effect on the sustainability of imperative code, which makes the claim that "imperative programming is founded on an unsustainable premise" feel dated.

It is worth taking the time to understand what borrow checking enables. For example: borrow checking allows even mutable datastructures to be treated as values with structural equality. It does this by guaranteeing that unless you have exclusive access to something, it may not be mutated.

A good explanation of the benefits of ownership and borrow checking: http://squidarth.com/rc/rust/2018/05/31/rust-borrowing-and-o...

This is a really interesting thought. In the presence of must-use types, you'd imagine that types with side effecting Drop impls (like files), would want to migrate to eventually being used/consumed by a "close" method. But doing that safely in the presence of panics would require... exception handlers?...

Twitter is not moving away from Scala. And the internal adoption of Java 8 has not had an appreciable impact on the growth of the Scala codebase.

Nice. Could imagine this as a realtime renderer for http://zipkin.io/

Twitter is not moving away from Scala. Scala continues to grow at a faster rate internally then any other language, and is ~50% of Twitter's backend codebase.

There is little-to-no actor composition in this post, except that which is hidden by the framework that they've implementated... instead, it describes using the methods of an interface to communicate between your implementation, and their framework.

Composition of actors would allow for "wrapping" the actions of one actor in another and an implementation of RPC within your service itself (separate actors for both requests and responses), but that's not generally a thing you would do directly. Why? Because it's nontrivial, and you'd likely want a framework like theirs to orchestrate it.

When you look at how the composibility of Futures/Promises make both sideffecting and transformation tasks like monitoring completely trivial, it becomes really hard to accept the actor model as a reasonable choice.

Ah, sorry. Even the article I linked is potentially stale. Things seem to be moving quickly. The "near majority" statement was based on unconfirmed reports that another large pool has hopped onboard: https://twitter.com/mkomaransky/status/636534235508178945

This article is already stale: a near majority of the network has voted for BIP100 in the last few days.

http://bitcoinist.net/block-size-debate-takes-turn-f2pool-re...

In scala, the body of a match expression is a PartialFunction, and PartialFunctions compose similarly.

com.twitter.util.Future supports raising interrupts that propagate 'backwards' through the chain (and across network boundaries.) This is used to implement cancellation, among other things.

https://github.com/twitter/util/blob/master/util-core/src/ma...

Twitter has not used a fork of the scala compiler/library since the pre-2.8 days (and maybe not even then, since we have always had a fair fraction of open source code.)

Would recommend "The Diamond Age" by Neil Stephenson, with the highly relevant subtitle: "or, The Young Woman's Illustrated Primer".

To get a log for a specific subdirectory, you just:

  git log -- my-teams-subdirectory

That only applies to deployment. You're not building these services from the ground up: they're all going to have common libraries that need to stay up to date.

I've done SF -> LA and SF -> Vegas without any issues.

The supercharger in Folsom enables Tahoe, and was one of the first to go in. But because of the cold and the elevation change, you have to stay there for more than 2 nights to make that one practical (or stay at the Ritz, which still seems to be the only hotel with >110v charging.)

Hm, it looks like that must have been an older number. More recent estimates are in the $100k-$200k range: http://techcrunch.com/2013/07/26/inside-teslas-supercharger-...

And they say that hardware startups are hard. Hardware startups that require hundreds of custom, million dollar station installs, AND cooperation from a significant fraction of car manufacturers... are the hardest.

The Tesla Superchargers cost about $20k each to install, which is low enough that they didn't need anyone else's cooperation to cover the US.

Does the security team not count as one of the sets of "eyes"? Would they have discovered the bug without inspecting the code?

Considering that every restaurant, store or bar you've ever used your card at potentially stashed away your secret, how closely have you been monitoring your card for siphoning of funds?

It is not in the credit card companies best interest to even acknowledge this type of theft, because they have no way except machine learning to protect you from it.

On the other hand, it IS useful for them to acknowledge huge security breaches at corporations, because they can point to them and say: and look at how we protected you! (after their dumb security system endangered you in the first place)

Because it got slammed? Unlikely, but would be a nice surprise!

Timsort is in JDK7, btw.

http://grepcode.com/file/repository.grepcode.com/java/root/j...

But if this theoretical (but somehow very well defined) system supported offchain transactions, whereby a sender could attach a signed transaction for the appropriate amount to the sent message (rather than submitting it via a theoretical "peer-to-peer" network), then the throughput would be effectively unlimited.

EDIT: or micropayments: https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adju...

There are no version numbers in those benchmarks, nor any way to reproduce them. So take them with a few grains of salt.

In particular, how old was the version of git they were testing with? Were they using SSDs?

I wasn't excited about scala's macros initially [a], but Eugene's Burmako's recent talk [b] on the constraints the developers worked with to keep macros consistent and interoperable was illuminating, and has changed my mind to a large degree [c].

In the end, they only directly added support for 1) type-safe macros, aka "black-box" macros 2) ...invoked transparently as methods, aka "def macros"

They identified "white-box" (non-type safe) macros and quasiquoting as distinct from black-box macros, because the type signature of a black-box macro tells you approximately what it will do, meaning that you can treat it as a "black box". But additionally, in order to write a meaningful type signature, the input to a black-box macro must _already_ be valid scala code! This means that the addition of macros cannot actually result in new scala syntax [d].

[a] https://news.ycombinator.com/item?id=3709193

[b] http://www.infoq.com/presentations/scala-macros

[c] still hoping the existence of scala macros leads to the deprecation of a bunch of other features though

[d] see the explanation starting around 33m30s in [b]

Given the current trends in language design, it's interesting that Nimrod declares itself an imperative language, and that this talk doesn't discuss lambdas at all.