121–130 of 146 posts
Earlier quoted context omitted.
I filed a Go bug: https://github.com/golang/go/issues/20859 We should just fix the compiler.
I'm surprised Go doesn't compile down to an IR language where these differences in syntax are represented in a single manner. Seems like different ways to write the same thing.
Earlier quoted context omitted.
I think accusations of premature optimisation might be a little unfair here. Ignoring the style issues for a second (I'll pick that up later), if I'm looking at some code and there are two equally viable alternative ways of writing it, one of which saves a chunk of memory* or is faster then it's just perverse to choose the path of larger/slower code. I do this with regular expressions/string functions. I see people u…
The issue is that with the string/regex issue, there's a good reason that the string operation should be faster. Maybe a "sufficiently smart compiler" could optimize it in some cases of static regexes, but it's at least complicated. In cases where the regex is dynamically determined, even the sufficiently smart compiler probably can't optimize away the regex. In contrast, the case in this article seems like table sta…
start_with: 5703143.1 i/s regex: 2821224.4 i/s - 2.02x slower
That aside:
> There's no reason to contort your code around something that should automatically happen.
Absolutely, but it's a question of style at that point. "Contorting your code" suggests using a less desirable style/syntax for some gain, and I'd agree would be premature optimisation. If you're just making a choice between two styles that you consider to be pretty much equal then it's just pragmatic.
edit: Forgot to add, yes, I agree that this should happen automatically in the compiler :)
Fortran functions have always (since Fortran II anyway) used named result values; so did Pascal. Since you can now pick the name of the result value variable in Fortran, I find it a useful convention to just always put RESULT(RESULT) on my functions.
Earlier quoted context omitted.
> Make this function 30 lines long, take 6 arguments and then you have my original argument. It creates context sensitivity, something Golang tries not to do. But like I said before, you're blaming unclear code on the language rather than the developer. It's an optional feature, so don't use it in inappropriate situations. It's like the whole goto statement argument. Nobody is suggesting we all using goto 's just bec…
> But like I said before, you're blaming unclear code on the language rather than the developer. It's an optional feature, so don't use it in inappropriate situations. There's a 30 line function claimed to be a refactor of production code in the article we are discussing. It's not my whole cloth example. Heck, my first post was commenting on the structure of that very function hoping it was a defactoring example. Peo…
Like all language features, you're always going to get some individuals who will misuse them. The author there I definitely think is misusing named returns for something that really needs to be optimised in the compiler instead.
Earlier quoted context omitted.
> But like I said before, you're blaming unclear code on the language rather than the developer. It's an optional feature, so don't use it in inappropriate situations. There's a 30 line function claimed to be a refactor of production code in the article we are discussing. It's not my whole cloth example. Heck, my first post was commenting on the structure of that very function hoping it was a defactoring example. Peo…
Yeah, the article wasn't great. I think few supporters of named returns would even agree with that article. Like all language features, you're always going to get some individuals who will misuse them. The author there I definitely think is misusing named returns for something that really needs to be optimised in the compiler instead.
So I could see how things like having a alternative-providing validator chain take 5% fewer characters would feel intoxicating after using code generation to stamp out four variants of a competent data structure for some primitive types.
Earlier quoted context omitted.
The constraints are important. They're what let you code safely, and also give the compiler the ability to optimize better.
Not sure those optimisations are worth much. And it's only safety by forcing lowest common denominator code and making you justify everything to a dumb compiler. Rust serves a niche, but it is a tight niche IMO.
Aliasing info is, fundamentally, what allows Rust to have memory safety without GC.
Earlier quoted context omitted.
How can you be sure that the other threads ever see it in time? they might be suspended for a whole second because a HDD needs to spin up or something like that. So threads never seeing the value is already a valid outcome, so the compiler might as well always do that.
time.Sleep(1000) could be replaced with a real syncing mechanism of some kind -- it's only for illustration.
Earlier quoted context omitted.
"Are they actually frowned upon? I've been writing Go for a few years now and while I acknowledge there will be blind spots in my knowledge, this is still the first I've heard against using that language feature." /r/golang consensus is against using named values. I disagree with it, but the consensus is there. Or at least I think that at the very least named return values should indicate that someone is doing someth…
> /r/golang consensus is against using named values. /r/golang is a toxic subreddit and I wouldn't take anything said there for face value. Dave Cheney deleted his account there and the go team itself wanted to delete that subreddit. So no, /r/golang represents only /r/golang and certainly not the go community as a whole. /r/golang favorite pass time is to take some piece of code or a library and humiliate its author…