anameaname

Following the law isn't black and white. I'm sure each of us as individuals broke the several times today without even knowing it.

The paper that was linked suggests using derivatives rather than directly taking out loans, which are financially convertible. Specifically it says buying deeply ITM call options for several years out strike date.

In Item 10 it says:

> One study I remember showed that young investors should use 2x leverage in the stock market, because – statistically – even if you get wiped out you’re still likely to earn superior returns over time.

And the linked paper says:

> The mistake in translating this theory into practice is that young people invest only a fraction of their current savings, not their discounted lifetime savings. For someone in their 30's, investing even 100% of current savings is still likely to be less than 10% of their lifetime savings

This makes a lot of sense to me and says what I haven't been able to about my own risk tolerance. What is OPs counter to this? That the paper's conclusions are flawed, or that no 20-something could execute it?

I've use Go's context based cancellation, and while I like the paradigm, it's kind of verbose. There are some that say that since it has to be passed everywhere, and can store values, it's equal to Goroutine-local storage. I'm would be surprised if they don't include a formalization in the language itself in version 2.

You are right, editted.

As another surprising thing, calling interrupted() actually clears the interrupted bit. If it's true, you pretty much have to throw InterruptedException. Otherwise, you have to re set the bit, and exit quietly.

Net income is not that useful of a metric since both companies are still growing.

This is on purpose. If the number of support people is a linear function of the number of users, the business cannot grow past half the worlds population.

This is what you get when you don't have a top-down management style. Teams are given too much freedom, leading to inconsistency. No one has the whole vision of how a product should work. Even if they did have that, they likely don't have the authority to make it happen.

Large transfer's wouldn't be the place where the effect would be noticeable, it would be JSON payloads that can fit in a few packets. If operators would do this seldomly enough to not be noticed, why do they need the bit at all? It feels like a blank (albeit single digit) check.

Realistically, are network operators going to add artificial delay to packets going through their network? If they don't get their bit, and they start slowing down communication, it would seem like market correction would solve it.

If you give an engineer a bit:

https://mailarchive.ietf.org/arch/msg/quic/yQfBIAOnUEKIWjZhF...

You can kind of see how this might get out of hand and cause the discuss to digress and go in circles.

> QUIC (aka HTTP/3)

Why focus on QUIC when the JS APIs to use it aren't available? Numerous of the features of HTTP/2 aren't usable (i.e. trailers, flow control, security sensitive headers, priority, etc.).

I don't understand how the web is supposed to flourish without giving web developers some kind of access to these tools. Meanwhile, app developers are showered with such goodies.

Dissenting opinion: I think the blocky version looks better when not zoomed in. The sample on the left is less smoothed, and doesn't look as airbrushed. It looks better when zoomed in, but not when are regular zoom.

It will change as SF's credit goes down the tubes. Unlike the federal government, there is a chance that SF could default on its loans. If they can't get a loan and they squeeze the rich out of the city, there won't be any money left.

If getting off the plane early while it's on the ground is valuable, why not charge for it? That way people who really do want to get off can? It's hard to say that deboarding early is a right, because that would imply your rights change if you were in the air or not.

I think gp's concerns would be addressed by making this transaction legal and letting passengers and airlines arrive at a fair price.

That could be fixed though. If the Airline let the luggage go the final destination, they could charge (maybe $100) to return the luggage once it arrives at the destination. This would also decentivise people from trying to deboard unless it was really important.

For the record, the reason grpc uses trailers is because it uses http/2, not the other way around. It was expected that since the whole transport was completely new, adopters of http/2 would add trailer support. As it turns out, they mostly didn't. Particularly Firefox and Chrome did not expose trailers. This is even despite being part of the new Fetch API.

All core grpc libraries support bidirectional streaming. It's the "routeguide" example.

Finally! Up until now, when people ask how they are supposed to proxy grpc traffic, we could only recommend Envoy. Pretty much no one wants to hear that they have to change their stack to use new technology. Since a large part of the world is already on nginx, this was a a real barrier for adoption.

Next up, browser support?

Isn't line breaking an NP complete problem, akin to bin packing? I seem to recall hearing a presentation about it in the context of autoformatters for code. For example, Auto formatting Java code, which is typically verbose, relies on heuristics to avoid computational snares.

An unfortunate part of experimenting with advertising is that it's expensive. Trying to find the right audience for the ad is very costly, to the point where I don't understand how advertisers can afford it.

I say this as a tinfoil-hat person: narrowing the audience is going to need a lot more info about the person. Particularly, their browsing history (i.e. remarketing). Knowing this would raise the conversion ratio immensely at the cost of privacy.

America, and the market as a whole benefits because something new is created. Even if you didn't own any Apple stock, you can still buy something that didn't exist until Apple made it. iPhones are an option for consumers to choose when making a purchase that otherwise wouldn't have existed. You can buy something that previously didn't exist.

A smaller scale example is restaurants open late. If you wanted a meal at 4am, a 24-hour restaurant is providing you value because otherwise you would have gone hungry. The value to you is fulfillment, even if you don't own any of the restaurant, or even if the restaurant didn't pay any taxes.

There is real value in companies moving the world as a whole forward. You don't have to own part of them to get the benefits.

It's hard to tell ahead of time if performance matters. When you hack something out, and are able to get it to work, it inevitably starts to grow features. At some point (around 1000 lines in my experience), Python no longer is fast enough, but the code is difficult to port to something faster.

It would be much better if you didn't have to back track on all the code you wrote. I've been burned by this enough times, that now I am wary of starting anything in Python, because I know it will grow to be bigger, and I will regret having picked Python!

For the record, gRPC can use JSON. There are examples in the repo on how to do this:

https://github.com/grpc/grpc-java/blob/master/examples/src/m...

A conundrum for me is how to get other people to code review the way I want to be code reviewed? Particularly, I noticed code reviewers on my team are pretty pedantic, obsessed with correctness, and need to be explained why each change is okay. These are people that regularly write good quality code themselves, but there is a high amount of distrust. Why doesn't a team of talented programmers trust each other?

(in case it needs to be stated, to date, I have reviewed about as much code as I have written, upwards of 100k lines, as have most of the other people on my team. We aren't amateurs, but it often seems like we're babies.)

FWIW, the primary maintainer of grpc-go left the team and it was passed on to a new maintainer. The new maintainer inherited the mess. Not justifying the project or anything, but I think that's why. Look at the Github top contributors to see what I mean.

The problem with web is that browsers don't expose trailers. gRPC depends on having trailers to know if the RPC succeeded or failed, but neither Chrome nor Firefox, nor any other browsers surface this information. If this was exposed in the XHR or Fetch API, gRPC would work.

It's browsers in this case that are the laggard (trailers have been part of the spec since HTTP/1.1).

> And it hasn't really been good for the industry.

Intel's problems over the past year aside, they have done an amazing job pushing the limits of computation over the past decades.

That isn't reading the graph correctly. The saw tooth pattern means that memory is being allocated, but not that it's slow. The CPU usage graph tells you if it's slow.

Object pooling is generally considered to be the worse approach, because it's tricky to know when to put object back in the pool. Realistically this mean ref counting. The code will get more complicated and bugs will happen when an object is returned to the pool but is still used. Each object will get bigger, since now it has to have an extra word associated with it.

Also, this puts undue stress on the GC. Collections won't pick up pooled objects, even when they could have been. This causes memory pressure because the program may actually need to allocate a large amount of memory, but none could be freed up.

I think the real answer here is to just do less work. Don't try to change a program to let it keep using lots of memory. Instead, make it so it needs hardly any memory in the first place.