"Throw caution to the garbage collector" -- my new favorite phrase.
Four days of Go
61–70 of 187 posts
Re: Four days of Go
#62Two things stick out:
Catching unused variables is pretty essential, it's easy to shoot yourself in the foot by redeclaring a variable with := inside a block.
>> which means you have to need separate storage for the actual RaceCar and GetawayCar values, either on the stack with a temporary variable or on the heap with calls to new
Maybe I miss his point here, but in Go it's totally valid to just create a new *GetawayCar with &GetawayCar{} in any scope. You can return that pointer from your current method. It's not necessary to explicitly put your GetawayCar on the heap with new(), Go will decide for you with escape analysis.
Re: Four days of Go
#63In other words, Go represents a kind of Machiavellian power play, orchestrated by slow-and-careful programmers who are tired of suffering for the sins of fast-and-loose programmers. The Go documentation refers quite often to intolerable 45-minute build times suffered by the original designers, and I can’t help but imagine them sitting around and seething about all those unused imports from those “other” programmers,…
Sounds wonderful to me!
Re: Four days of Go
#64no ternary is a smart move tho. makes code more readable for all skill levels.
It's just syntactic sugar for if-else though, so it's right in the sweet spot of "doesn't make a big difference either way" and "is subject to preference" that makes it a prime target for bikeshedding. Personally I don't like the ternaries either, typically the syntax is ugly, but the if-else seems only slightly better to me.
Re: Four days of Go
#65From the article:
In order to do evil things like convert raw bytes to floats,
I chose to use the “unsafe” package
Re: Four days of Go
#66In other words, Go represents a kind of Machiavellian power play, orchestrated by slow-and-careful programmers who are tired of suffering for the sins of fast-and-loose programmers. The Go documentation refers quite often to intolerable 45-minute build times suffered by the original designers, and I can’t help but imagine them sitting around and seething about all those unused imports from those “other” programmers,…
I think this is part of it, some of the hate comes from people that "know better" (possibly true for some, obviously the Go authors aren't omnipotent) than the Go language designers and are baffled that the language design ideas they know about aren't in the language. But I can tell you in my experience that this type of forceful "everything is a error, no warnings" and "it is done this way (formatting for instance)"…
In before "but adding generics does not make team projects harder, look at language ..."
Your (and many other people's) insistence on dismissing discussion regarding generics as some kind of a joke is anti-intellectual. You're rejecting valid criticism of your arguments on the basis that the critic's argument is unworthy of attention for some reason external to the discussion at hand.
I agree that pro-generics arguments are usually boring, and at least 90% of what they say has been heard before. But the same can be said of Go evangelism, like your comment; they are no less worthy. Please don't deliberately shut down discussion.
Re: Four days of Go
#67Educational and entertaining as always Evan, I would love to see a similar writeup on Elixir. Maybe a Chicago Boss port is in order ;)
Re: Four days of Go
#68Earlier quoted context omitted.
I think this is part of it, some of the hate comes from people that "know better" (possibly true for some, obviously the Go authors aren't omnipotent) than the Go language designers and are baffled that the language design ideas they know about aren't in the language. But I can tell you in my experience that this type of forceful "everything is a error, no warnings" and "it is done this way (formatting for instance)"…
> Go makes coordinating with them a lot easier. What I like about strongly opinionated languages in general is that most of the strong opinions are around trivial features of the languages relative to the complexity of a decently interesting programming problem. Features like formatting, no unused imports, etc. These are typically areas in a project where Parkinson's Law of Triviality rears its ugly head in project p…
I agree with a lot of these (and would be interested in adopting a language that followed them - but one with a decent type system), but I don't think that's the Go innovation. Python had opinions about whitespace and never attracted the same level of hate.
Re: Four days of Go
#69no ternary is a smart move tho. makes code more readable for all skill levels.
It's just syntactic sugar for if-else though, so it's right in the sweet spot of "doesn't make a big difference either way" and "is subject to preference" that makes it a prime target for bikeshedding. Personally I don't like the ternaries either, typically the syntax is ugly, but the if-else seems only slightly better to me.
Here's how you should use ternary:
return (isblue ? "Blue" : "Red");Re: Four days of Go
#70>Reading Go’s mailing list and documentation, I get a similar sense of refusal-to-engage — the authors are communicative, to be sure, but in a didactic way. They seem tired of hearing people’s ideas, as if they’ve already thought of everything, and the relative success of Go at Google and elsewhere has only led them to turn the volume knob down. Which is a shame, because they’ll probably miss out on some good ideas
This captures my sentiments and experiences with the language perfectly.