tupshin

GC has non-zero overhead compared with linearly typed de-allocations, but that's not the main point. The title mentions predictability, and one of the big blockers to using almost any GC-ed language is the lack of predictability about runtime latency, which is very different than throughput, which I generally associate with the term bottleneck.

Additionally, predictable performance is about what the programmer can predict (whether you are talking about throughput or latency), and the argument is that linear types make it much easier to reason about the performance of a system, hence making it more predictable.

Sure, but rust benefits from must_use annotations, which effectively turn those annotated affine types into linear types. Turns out they are both useful in a very overlapping venn-diagram kind of way.

Have you considered https://getchip.com/pages/chippro ?

It does, but within what bounds? The CAP theorem doesn't specify. One could assume that it means before the partition is restored, but that is only one possible valid interpretation. The PACELC theorem, which is by no means the last word on the story, clarifies this well:

https://en.wikipedia.org/wiki/PACELC_theorem

"PACELC builds on the CAP theorem. Both theorems describe how distributed databases have limitations and tradeoffs regarding consistency, availability, and partition tolerance. PACELC however goes further and states that a trade-off also exists, this time between latency and consistency, even in absence of partitions, thus providing a more complete portrayal of the potential consistency tradeoffs for distributed systems."

And I would take that argument one step further and say that latency and partitioning are effectively identical, and from the point of view of any given operation, it is impossible to say whether the system is in partitioned state until max lateny (timeout) has elapsed, because failure to make progress within timeout is the only meaningful definition of partion-induced unavailability.

Can confirm that this is absolutely not the case. I have encountered a number of companies that are absolutely fine with [L]GPL but not going to consider AGPL.

Whether rightly or not, https://www.theregister.co.uk/2011/03/31/google_on_open_sour... and other writings on the topic had a big impact on enterprise adoption of AGPL software.

There's also the fact that most prominent AGPL licensing tends to be around commercially backed software where the main backer owns all the source and is therefore in position to not hold themselves to the same standard of sharing changes as their customers and third parties must do.

This might be deeper than you are looking for, but this is the theory it's based on, and even has diagrams. :)

https://arxiv.org/abs/1311.3903

Trivially, by never allowing either half of a partition to make progress while the partition is in place. Since the CAP theorem, by itself, doesn't put a cap(oof) on latency, it is valid to consider a system CA, if it if always available to listen to requests while partitioned, but never able to fulfill them.

This, of course, is effectively useless in practice, and is dependent on an infinite buffer of pending operations, etc.

https://brooker.co.za/blog/2014/07/16/pacelc.html

It is heavily inspired by Darcs, and is based on an alternative "theory of patches" that reportedly has much better worst-case performance characteristics.

It is written in Rust, instead of Haskell, also contributing to better/more predictable performance.

The Darcs folks are very aware and supportive of it, and last I heard, Darcs might add support for the Pijul patch format.

This is an extremely exciting project.

(speaking as a long time Darcs fan and passive onlooker who saw the Pijul presentation at rustconf)

While I largely agree with the positioning and much of the reasoning, this statement is so false as to be farcical:

"All solutions necessarily have to come from the middle ground. "

Just no. All good solutions should be taking in the perspective of both sides, but the best solution will often be from a totally unanticipated direction that is far from the middle ground of the status quo.

Mock the wife

By passively accepting this situation your are part of the problem. Morality aside, your coworker that denigrates employees by calling them girls is opening your 15 person startup to justifiable lawsuits (discrimination and hostile work environment) that could easily shut it down.

The fact that the main problem source is friends with your boss makes it a more challenging conversation, but in no way alleviates your responsibility of having it.

Cassandra

Given that none of those things are important to me, and that threaded messaging is important to me, I suspect we have very different answers to that question.

By your own admission, what you are asking for would require dependent typing. I am hugely in favor of rust eventually acquiring such capability, but it would be a huge change, and there are reasons why dependent typing hasn't hit mainstream languages yet.

That is an extreme mis-characterization of stymaar's excellent summary. in short, there are no runtime checks for iterating through an array, and since the general case of random access to an array can't be safe (without dependent typing), that is the one place the runtime checks are automatically added, and even there you can opt out of them. It is easy to get C equivalent speed with far more safety. You are spreading FUD, indeed.

I believe the idea is that tokio, because of its zero-cost abstractions will be able to be efficiently be the foundation of those styles.

Check out https://github.com/dpc/tokio-fiber/ for co-routines being re-envisioned on tokio, and https://github.com/rust-lang/rfcs/issues/613 acknowledges that the actor story is still a work-in-progress.

I have seen no indication that either coroutines or futures will be less ergonomic or performant due to being built on top of tokio's futures.

There is a lot of work already done, and more to do on this topic. The best source is the main tracking issue: https://github.com/rust-lang/rust/issues/2369

while it's still in early days, keep you eye on the tokio project https://github.com/tokio-rs/tokio which looks to be the foundation for higher level activity in this area

rustdt has been my daily rust environment for months. has some warts, but mostly just works

Edward Snowden responds to the HPSCI report on his disclosures

https://twitter.com/i/moments/812014048866877440

This capability is still a work in progress for rust/cargo, but check out

http://doc.crates.io/faq.html#how-can-cargo-work-offline

exactly the goal:

https://github.com/jameysharp/corrode

Except that the source article is exclusively about the problems with tech in China, largely due to government and cultural reasons that have very little to do with Taiwan, and the fiction that there is actually a single China, inclusive of Taiwan, is totally irrelevant.

These were the links in the article that provided background (the own-site links have their own references)

https://openmedia.org/en/bill-c-51-just-passed-where-do-we-g... http://www.tomshardware.com/news/snoopers-charter-passes-uk-... http://motherboard.vice.com/read/yahoo-government-email-scan... http://www.tomshardware.com/news/e2ee-yahoo-mail-hack-spying... http://www.tomshardware.com/news/burr-feinstein-anti-encrypt...

And this was the link at the bottom of the article that was actually being discussed. https://www.publicsafety.gc.ca/cnt/cnslttns/ntnl-scrt/thm09-...

Did you read any of them? Your comment seems disingenuous, at best

FWIW,after spending a couple of years with rust as my primary programming language, I'm convinced that they made the right decision wrt mutability (immutable by default, but mutability availale when needed), as rust's lifetime system eliminates nearly all the remaining pain points around mutability (data races).

On the other hand, I think it is very important that some notion of purity be incorporated, even if only as an opt-in.

In what way is Rust's use of affine lifetimes insufficient to implement "function programming with no garbage collection"? Genuine question, given my previous interest :)

https://twitter.com/tupshin/status/587275945163251713

https://twitter.com/tupshin/status/626164932778819584

Is anybody still thinking about Idris and HoTT? https://github.com/fmota/HoTT-Idris/blob/master/README.md I don't see anything more recent than the 2014 discussions.

The claim is that it is a blazingly fast hash function compared with other hash functions, and it is also written in Rust. Rust is an enabling technology, but not able to be dramatically faster than a comparable C/C++ implementation, as a general rule.

Personally I love Rust's error handling, but I do think that I understand your perspective.

At least part of your objections would seem to be addressed by the combination of the ? operator to make it trivial to do the equivalent of re-throwing inline, and the error-chain crate, which can make exception-like stack traces/etc trivial to implement.

https://brson.github.io/error-chain/error_chain/index.html