anonacct38

& doesn't always imply a value is on the heap. Escape analysis will ensure that pointers to the stack are safe.

Here's an example with a bit of explanation: if you pass a value to fmt.Println it will escape. The raw println builtin does not cause values to escape. So calling the first function twice and seeing the same address for the value strongly implies stack allocation while calling the 2nd function twice and getting different addresses implies heap allocation.

https://play.golang.org/p/PSb1wj1-x1c

Same reason Amazon didn't show a profit for years. Just means they are continuing to spend more than they make in an effort to grow and to find those killer apps and services that will make them the dominant player.

They do have a reputation issue, and it does cost them some business. There are CTOs who basically won't touch a google product in beta because there are so many things that get pulled.

That being said they are good at running vms and storage. They are really good at running kubernetes. Their network is amazing.

If wal-mart stops selling a brand of ice cream, is that censorship? Is it censorship that wal-mart doesn't sell playboy in their store?

If not, then why is the removal of an app from the app store censorship? The world wide web still exists. Parler is still on the internet.

Seems like there should be some acknowledgement that there's a difference between refusing to actively participate in distributing content and censorship.

Go's journey here has been interesting. Early on it was possible (though rarely seen in practice) to end up with a cpu bound thread not yielding because it didn't hit yield point like I/O.

Then they added a guarantee that if your loop called a function, the scheduler would be able to make the goroutine yield. https://golang.org/doc/go1.2#preemption

This mostly worked although you could still have a CPU-bound thread not making any function calls. I also personally ran into a pathological issue where the scheduler was being invoked, but a heuristic kept the current goroutine running so others were still starved.

Finally they added true pre-emption (not yielding) in 1.14 https://golang.org/doc/go1.14#runtime it looks like it just sends signals and saves state.

Once nice thing is that if I understand the go runtime correctly, work stealing by scheduling goroutines on different threads has been a thing for a long time.

I went through a pretty intense crunch time at a fortune 10.

We had one person go to the hospital with tachycardia and 3 people who were vomiting. There were only 10 people on the team.

> Didn't she inject code into an unrelated internal extension?

Depending on your definition of code, that's probably not the case. She added an entry to a config file that contained a mapping of urls to messages. Such as:

   dropbox.com/upload -> Friendly reminder: please don't upload internal documents to dropbox

Also, Google generally trusts engineers and it's not that unusual to have an engineer writing and deploying code. So essentially it was her job to work on and deploy this extension. I believe that had the message been an April fools day joke she wouldn't have been fired.

So in my opinion arguments that others have made (not you) that: "this was a unauthorized code change therefore obviously she should be fired on security grounds and charged with violating the CFAA too, it doesn't matter what the message was" don't really hold water. There's also an argument that she used some sort of "emergency" deployment mechanism, but that doesn't really hold water either. Honestly it's not that unusual to see people deploy some package when they need it rather than wait for a scheduled job to deploy it.

I think the grey area she was operating in boils down to: She had a platform to distribute certain types of messages internally and she put a message in there that probably wasn't the normal type of message distributed. If I were her manager I probably would have taken some action but it wouldn't have been firing.

The author touches on the reason, but I'd phrase it more strongly.

Shared mutable data concurrency is hard because it removes ability to locally reason about code.

    x=1
    x++
    assert(x==2)

can now fail.

I've seen both extremes. For instance I'm told github largely has a rails monolith and that they have to run headless instances of rails to do database leader election (although this statement implies they are trying to break things out).

I've also talked to junior engineers who want to make every function call a pubsub message.

I've heard principals from Amazon promote a model where one service is responsible for one entity.

What I've decided is that the services in your company should follow conway's law. Most of the problems with a monolith come when multiple teams with differing release cycles and requirements are making changes in a shared codebase and they are having trouble keeping their tree green. You should generally have one to a few services per team. Scoping a service to a team ensures that people can have true ownership.

For SREs microservices are harder, but they give SREs the control plane they need to do a good job. If communication happens between services rather than function calls, it's easier to instrument all services in a common way and build dashboards. It's simpler to spin up different instances connected to different datasources.