351–360 of 402 posts
Question: who is going to remember all these conversion rules? By the second bullet you lost me. Simply run the command below: go tool fix -diff -force=context state-of-go/tools/gofix.go How is typing 59 characters simple?
And 32 characters is not much longer than, say: python manage.py makemigrations
i love languages and i am enjoying seeing Go mature as a language. At the moment I do have my hands tied with Elm and Haskell. Originally I am a Python programmer. Any advice for people transitioning for Python? What are some of the advantages of Go?
Earlier quoted context omitted.
OK. I should have said, it's not inherently a criticism, it's just a fact. That others may choose to use it as a criticism--well, that's upto them. Personally I don't think there's such a thing as a 'mediocre' programmer, I think there are programmers who have studied and trained in concepts, techniques and idioms and those who haven't. It seems pretty clear from that quote that Google is hiring kids fresh out of col…
> I think there are programmers who have studied and trained in concepts, techniques and idioms and those who haven't Which is really just talking in circles, because as I've now said in three consecutive comments, I have quite extensive experience with functional programming, and so I'm rejecting the argument that Go is simply for people who don't have that experience. > And in fact, I also don't see how you can der…
You may reject it, but the fact remains that that was explicitly one of their design goals when creating Go.
> ... a single quotation cited on a blog post written by someone who (by his own admission) is very new to the language.
A quotation is a quotation; either Rob Pike said those words or he didn't. Who cited the quotation doesn't make a difference.
Earlier quoted context omitted.
Nah. I like Go because the language itself is minimal yet powerful, and because the quality of engineering is extremely high. I am so tired of having to deal with bullshit because of poorly-thought-out and poorly-engineered tools; Go minimizes that. An excellent example is the handling of this bug report(§): https://github.com/golang/go/issues/12914 which resulted in this language-change proposal: https://github.com/…
I am so tired of having to deal with bullshit because of poorly-thought-out and poorly-engineered tools Seems to be some cognitive dissonance (in the modern erroneous sense of the word) going on. This was a hack necessary because the design of the library wasn't fully thought out. Imagining the world would one day become Google is not thinking things out.
And that's just an example that was intended to illustrative.
You'll just have to take my word for it that my experience of the Go ecosystem, tools, and standard library has been more solid than the various other things I've used over the years (python, C# + unity, c++, fucking maven, boost...).
If I'm missing out on something even better, let me know. ;-)
Earlier quoted context omitted.
Terseness doesn't necessarily bring clarity.
It's the recognizability, not the terseness, that brings clarity. Although Python's approach is not terse -- `fstyle = [f(x) for x in arr]` -- it is eminently recognizable. Your argument is not really about anything I specifically said; and without something to counterbalance, it argues against structured programming, too.
My argument is that "recognizability" is in the eye of the beholder. One programmer's "map is a powerful abstraction over transforms, for example loops" is another's "this is some cutesy code/math creole by a CS graduate who desperately wants to find nails to apply his functional programming and applied math hammer on".
That's a fairly harsh way of saying that at some point the abstraction isn't clarifying, whether it's recognizable or not.
Disclaimer: I'm a big fan of functional idioms (they're one of my favorite parts of Rust, for example). I'm not so much a big fan of absolutism or over-generalization.
Earlier quoted context omitted.
What is the first class integration? My experience using Ruby, Python and Rust (via Racer) with Vim+Syntastic has been pretty good.
In my Emacs I've got 1) eldoc (displaying signature of function at point), 2) function source lookup, 3) function documentation lookup, 4) flycheck (display compiler err/warn on save), 5) auto-completion. Among a few other things like go-guru integration which I haven't used much yet but I can see its use. All of those features come from editor agnostic golang tools.
In Emacs too. I'd hardly say this is a unique selling point of Go.
Earlier quoted context omitted.
What is the first class integration? My experience using Ruby, Python and Rust (via Racer) with Vim+Syntastic has been pretty good.
IDE functionality, similar to what godef/guru for Golang offer. But I'd settle on any mostly working jump-to-definition tool for Ruby/Python/Java that can be integrated with Vim/Emacs.
Earlier quoted context omitted.
But Go really does encourage good practices. I came to Go after programming in C, C++, Java and a bunch of dynamically typed languages. After a couple of years with Go I returned to C (and a bit to Java). And I'm writing better code in those languages now. Now, part of it is natural progress probably. But especially when I'm writing C, I can tell that I'm writing it much better than before because I'm adopting back s…
i think a couple of years of experience and learning a new language .. was a far bigger factor than any intrinsict characteristics of go
Earlier quoted context omitted.
The loop and map are equally readable, it is just that some people are used to one form more then the other. More importantly, how many character needs to be used for simple idiom like that has zero influence on how maintainable your system is going to be few months later on, how fast it is and so on. The difference between loop and map wont make you do less or more bugs. It may make you read the code few seconds lon…
Functions are trivially composable, while imperative loops are not. The difference that makes in terms of maintainability and readability of non-trivial applications is hard to overstate. Writing code in terms of small, composable, reusable functions with a clear single intent (through good naming), that you can then mix, match, and reuse to compose into larger functions is what makes good functional code so much eas…
Absolute, that holds for non functional code as well.
It just does not matter whether the smallest function inside that system of functions has a loop or a map inside it. Loops are as easy to tuck into reusable functions as maps or anything else. Notably examples in the presentation you link have functional version shorter, but harder to read - they have more features however. Even the first one pipe(..., reduce(add, 0)) just does not read fluently.
But again, this low level has very little influence on maintainability of the larger program. In anything that is not computational library, how you compose them matters more. It is as if you assumed code with loops can not be split into smaller composable units.
I worked with codebase written in largely functional style. It was hard to read at first, but then I got used to it. However, it never became all that much easier to read them loops nor easier to work with. It gets bad when people get clever with composing functions.
Earlier quoted context omitted.
Given Pike's extensive experience inside a world of his own making (Plan 9 and Go), it's entirely reasonable to attribute the misconception that Go is a system language to Pike's idiosyncratic use of the phrase. If I understand things correctly, Go came about as fallout related to the non-scalability of Python and the massive technical debt associated with Python within Google. The projects to automagically port Pyth…
Actually, Go was born out of a desire to make something better than c++ for google scale and style use. https://commandcenter.blogspot.it/2012/06/less-is-exponentia... It just happens that Go is a better replacement for python than c++ in the general case.