My take on Go: http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-in...
I still use it but I also have a love, hate relationship with it.
I Love Go; I Hate Go
151–160 of 329 posts
Re: I Love Go; I Hate Go
#152Earlier quoted context omitted.
> Stockholm syndrome in action. That's a very negative way of saying "that's not my personal behavioral preference" > There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter. Many of Go's idiosyncrasies are for code readability and maintainability, which is very much a part of active development. The point being to mitigate the likelihood you end up with spaghett…
>> Stockholm syndrome in action. >That's a very negative way of saying "that's not my personal behavioral preference" In my experience, Stockholm syndrome is not used to describe personal behavioral preferences, but rather (unexpected) transitions between such preferences from the negative to the positive. In the grandparent's own words: >>> i was shocked by that at first too. Then I came to love it.
Yes, but it requires that the victim has no way out. Stockholm syndrome is not just any unexpected change of preferences.
Re: I Love Go; I Hate Go
#153Earlier quoted context omitted.
> Except it does though, since that's the very behaviour you're complaining about. No, the meaning was: if someone cannot handle unused things, that someone is screwed. Go will not save him in other aspects which require a little bit of discipline and are not checked by the compiler.
> if someone cannot handle unused things, that someone is screwed. So what you're saying is, there are two kinds of people—those who don't need the feature, and those for whom the feature isn't sufficient?
User laumars was apparently misinterpreting part of a comment by saying that "unused" errors (not warnings, but errors) would in fact save the hypothetical "someone" that was claimed to be not disciplined enough to remove unused imports at release time. But the parent comment was in fact saying that the disability to handle something as simple as unused imports would prevent said programmer to accomplish the less trivial things that programmers are expected to do and for which no tools is a substitute for.
My personal view on this is that warning the user should be enough. The compiler designer is basically saying: I can't trust developers to fix warnings and it is my duty to protect them from their own laziness by enforcing a certain way of working. This apparently attracts a certain kind of people. I prefer to be the one telling the compiler what to do, instead of the reverse.
Re: I Love Go; I Hate Go
#154Earlier quoted context omitted.
>>But it, and, more importantly, the use requirement for variables, has saved me from bugs repeatedly; So how is it better than C where you get a warning (at least from GCC) that you have unused variables? You can quickly test things and you are coming back to fix all the warnings later anyway.
You get warnings for lots of things in C. There's no getting around the use requirement in Go, at least not without crudding up your code.
I prefer what I do with Python in this regard: The IDE shows me unused variables, I can run my code with them, but I can't commit since the linting hook will produce a hard error at commit-time if something's wrong.
It's not as easy to do with a compiled language, of course, but I don't think it would be over the top to have the compiler exit with a non-success code if there are warnings when building.
The "warning fatigue" you get from C is because the warnings are either about false positives or about things that are too trivial to bother with, not because of a property inherent in compiler warnings themselves.
Re: I Love Go; I Hate Go
#155Earlier quoted context omitted.
It's because it's the wrong data-structure for the job. A slice is not sparse. If you need to delete from the middle of an ordered collection of items then it's better to use a linked or doubly-linked list (unless it's small then it doesn't matter).
> It's because it's the wrong data-structure for the job. A slice is not sparse. So? > If you need to delete from the middle of an ordered collection of items then it's better to use a linked or doubly-linked list (unless it's small then it doesn't matter). Meh. Deleting from the middle of an array is one memmove, you don't get 1~2 pointers memory overhead, caches blown and having to deref' n pointers getting to the…
You don't want to memmove an array which content is shared by another array, which is what slices are about.
Re: I Love Go; I Hate Go
#156Why not just use Java? Is faster, have better tooling.
Re: I Love Go; I Hate Go
#157The most frustrating thing for me, by far, is that Go won't let you import unused packages. When you are commenting stuff out to debug a program, or adding debug statements and removing them later, it constantly requires you to go back to the top of the file and comment out the unused libraries, only to uncomment them later when you've solved your problem. The fact that there is not a compiler flag to disable this be…
It's a simple reflection of the fact that the Go creators have never used a modern IDE.
Anyone using a modern IDE pretty much never even thinks about imports, which are (and should be) automatically managed by the tool, not by the programmer.
Re: I Love Go; I Hate Go
#158Earlier quoted context omitted.
Devil's advocate: if you can disable -Werror, then users will disable -Werror, and we'll end up in a C-like situation where everything warns all the time, and real problems get buried. Better to inflict some pain during development if it keeps the Go source corpus hygienic. One under-appreciated consequence is that this policy limits Go to one implementation. Say I write an alternative implementation of Go, that has…
> Devil's advocate: if you can disable -Werror, then users will disable -Werror, and we'll end up in a C-like situation where everything warns all the time, and real problems get buried. I already mentioned that case. To be more clear: Let it not build with default options. Make it not `go get`able. Let me develop first, and not force me to optimize prematurely.
> Let me develop first, and not force me to optimize prematurely.
I'd argue that cleaning unused code as you work isn't optimisation. It's a part of the refactoring process of development which is something that must happen during the main development phase.
But arguments for and against aside, most developers don't see these kinds of compiler errors that often as you'd generally be commenting out unwanted code while you're prototyping. The biggest annoyance is easily the imports and pragmatically that still takes up such an insignificant amount of effort when compared with the overall time spent writing code in any particular language. Which is why many Go advocates are willing to put up with it.
Re: I Love Go; I Hate Go
#159My favorite little annoyance with Go is the way the := operator behaves with multiple assignment. It declares a new variable if there is no variable of that name in the current scope. But it refuses to do that if there are struct fields involved.
var t int
t, err := someFunc() // that's fine
var s struct{ x int }
s.x, err := someFunc() // doesn't compileRe: I Love Go; I Hate Go
#160I like Go quite a lot. Mainly I am a Lisp programmer, so I am not looking for the next most high level programming language. I am looking for a language which gets things done, where Lisp doesn't quite fit. For jobs, which traditionally would have been done in C. Programs that run fast and have a reasonable complexity. It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system. On top of that it adds memory safetey due to the presence of GC.
Go it easy to learn, as its a moderately sized language, but it has just enough abstractions, that your programs are not held back by the lack of those, without opening the traps too "powerful" languages bring with themselves, namely complexety.
On top of all, the whole infrastructure is very well thought out and a pleasure to use. A very fast compiler which produces static executables, a good module system without header files, a rich standard library, many things. There are quite a few quirks, especially for the beginner, but the more I gain insight, the more I agree with the choices made - with some I don't, but the agree to disagree ratio is surprisingly high. And most of them don't get into the way of writing good programs, which is what counts.