wspeirs

3 more speakers added to the schedule

Beyond "not having GC", what are those reasons? I'm new to Rust and curious...

You can always check out Datto Drive http://www.datto.com/drive 1TB of free space for a year, then only $10/TB with unlimited users!

https://influxdata.com/ - purpose built DB for storing time series data.

As a few others mentioned, the 80% issue is one. We try and keep all machines below that so performance doesn't degrade. With the number of drives we have (200+ PB total space) we also run into issues where there are "holes" in the ZFS array after replacing a disk. We've always had enough redundancy work around any issues we find. Overall, I cannot speak highly enough of ZFS!

tcaputi works with me at Datto. We use ZFS as our main file system for some 200+ PB of storage. It is a truly amazing file system, and this change, once merged, will add another layer of security for our customers. Great stuff!

We run ZFS at my company, Datto, across hundreds of machines, including devices out in the field and servers in our data centers. It has a few warts, but overall very stable and the feature set has allowed us to deliver world-class features to our customers.

It's too bad this is written in Haskell. I don't have anything against Haskell, it is just not as popular a language as others.[1] Any ANTLR target language would have been a solid choice.[2] This way more of the community could contribute. This is an invaluable tool if we're truly going to see a shift from C (or C++) to Rust.

[1] http://pypl.github.io/PYPL.html

[2] http://www.antlr.org/download.html

Datto Drive just launched today and is giving away a TB of space for free: www.dattodrive.com

Ha... I started on the kernel, but it couldn't parse it, so I gave up :-(

How has this been here for 30+ minutes and no one has posted the complexity of the Linux kernel, gcc compiler, and of course the complexity program itself?

What's wrong with continuing to pay? All the time companies pay for support for open source software because they want the "insurance" of having someone to call when the $hit hits the fan.

You don't want to pay anymore, go back to glibc...

I'm not sure it would take "years and years" of static analysis research. You could use the data-flow analysis that is built into LLVM, then punt on the rest. It doesn't HAVE to produce Rust code that compiles 100% of the time. The goal would be to run it through the transpiler so you have a starting place to produce Rust code that compiles and works the same as the original C code.

Again, this might be a terrible idea, but I'd be curious to hear from anyone that has experience with this sort of porting...

Do people think companies would pay for a closed-source glibc if it were shown to be 100% compatible with the current glibc, but written in Rust?

I realize something like glibc would be the LAST set of source code to run through a transpiler, but how hard do folks think it would be to make a C -> Rust transpiler? I'd think you'd go about it by making Rust a target backend for LLVM. This way you let LLVM deal with the all C stuff (macros, etc), and just focus on the internal representation to Rust conversion. In theory, you'd get C++ to Rust as well.

Chances is successfully going from some not-so-obfuscated C code to equally not-so-obfuscated Rust code?

Agreed, the hope is that the combination of Rust + a rewrite, you'd be in a MUCH better place than where we are now.

I think an interesting question is, why are there so many contributors to the Linux Kernel in comparison to something like glibc? Both, I'd argue, are equally foundational.

Say we get the announcement that GV is going away tomorrow... anyone know of a decent alternative?

Yea, I wonder if stating a site is dangerous would be considered libel in the US...

Unless Python 4 is 100% compatible with Python 3, I hope they wouldn't overload that constant!

It's clear that the cost of storage is approaching $0, but it's surprising to me that the price of these company's services vary so much:

- Box: $180/year for unlimited (https://www.box.com/pricing/)

- Google: $120/year for 1TB (https://support.google.com/drive/answer/2375123?hl=en)

- Dropbox: $100/year for 1TB (https://www.dropbox.com/pro)

- Amazon: $60/year for unlimited (https://www.amazon.com/gp/drive/landing/everything/)

- Microsoft: $60/year for 1TB (https://products.office.com/en-us/business/compare-office-36...)

They all offer approximately the same service, but from cheapest to priciest is almost 3x. I wonder how much sand is left in the hourglass for companies like Box & Dropbox? Also, how much longer will Google keep their price at $120/year for 1TB when Amazon is half that for unlimited storage? Also, does your average Joe even care when you get 15GB for free from Google?

I wonder how hard it would be to create a C -> Rust transpiler. The output would probably be God-awful, but it could be a start to moving away from C towards Rust.

Is there something wrong with the counting, or is this an actual drop in users?

> If nothing else we need a solid competitor to keep them honest.

I completely agree which is why I've been trying to support Jet by buying "house supplies" through them instead of Amazon.

Maybe I'm full of FUD, but I just see a day in the not-too-distant-future where are only option is Amazon.

Amazon didn't have other sources, but they also didn't have a ton of competition or one "big guy" like Jet has with Amazon.

This allows for a future email, but doesn't allow for recurring emails... say every Tuesday at 9 AM. Also, my email list can change between when I issue that call and when the email actually goes out; there is not callback.

I also like how the last exclamation point on the 500 page is just a '1'... someone forgot to hold down shift :-)

Yea, been almost 30 minutes without an update.

I'm always curious what the scene looks like at Google right now. Are people screaming at each other? Or are some engineers just calmly looking through logs trying to find out what's going wrong...

I've had GREAT responses from Uber customer support when I rate a driver lower than 3 stars and add a comment. I usually get a follow-up within an hour or so.

> And Rust's solution to buffer overflows is the same as every other language — run time bounds checking.

Right, because that's the only way to do it? What's wrong with that?

The point is a language like Rust has built-in bounds checking...

To really "go for the gold" you can add in other abstraction libraries for talking to clouds like http://www.dasein.org/ and https://jclouds.apache.org/