sirclueless

Unless I'm misreading things, the reason they only lost 6 hours of data instead of 24 hours was a chance backup, but there was never an existential crisis here.

Downtime happens to pretty much every service out there. In this case the company was incredibly forthright and so we can make fun of their stupid mistakes, but really most mistakes are stupid when you look at them -- when you make thousands of decisions a day, some of them will seem silly in hindsight. We just never learn about most of them.

Ahh yes, the advisory board with other fringe right-wingers such as Elon Musk, Satya Nadella, Larry Page, Eric Schmidt, Tim Cook, Jeff Bezos, and Sheryl Sandberg. How could he possibly be so two-faced as to throw his hat in with these marginal characters?

It's actually a pretty rational response for someone who is only moderately aware of what is going on in their computer. If they are aware that malware and adware can cause unwanted changes on their computer, perhaps because they've been bitten before, then a new icon -- even one that is easily interpreted (which this one would not be) -- looks scary.

The audio thing works because there is an obvious icon in the tab bar that shows the source of audio, so if developers use it in an annoying way the user can easily respond appropriately.

I wonder if you could run a paid study with a proper control group. Perhaps have everyone pay to participate, administer the treatment to half of them, and at the end of the study refund some amount of money (all? all + interest?) to the ones who received a placebo. That way they've only donated their time.

It's not necessarily as arbitrary as you're making it out. For businesses, the cost of failure is low and the potential upside is enormous. As a result, risk-seeking behavior makes sense, and people generally respect that. For humans, the cost of failure is very high, and the upside is only the productivity of one 2 meter bag of flesh with a brain inside. Taking existential risks as a human is foolish for reasons that do not apply to businesses.

I notice that this news piece is headlined "Alphabet's Waymo" thus avoiding mention of Google. I wonder whether this is good or bad for Waymo. I assume they're intentionally distancing themselves from Google and this is what it looks like.

Affiliates work fine for E-commerce and performance advertisers that can track conversions. They work considerably less well for cost-per-click advertisers and brand advertisers because the advertisers can't trust the publishers either; there are plenty of spammy publishers who will send fake clicks and impressions your way for $$.

This is the major reason ad networks put JS on publisher sites. You can't give a website author "complete power" any more than you can give an advertiser complete power.

See steveklabnik's detailed answers elsewhere in this thread, but the short answer is that you can't write this data type in Rust.

Thanks for all the responses, I'm learning a lot. This explains to me why iterators and other references to the internals of a data type have to take ownership of the whole data type, which is something I ran into several times during my (brief) explorations with Rust.

Interesting. How does Rust handle types that want to do interesting things when copied, like bookkeeping or updating internal pointers? Maybe you just can't, which would preclude some kinds of intrusive data structures, or owning non-copyable mutexes for example. Does `drop()` get called on objects that have been copied from?

Well, for trivially copyable types[1] the reallocation can be a straight memcpy. For the rest, I don't know that having or not having a move constructor is the important distinction; it will be preferred over the copy constructor if it is declared as not throwing exceptions, but either way some constructor of the object must be called if it exists (though it might be inlined and optimized away).

I imagine Rust does something similar, copying bytes if the underlying type has the `Copy` trait and calling some actual code if not, but I'm not familiar with the details.

[1]: http://en.cppreference.com/w/cpp/concept/TriviallyCopyable

> Neither C nor C++ knows, at the language level, the size of an array, unless that size is fixed.

Neither does Rust.

> The subscript checking variants of C and C++ have to use "fat pointers" which carry along size information.

So do Rust's Slices.

> The overhead for this is large and nobody uses that.

People use std::vector all the time for this purpose in C++. It has about the performance you'd expect, with very little overhead except where you want it in bounds-checking.

I don't think there's actually a performance difference here. Rust's default is safer because it requires dropping to unsafe code to do something dangerous, but the same optimizations are available in both.

The basic argument made by the "random chance" commenter was not that evolution is a random process, but that it favors organisms with complex and interdependent gene expression, because this increases the rate at which random mutations cause differentiation.

> Nobody is suggesting AI will replace salespeople in the near future.

They aren't? Because I see this happening all the time. Automated checkout lines, E-Trade and online brokerages, etc. Low-value transactions are handled more and more by electronic "salespeople". All it takes to reach high-value transactions as well is for the clientele to decide they trust machines more than humans, which is not all that unlikely given the many sources of human error involved.

It's possible that humans will be involved in high-value transactions like investment for a long time, since the marginal cost of human labor is low as the numbers get bigger, but it's not impossible to replace; we already have the technology.

This is true for the toy example. In the actual problem, the loop guards are quadratic equations or even higher order, and his first method generalizes better (and for small ranges is hardly slower).

The assumption behind string.format and friends is that people who override __getattr__ and __getitem__ know what they're doing. Which is probably a reasonably safe tradeoff in order to allow attribute access.

I'm not worried about executing arbitrary code, because it's not user-supplied and it's normal for a templating library to access attributes of objects you pass to it (if it was unsafe you shouldn't have done that). This is more of a snafu with the number of sensitive and powerful attributes available by default on Python objects.

At the risk of introducing a contentious topic into polite discussion: there's an obvious parallel with abortion. It's seen as pragmatic, and maybe even kind, to terminate an entity's existence before it can achieve the intelligence and sentience that grant it moral rights.

