They could also write the comment in French, and by the same argument people should need to go out of their way to copy-paste that into google translate.
Thousands of people are going to read this thing. The writer could spare thousands of people spending tens of seconds (totaling days of human life), by simply spending less than a second spelling out the obscure term.
Boy are you going to be surprised when you find out that there is an entire French literary tradition that doesn't concern itself with who does and does not speak the language.
This is too forgiving of intel in this case. It has a name. They just don't use it. "Sockets Supported: FCLGA2011". It's not like this is poorly named. It's not even true.
Are they bugs, though? Or just ambiguities where they want bug-for-bug compat?
Another commenter said "dumb cases where it's 100x slower when providing unrealistic values like parsing e9000000 which is actually because it attempts to actually parse it due to bigint support instead of clamping to i128".
Not very. Most notably `env -S` doesn't work on some systems. I did get bitten by one script on Ubuntu using uutils where the script expected `uname -p` to work but it just prints `unknown` (technically legal I guess). But when I went to fix it they already had.
Probably was a bit premature for Ubuntu to enable it by default. Looking at the graph uutils will be fully compatible (or as close as makes no difference) in about 2 years, so I would have waited until then.
Still, I think most of the push-back is just the usual anti-Rust luddites.
To be fair, `/bin/sh` is suppose to be the POSIX shell, so as long as they are compliant it really doesn't matter. The problem with `/bin/sh` being bash, is that it provides extensions (even when running in POSIX mode from what I remember) and relying on them makes those scripts technically broken.
It would be more of a comparison if dash was aiming to be a drop-in replacement for bash and not a POSIX shell.
Well that's kind of my point. `ls` and `find` are "supposed to be" POSIX `ls` and `find`.
Obviously on a GNU system one can't just drop the GNU extensions, but what Rust Coreutils is fighting is (IIUC) to a large extent the goal of becoming bug-compatible, or unspecified-compatible.
For unspecified-compatible, to support users who relied on it (Hyrum's law), the same case could be made that lots of people relied on /bin/sh being bash.
dash may not have been aiming to be drop-in replacement for bash, but when OS vendors change /bin/sh to dash, what's the difference?
> Well that's kind of my point. `ls` and `find` are "supposed to be" POSIX `ls` and `find`.
I don't know about that, I at least wouldn't 100% agree on that. Mostly since POSIX only defines short args it kinda makes just not want to use them, since I like to spell out the long arg in scripts for clarity. So by default I just assume I am using GNU coreutils (since BSD coreutils have slightly different names in some places IIRC). And since there isn't such a destinction between "POSIX coreutils" and "GNU coreutils" like there is with "POSIX shell" (sh) and "bash" I wouldn't call the situations equivalent.
Well, my point is that escape analysis has nothing to do with it at the semantic level. So it's actually just 'because GC'. You don't need the concept of escape analysis at all to understand the behavior of the Go example.
I mean that escape analysis has nothing to do with my example either, in terms of understand the semantics of the code (so I’m disagreeing with the ‘because GC and escape analysis’ part of your comment).
Escape analysis clearly isn’t part of the semantics of Go. For that to be the case, the language standard would have to specify exactly which values are guaranteed to be stack allocated. In reality, this depends on size thresholds which can vary from platform to platform or between different versions of the Go compiler. Is the following non-escaping array value stack allocated?
func pointless() byte {
var a byte[1024]
a[0] = 1
return a[0]
}
That’s entirely up to the compiler, not something that’s determined by the language semantics. It could vary from platform to platform or compiler version to compiler version. So clearly you don’t need to think about the details of escape analysis to understand what your code does because in many cases you simply won’t know if your value is on the stack or not.
While you are of course 100% correct, in the context of discussing escape analysis I find it odd to say that it's essentially not "real".
Like any optimization, it makes sense to talk about what "will" happen, even if a language (or a specific compiler) makes no specific promises.
Escape analysis enables an optimization.
I think I understand you to be saying that "escape analysis" is not why returning a pointer to a local works in Go, but it's what allows some variables to be on the stack, despite the ability to return pointers to other "local" variables.
Or similar to how the compiler can allow "a * 6" to never use a mul instruction, but just two shifts and an add.
Which is probably a better way to think about it.
> So clearly you don’t need to think about the details of escape analysis to understand what your code does
Right. To circle back to the context: Yeah, OP thought this was due to escape analysis, and that's why it worked. No, it's just a detail about why other code does something else. (but not really, because OP returned the slice by value)
So I suppose it's more correct to say that we were never discussing escape analysis at all. An escape analysis post would be talking about allocation counts and memory fragmentation, not "why does this work?".
Thousands of people are going to read this thing. The writer could spare thousands of people spending tens of seconds (totaling days of human life), by simply spending less than a second spelling out the obscure term.
reply