Rust types have markers (Send, Sync) that tell the compiler whether they can be moved across threads, and whether they can be simultaneously accessed across threads.

These markers are irrelevant in a single-threaded scenario.

It's not purely about those markers. Many people also believe that the only issue with aliasing is when threads come into play, but that's not the case. Rust also prevents mutable aliasing even in non-threaded cases for this reason.

Is there any explanation of this? Specifically i would like to understand how a single mutable reference is required for correctness in a single thread scenario.

I’ve googled everywhere but I can’t find a single source of information that completely explains this, possibly showing realistic source code and elaborating the way it could generate memory errors or be miscompiled in case of multiple mutable references.

https://manishearth.github.io/blog/2015/05/17/the-problem-wi... is what I usually link folks to.

The TL;DR is: iterator invalidation can happen even without threads.

Thanks, exactly what I was looking for!

For example, if I could push to a Vec while holding a slice to it, that would obviously lead to horrible behavior if the Vec needed to reallocate.

Another example is if someone tried to use a Vec x inside the closure passed to x.drain.

Right, but the question was:

> doesn’t Rust refuse to compile even when you use non-concurrency safe objects in a single thread?

and given that most types (Vec, HashMap, etc.) aren't "concurrency-safe" (thread-safe?), your answer

> yes

is rather perplexing.

Yep, you can't implement UnsafeCell yourself without running into undefined behavior.

Right. The main advantage of Rust is that its thread safety is opt-out (unsafe) rather than opt-in (remember to use the right data structures / locks).

It is a convention, not a rule, in mathematics to use (+) to represent operations that are commutative (i.e. abelian) groups.

But this convention is not at all respected in programming (e.g. + for string concatenation in many languages) so I have to admit that it's pretty irrelevant.

The war to keep programming operators at all consistent with mathematics was lost long ago, with `=` and `==` being the worst offenders.

To be fair, mathematics uses = to indicate assignment as well, e.g. for summation limits.

Literally no "non-tech-savvy" person I know backs up anything at all. I seriously doubt that backup / transfer is on anyone's mind at all when deciding to use a new messenger.

I mean, for most competing apps this backup is completely transparent. It's when they reinstall Signal that they'll notice all their messages are gone irrevocably.

I don't understand this claim: I don't know any non-tech person who has WhatsApp backups enabled and working. If I don't go through the process with them when they're changing phones they'll literally start from blank state and are ok with that.

Really? I mean, either a few drug dealers slip through the cracks, you fill the nice fun stadium with creepy surveillance cameras to cover your own ass, or the stadium simply doesn't exist. I'm all for options (a) and (c), but option (b) is the worst.

Why? I can't think of an alternative that users wouldn't complain about.

Great, but this reads like a particularly blunt Amazon ad. Is there a way to achieve "high scalability" without selling my soul to Amazon?

Yes, it does read like that.

In the context of a start-up, cost is a big factor and then perhaps (hopefully) handling growth. You could start small and refactor apps/infrastructure as you grow but I am unsure how one could afford to do that efficiently while also managing a growing startup.

On the selling soul to cloud provider, I don't see it like that. I have a start-up to bootstrap and I want to see it grow before making altruistic decisions that would sustain the business model.

Once you are past the initial growth stage, there are many options for serverless, gateway, caches, proxies that can be orchestrated in K8 on commodity VMs in the datacenter. Though this is where you would need some decent financial backing.

(I am not associated with Amazon, Google or Azure. I do run my start-up on Azure.)

I'm down a similar route, but I must point out that beyond a certain number of users / scale, Serverless becomes cost-prohibitive. For instance, per back-of-the-napkin calculation, the Serverless load I run right now, though very cost-effective for the smaller userbase I've got, would quickly spiral out of control once I cross a threshold (which is at 40k users). At 5M users, I'd be paying an astonishing 100x the cost than if I hosted the services on a VPS. That said, Serverless does reduce DevOps to an extent but introduces different but fewer other complications.

As patio11 would like to remind us all, we've got a revenue problem, not a cost problem. [0]

[0] https://news.ycombinator.com/item?id=22202301

The big clouds have similar enough products, just the names are changed, so at a high level, GP's list of AWS products can be swapped with eg, Azure's product names. https://www.wintellect.com/the-rosetta-stone-of-cloud-servic...

Sadly, anything more in-depth than that, you'll need to sign an NDA with AWS to learn anything about the performance limits of their services (eg Redshift), and you won't get that unless you're already a big customer there. Azure's not going to be falling over themselves to let you know where they fall short, either. This is vendor lock-in, and is why there are so many free cloud credits to be had to startups.

This is also a reason I believe SaaS companies will find it is harder than they realized to arbitrage between clouds, and business models based on that may not be able to get that right.

I think if you use something like serverless, you can abstract the cloud layer. I've never used it for anything more than a toy project though.

https://serverless.com/

High scalability always revolves around the storage layer. There are plenty of options in the free software world; MongoDB, Redis, variants of MySQL/Postgres replication, Cassandra, FoundationDB, and many more.

Using one of those is where you'll spend most of your operational time if you really need that level of scalability. Most people don't, but the options are there if you really need them.

If you are happy with your storage layer, which most people are, the rest scales horizontally pretty easily. And there are plenty of free things you can use to get what a cloud provider gives you.

> App load: |User| <-> |Cloudfront| <-> |S3 hosted React/Vue app|

The CDN is always going to be tough to replicate on your own. In the end, latency is bounded by the speed of light, so you can only bring your files closer to your users. I wouldn't expect you to build one of these yourself; just buy one until you're the size of Google.

> App operations: |App| <-> |Api Gateway| <-> |Lambda| <-> |Dynamo DB|

Your app should be designed to scale horizontally; don't keep any state in your app, delegate it to your storage layer so you can scale a CPU-intensive app up across multiple servers.

There are quite a few API gateways around; Ambassador comes to mind but there are a million. I personally use raw Envoy for everything. I was load-testing my website the other day and pushed 5000qps through it from my cable connection before I decided "it's probably fine". (I started dropping frames on the Twitch stream I was watching, though ;)

There are plenty of "serverless" frameworks that emulate what Lambda does. knative comes to mind. I have not experimented with them in depth, but am intrigued by the idea. (I am more intrigued by turning config files into webassembly-compiled programs, to make existing apps more configurable at runtime. This is like serverless, but less general.)

> Add in Route53 for DNS, ACM to manage certs, Secrets Manager to store secrets, SES for Email and Cognito for users.

CoreDNS scales nicely and has an API. cert-manager is an open source way of obtaining certificates (though it's tightly coupled to Kubernetes); either ACME (letsencrypt) or your own root CA. There are a bunch of free software secret managers; Vault, bitnami-labs/sealed-secrets, etc. I personally use git-crypt ;)

Email deliverability is always going to be an issue. Like the CDNs, you might want to delegate it while you're small. Use anything except Mandrill.

Yes, sell your soul to Google.

For many lying is already a deeply ingrained habit, and for them honesty will take practice.

> Reading a few top research papers in a field you're interested in and work through them

Why reading a research paper rather than the more standard approach of reading a textbook?

Recent research papers are the stuff that hasn't made it into textbooks yet.