deschutes

My complaint is that it is too easy to create an object with uninitialized members by accident. On account of the syntax being identical. I guess its too late to add affordances there.

I suppose a definition of valid that prohibited uninitialized members would preclude lots of useful stuff like container and buffer types.

From the msan documentation [1], the flaw with my earlier example is that `printf` isn't instrumented.

And to address your other question, I don't know if msan can instrument a function implemented in assembly. It definitely can't deal with something it didn't compile as the instrumentation is added during compilation.

It seems that on godbolt the platform library also isn't instrumented because the equivalent iostream code is msan clean [2]. I suppose that makes sense as it's allowing you to pass arbitrary options to the compiler.

In summary, msan can detect these uninitialized reads but it requires quite a lot of fiddling.

[1]: https://clang.llvm.org/docs/MemorySanitizer.html#handling-ex... [2]: https://godbolt.org/z/Gsxsfn9GT

It depends on what you mean by "object". For example, pod types share syntax with classes but are not always initialized.

What's better is that sanitizers don't detect this form of undefined behavior! (Clean on memory,address,undefined.)

https://godbolt.org/z/7jsxnMs8E

also relevant: https://i.imgur.com/3wlxtI0.gifv

Clang tidy covers only the most trivial use after move scenarios. It's useful coverage but isn't and never will be complete like the rust borrow checker.

So, my understanding is that: 1. Unless otherwise initialized, types have a zero value in go. For pointer types that zero value is nil. 2. It's encouraged for this to be meaningful. That's opposed to say java, python, or C++ where invoking a method on a null object is a runtime error (or undefined behavior). So for example, appending to a 'nil' slice is the rough equivalent of trying to add to a null List in java. I don't see how the go approach makes anything simpler.

Value semantics are simply that the value of an object is all that matters. For example, two int objects '5' are the same from a value-semantic perspective. I guess this implies all objects have some value. This requirement can be satisfied by requiring they be explicitly initialized.

Equatability is a requirement of objects in java. Not all types of objects are equatable beyond their identity (some unique identifier) though. For example, how do you equate two functions? To me this parallels the decision in go to make zero values a thing beyond a runtime error.

Why require types have a meaningful zero value?

It's not necessary for value semantics. You can require that values be initialized and the machinery for that doesn't seem that bad.

Zero values seem as arbitrary as requiring all types be equatable.

I'm not sure what you're driving at. The sibling clearly outlines a scenario where the collateral is lost. But it almost doesn't matter so long as you assume the clearinghouse isn't some vestigial intermediary.

I can't answer why customers with cash in hand couldn't directly settle the trade. Maybe most of the time it doesn't matter and it's easier for brokers to have one settlement process. Maybe the industry has come to depend on the delayed settlement in some unrelated way. Maybe it's something that hasn't fully been adopted due to change taking time. Maybe the referenced regulations get in the way of an uncollateralized process.

It makes perfect sense for a regulation that intends to protect the retail customer's interests. I suspect Robinhood would put customer money up for collateral if they were allowed to do so.

Here's what I gather from that thread.

The bottom line is that the retail trader stays whole in the case the trade fails to clear.

If the broker was allowed to use the retail trader's money for collateral it would either not really be collateral or it would be at risk of being forfeit. You can't have it both ways.

I'm not sure deferred conversion is a bad thing in this toy instance.

I agree that being able to easily tradeoff between time and space is an important property of compile time evaluation and C++ doesn't make that easy with the no escaped allocations requirement.

On the other hand, I shudder to think what will happen to binary size. It can't be any worse than codegenning all the things with reckless abandon... Right?

I missed that. You're right.

String literals are specified to have static storage duration. That means references are valid at least until main returns. In practice string literals are immortal and references to them are always valid.

Have to defer conversion to std string to runtime https://godbolt.org/z/rWKEr4P6h

In that case, the soap is the least of your problems.

Find me a reasonable person offended by this terminology and I'll show you an unreasonable person. That connotation doesn't come through at all.

I had a similar belief that ended much the same.

Wait till you see the rest of javascript...

It's amazing that a dog smelling odors could be evidence of anything, even taken in the context of other evidence. In my view the dog is simply a tool to find evidence. The tool indicating there is evidence is not evidence.

The problem with trans fats seems to be a matter of degree rather than kind. See the note on palm oil on Wikipedia. Also note that deaths attributable to coronary artery disease, the quantifiable thing linked to trans fat consumption, are hugely decreasing over the period where trans fats became common, suggesting again it's not a high order bit.