If you're OK owning and operating a robotic arm, and not OK with owning and operating a sentient AI, then what to do with robotic arms that develop sentience over time?

You can define a pointer of type `int (*)[5]` and assign `(&arr)[1]` to it. That's fine, it's a pointer to the 5-element array just after the one we're sure is valid.

Dereferencing the pointer is UB, but you can create the pointer, assign it to a variable, etc.

Well, I think like every other loosely federated communication system from the 90s (except email), the scene has moved on to a couple proprietary platforms providing a better user experience. lichess.org and chess.com have pretty good scenes now, and you can still make friends there.

What to do with commits that touch both back-end and front-end code in step 2.? This amounts to manual run of git-filter-branch, which is a feature the author was unaware of. Without that tool this task is daunting. If the author is willing to manually rewrite potentially hundreds of commits that touch back-end code, then there are a lot of straightforward solutions. We're looking for something more elegant.

Speaking from experience, I've had to worry about what implementation of sort is being used in many languages, from Java to C++, even Go and Python.

There are a lot of details to get right: how are elements compared? Is the sort stable? Is it efficient for small N? Is it efficient for nearly-sorted arrays? Is it efficient when almost all the elements compare equal? Is it guaranteed O(n log n) or average? If average, is there an input that reliably triggers n^2 behavior making it a DDoS vector?

Anything is a leaky abstraction when you care enough.

If your project cares at all about security you should at least be using some form of query builder. The bare minimum is a system that binds parameters of a query to user data without manual escaping.

From there the distinction between ORMs and query builders gets fuzzy, it's more of a spectrum than a bright line. I particularly like SQLAlchemy's model of a core SQL-building library with an ORM you can use piecemeal around it.

Re: your nitpick.

It's true that TLS as implemented on the internet encrypts with a private key and decrypts with a public key, but this is not universal. Encrypted PGP communications, for example, work the opposite way.

Encrypting with a public key is a common technique if you want to ensure that only one person or device can decrypt it, which is what is desired here. It doesn't prove authenticity, unless you also sign the message with your own private key, but that's not the goal -- protection of the message from unwanted actors (and yourself even under compulsion) is the goal.

If "Foo" represents anything at all complex or stateful (e.g. a database connection, a model of some data, an HTTP server, etc.), and you might want to extend it later, it's going to be messy.

If you assume there is only ever going to be one implementation of "Foo", then there's nothing to be gained by using an interface over a struct with private fields. If there are other implementations, then you have to update every implementation in sync with the interface every time you add or change a method. That might be very difficult or even nigh impossible if they're in different packages maintained by different people.

My point is to be very careful with how you use interfaces. They're designed to represent abstractions that apply to multiple data types. Looking at the standard library, Reader, Writer, Stringer, http.Handler etc are all pretty useful as interfaces. database/sql/driver has the Driver interface, which is about as complicated as you should allow an interface to become. Notice that nothing in database/sql implements the Driver interface -- it's strictly for polymorphism, to consume external implementations -- and nearly every type in database/sql is a raw struct.

Accepting interfaces is an implicit commitment to support external implementations of the interface. You can't add a method to an interface without breaking clients who do this. This makes interfaces more fragile than structs.

A concrete example: If I have a NewFoo function that returns a Foo and a FooTaker function that accepts a FooInterface, I can't assume that new features I add in NewFoo are usable from FooTaker. If FooTaker just took a Foo, there would be no problems.

This is, I think, the best rule of thumb for when to use an interface: If you expect consumers of your library to write their own data types that could be used by your library, define an interface they can satisfy. Otherwise just produce and consume a struct you control -- it will be much more flexible and maintainable in the long run.

So, to follow the diplomatic approach here:

Client: "Encrypt our data using the md5 cipher."

Consultant: "I will investigate the feasibility of this."

... two days pass ...

Consultant: "I have considered your proposal. I believe we should encrypt your data with SHA-256. md5 is insecure, here's several references. SHA-256 is much more secure and more popular. It is a NIST standard, and just as cheap."

Client: (probably) "OK, if it costs the same and is more secure, sounds good to us."

> the text model of Python 2 is a giant mess and makes it very hard to correctly deal with non-ascii text for any non-trivial software

There are counter-arguments to this. Armin Ronacher, author of (among other software) the excellent Flask web framework, thinks that Python 2's system of codecs and byte streams is better in practice [1][2]. Reasons include: You can do byte -> byte conversions with codecs that are no longer possible. You can better handle text encodings besides UTF-8 (and here he describes several embarassing failures of Python 3 to handle OS paths correctly). You can write single APIs that handle byte streams like gzip and text encodings like UTF-8.

[1]: http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/ [2]: http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/

If you can do it convincingly, you can probably play games involving some skill if you adopt a consistent and beatable strategy. Like Uno by playing the oldest legal card in your hand and choosing a color you hold randomly for wilds, or Guess Who by always choosing an attribute that about 1/4 of remaining characters share.

No, that would also qualify as "AI algorithm wizardry" as dheera puts it. Instead it's just a hardware sensor that measures the time at which light arrives at each pixel. Knowing the speed of light you can calculate the depth of each pixel.