> it’s not foreach from C++.
Ah the penny drops. We have a whiny C++ programmer on our hands.
Problems with Go's design
41–50 of 88 posts
Re: Problems with Go's design
#42I actually had a subtle bug caused by variable shadowing. The current behaviour of := is error prone and IMO should be revisited. The situations where it cleans things up are offset by situations where it doesn't work (including in compound statements where it often ends up being I'd like to declare and check err but I also want to be able to use the other variable if err==nil). Another thing not mentioned is type sw…
The behaviour you are talking about isn't anything to do with :=. It's just how scoping works in Go. := is just syntactic sugar. http://play.golang.org/p/bh6pm_8s9S
Probably the root of the issue is that it's slightly more complicated than syntactic sugar:
"Unlike regular variable declarations, a short variable declaration may redeclare variables provided they were originally declared earlier in the same block (or the parameter lists if the block is the function body) with the same type, and at least one of the non-blank variables is new. As a consequence, redeclaration can only appear in a multi-variable short declaration. Redeclaration does not introduce a new variable; it just assigns a new value to the original."
I.e. the mix of declaration with re-declaration. I agree it doesn't seem like much but it ends up causing needless confusion. If there was a more explict way of doing this, e.g.:
x, var y = 1, 2 // y explicitly declared
maybe that would be better. not sure.
Re: Problems with Go's design
#43FUD
Re: Problems with Go's design
#44Meh. 1. How often do you insert into a slice? You know that's a O(n) operation, right? 2. nil is typed, I'll grant that it's not the most obvious part of Go's type system. 3. Meh. 4. This is type covariance. It's complicated and hard to get right. The Java Generics FAQ looks like this: http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.ht... 5. I like by-value loops. Everything else in Go is by-value. 6. Yeah,…
This sums up my opinion on this pretty well.
On 1 I'll just say it'd be nice if append (and other varargs functions) could take multiple of individually listed and slice-expanded args at the same time. As in: `append(a[:2], 3, a[2:]...)`. I already expect append to be O(n), and this would be some very nice sugar.
Re: Problems with Go's design
#45I'm surprised to see the author mention not being able to compile when there are unused imports. Editor plugins that call goimports have solved this problem for a long time now. For example, I use vim-go ( https://github.com/fatih/vim-go ), and if I remove the only line of code that references the "fmt" package, the "fmt" import line at the top of the file will automatically be removed. Edit: Here is the reasoning on…
Cool package, but it looks like it doesnt exist for TextMate
Re: Problems with Go's design
#46Earlier quoted context omitted.
Dang, I think you're too aggressive with article renames. The author claims that Go is poorly designed. And that's the title of the article. Yes, it's a provocative opinion (and the article text is loud), but the title itself was not outrageous hyperbole. I disagree with other commenters here: just because a controversial opinion will (naturally) gather more clicks, doesn't mean it's linkbait. The articles here on HN…
You may not think this was linkbait, but I guarantee you that if this article were on HN's front page with that title, the thread would become about the title. All you need to do is look at the comments that were posted before we changed it. Your objection is really to HN's title policy. In my view that policy is a critical aspect of this site—indeed the longer I work on HN the more critical it seems. So I have to di…
Well, it looks like my only recourse is to mount an aggressive campaign to be the new HN moderator, take you down, restore the original titles, and eventually get run out due to various lurid scandals involving clickbots.
Thanks anyway for the reply :-)
Re: Problems with Go's design
#47Earlier quoted context omitted.
That's not type covariance. Variance only comes up when you have generics, which Go doesn't, and subtyping, which Go doesn't really have. It's the lack of a coercion/conversion between slice-of-T to slice-of-interface. The correct language-level solution to #4 is to introduce generics and to allow generic type parameters to have interface bounds. That would solve the problem without having to introduce variance.
Isn't it possible to talk about variance as soon as you have a type constructor (function from types to types)? In this case []. Edit: I don't know go, but if slices give write access, I think the automatic conversion the author wants would be unsound.
Yes, a coercion would be unsound (at least, unless the coercion copied the backing store of the slice, which would be very unintuitive). It shouldn't coerce. I'm describing generic type parameter bounds, which are not the same thing.
(For what it's worth, I'm not sure I would bother solving this problem if I were suddenly put in charge of Go's design, given Go's extreme aversion to type system features. I'm just describing what the solution to this problem typically is.)
Re: Problems with Go's design
#48I've been bitten by #5 quite bad. Ranged over N elements in my slice, took the addresses of the values, copied to new slice. Ended up with a slice with N identical values. !?!?!? Took me about 30 mins of staring, printfing and whatnot before I understood what was going on (the loop variable containing the copies is mutable so you end up with pointers to it throughout the whole new slice. And at the end the value of it is the last element in the range. So I saw N*the last element when printing the result).
Re: Problems with Go's design
#49I worked on a project with go, and initially i liked it. Because the new way of thinking, and the fast compiler.
But both the error checking, missing of generics, and missing of real functional programming paradigmas, required me to write something very simple in a complex way.
I concluded that a simple webapp, is better written in python, and go was not the way togo for my project. In python you can quickly generate json from objects (yeah you can in go but only with ugly string comments). All in all, go has its place, but when you start a new startup, watch out with go initially.
Re: Problems with Go's design
#50I think author of this article is strangely biased towards dynamic languages. Go is not about shortest programs in the worlds, yes sometimes code is longer than in python. But in Go I can manage code execution and predict memory easier better than in Python or other dynamic languages. Many things in Go were done on purpose. Learn to use Go and it's awesome tools, like gofmt, goimports and others.
I love Python, up until I remember that I can't make any guarantees of program correctness until I have 100% coverage tests on every line of code because the language is so flexible that it can't tell if a random identifier refers to a variable name that might exist at runtime (but is not determinable to exist at compile time), and therefore most of my variable-name typos that would be compile-time errors in another…
Indeed, with python i can program fastest, but whenever something gets big you had wished i programmed it in golang. However, its still a valid choice to choose python initially. It depends