If we consider this in the context of GMO it sure seems like FUD to me.

Ok. Show me something that would be a food but for "delayed bad things". Like, delayed by decades or even years. Just so we're clear, nutritional deficiencies aren't of any interest.

As far as I'm aware this angle is FUD.

If we want to apply the same standard to pesticides I'm not sure any high ground exists. That said, whatever effect they have on mortality appears to be miniscule given the trends over the last century.

I find reviews work best when you place a strong bias towards shipping workable if imperfect code. Quick reviews are also a strongly positive thing.

On the other end are fixed processes. Have as little of this as possible, automate it if you can. That means formatting, linters and shallow static analysis.

All of this is mainly in service of building trust. If you cant have some measure of success there you are truly doomed.

It doesn't do a very good job of delineating the coast. Seems like +- 50 ft is black. Puget sound is unrecognizable on my display.

What you're describing is WhatsApp. So we don't need to speculate.

iMessage benefited tremendously from being the default. Combine that with Apple's mobile market share in the US and you get the present situation.

My gripe isn't really that it won in the US. Its that you need Apple hardware to participate.

Google may be self interested but they're right about one thing: knowingly allowing and fueling this social dynamic is inconsistent with Apple's brand. But it was never really about values, just making consumers feel good about their purchases.

This is a hard problem and definitely not unique to Java. For example networks, or perhaps more appropriately, network protocols, have these kinds of cliffs as the offered load on the network increases.

As I understand a particularly bad traffic jam in the early internet is what motivated congestion control in TCP. As a matter of a fact traffic is also an example of this phenomenon playing out without any (effective) compensating measures.

I find "Metastable failures in distributed systems" [1] to be a really interesting and accessible exploration of the problem.

[1]: https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s...

How can the runtime conclude that the rejection is unhandled when there are outstanding references to the Promise?

In other words, as long as the promise might later be awaited or otherwise handled I don't see why the runtime should care. (That's the mental model I carry from other languages.)

It's pretty easy to understand. The idea is that the recommended doses are demonstrably not lethal. They may or may not be effective. The effective dose (if any) may or may not be lethal.

I don't know enough to evaluate any of the claims, I only wish to note the logic is pretty easy to follow.

I suspect you already understood all of this and chose to misunderstand to ... "win" the argument?

Memory safety bugs can be intimidating and sometimes challenging. Mostly they're not though.

Conscientious programmers aren't going to spend too long in the shooting themselves in the foot phase.

To me the awful compilation model and horrendous compile times are much bigger productivity bummers.

I enjoy helping folks debug memory safety bugs that stumped them. It takes the drudgery out of the day. And it's usually an opportunity to teach them something.

Model fallible instantiation with factory methods. e.g. Node::make(Args..) -> Result<Node>. It won't always be as efficient or ergonomic but it works. And hey it's c++, you've been conditioned to accept a ton of ceremony to get things done. Famously the bulk of google's code is written without exceptions. And from what I know of it (not much), factory methods are how they model instantiation fallibility.

As a related but separate thought, sometimes adding invalid states to an object is useful. For example, take a look at std::thread::detach. Sometimes you see rvalue qualifiers on such methods (indicating the object has been consumed).

If you consider memory allocation to be infallible, there is a lot of stuff that can be written as pretty normal c++ without exceptions. The STL even pretty much works without throwing given this. If you consider allocation to be fallible you're going to have a bad time with "standard" c++ too.

I don't like ion. The added features (over json) don't pull their weight. Symbols, annotations and the binary format all add significant complexity but don't make the format much better. As a consequence of the added complexity language support is poor.

For RPC the binary encoding compares poorly to external schema formats like protobuf. In this context binary ion is a poorly compressed text format.

I don't think the partial document read capability of the binary format is all that important, but I've never worked on an application that would benefit from it either.

My opinion is based on my experience integrating artifact generators (both code and config) into a build. I recall being funneled into building a plugin by documentation to deal with some idiosyncrasies of the generator. Whereas I just wanted to write a small script. In general I felt like there were a lot of extra hoops and concepts to learn to do basic easy shit. And there really isn't any payoff. For example I recall scripts and plugins have different capabilities. And that some things can't be expressed in untyped Gradle.

I also found that the user documentation was just a skosh above useless. It felt like it was more concerned with not being wrong than being helpful. Reminiscent of older javadocs in the java collections library.

The same could be said of many build systems, I suppose.

Gradle does suck though.