TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

What Golang Is and Is Not

168 pointsby elrodeoover 8 years ago

16 comments

codygmanover 8 years ago
As someone who writes Go every day for work, I can&#x27;t agree that Go is simple. Using a language for analytics without generics can be quite painful and error prone.<p>Go is a language that pushes remembering corner cases and failure conditions onto the programmer rather than the language and runtime itself.<p>When you already have to remember a myriad of corner cases for business logic, also remembering so many corner cases for your code hurts productivity.<p>I also believe that languages exist to make getting to an end result in given domains easier. Go does not make my life easier.<p>I really hope it gets generics. I wish it would do away with nil&#x2F;null.<p>Nim is a very good language that actually accomplishes the simplicity Go wanted imo.<p>Go affords simplicity to the Go compiler writers at the cost of burdening Go users with having to remember inane things.
评论 #12331803 未加载
评论 #12333214 未加载
评论 #12331606 未加载
评论 #12332307 未加载
评论 #12331885 未加载
评论 #12333149 未加载
评论 #12342909 未加载
评论 #12332190 未加载
jksmithover 8 years ago
What we like to keep missing is that golang innovates not as a language, but as a tool to contribute to software project success.<p>Project success in the software industry is abysmal, and we still keep thinking we can spin up another language that will contribute to project success because it let&#x27;s us express ourselves in new ways. Well, how&#x27;s that working out so far?<p>The reason why golang appears to have such wide adoption in such a short period of time is that it really does seem to contribute to helping devs get their shit done. Massive amounts of working code are being written in golang, and that&#x27;s good for the software industry as a whole.<p>Currently I run a massive project written in the standard issue kitchen sink corporate language (C#). It&#x27;s got generics, functional extensions, all kinds of shit to make the most discriminating programmer happy. Well guess what, IMO C# for all it&#x27;s features still doesn&#x27;t serve the business of software dev as well as golang because it doesn&#x27;t pull off what golang is brilliant at (easy to code for wide range of skill levels, easy to mentor, easy to test, easy to hire for). The result is difficulty finding productive devs, and a code base that is not up to my preferred quality standards.<p>This may be hard to swallow, but it might really be the case that you can get more quality work done with more devs if toolchain simplicity is emphasized over language features. If the evidence continues to bear this out for golang, then it&#x27;s time for me to shed some language biases just so I can remain competitive.
评论 #12332308 未加载
评论 #12332435 未加载
评论 #12332944 未加载
评论 #12332259 未加载
评论 #12342636 未加载
bad_userover 8 years ago
As some people like to point out, I&#x27;d also like to remind that in 1968 Algol had:<p><pre><code> - user defined record types - user defined sum types - switch&#x2F;case statement with support for sum types - unified syntax for value and reference types - closures with lexical scoping - parallelism support - multi-pass compilation </code></pre> Given that many mainstream languages don&#x27;t offer even what Algo68 had, I personally understand how a Go developer might thing that &quot;nothing is new under the sun&quot; since the 80&#x27;s. After all, Go ignores all progress in programming languages for the last 40 years.<p>I recommend watching &quot;Growing a Language&quot;, a legendary presentation by Guy Steele: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=_ahvzDzKdB0" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=_ahvzDzKdB0</a><p>I do love the attempts of Go developers to rationalize Go&#x27;s choices. But in the end it will end up being a hated language, universally recognized as a net negative in the industry. But that won&#x27;t stop the working programmer from doing the same mistake again and again.
评论 #12332926 未加载
评论 #12342742 未加载
评论 #12333640 未加载
评论 #12332217 未加载
sergiotapiaover 8 years ago
The author is quite correct. Go is super boring, and runs fast. Two great points for it.<p>For me however I just never felt happy writing Go code. I have a couple of open source projects with it, so I have put it through it&#x27;s initial paces to see if we fit.<p>The language that did make me happy was Elixir. Everything about the language and the surrounding tooling is polished. You end up with significantly less lines of code that&#x27;s easy to understand.<p>Here&#x27;s just one example from me - both examples scrape some info from HTML:<p>Elixir: <a href="https:&#x2F;&#x2F;github.com&#x2F;sergiotapia&#x2F;magnetissimo&#x2F;blob&#x2F;master&#x2F;lib&#x2F;parsers&#x2F;demonoid.ex#L36" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;sergiotapia&#x2F;magnetissimo&#x2F;blob&#x2F;master&#x2F;lib&#x2F;...</a><p>Go: <a href="https:&#x2F;&#x2F;github.com&#x2F;sergiotapia&#x2F;gophers&#x2F;blob&#x2F;master&#x2F;scrape.go#L39" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;sergiotapia&#x2F;gophers&#x2F;blob&#x2F;master&#x2F;scrape.go...</a><p>You tell me which one is nicer to look at and easier to understand.
评论 #12332114 未加载
评论 #12331557 未加载
评论 #12331479 未加载
评论 #12331383 未加载
评论 #12331291 未加载
评论 #12332991 未加载
junkeover 8 years ago
So, Go is designed to be an engineering language and not an academic toy. Contrary to other languages, Go programmers &quot;deliver&quot; and have a pragmatic view of the <i>real</i> development world, not just their own commits. Go programmers need a deeper understanding of computer science because other programmers are lazy and have everything given for free and probably don&#x27;t need to know how it works.<p>A whole page discussing the virtues of Go by insulting people.
评论 #12331402 未加载
评论 #12384518 未加载
评论 #12333682 未加载
tux1968over 8 years ago
The article mentions a keynote speech by Rob Pike* from 2012 which is quite illuminating. The trade-offs made were all centered around google-scale and the pain points of such a massive operation. It stands to reason that people working outside of that environment may be less pleased with the language.<p>[*] <a href="https:&#x2F;&#x2F;www.infoq.com&#x2F;presentations&#x2F;Go-Google" rel="nofollow">https:&#x2F;&#x2F;www.infoq.com&#x2F;presentations&#x2F;Go-Google</a>
评论 #12333017 未加载
评论 #12384450 未加载
p0nceover 8 years ago
&gt; To provide any solution in Go that needs a dynamic data structure you can choose between hand rolled linked structures or a Slice or Map (or compose with them). As they are quite different the choice is normally obvious. Contrast this to the choice between map, set, hashset, bag etc etc, or rolling your own in a language that makes this a lot harder.<p>I can&#x27;t help but think the whole article is filled with bursts of dishonesty.<p>A language like C++, which let you use the proper data-structure in about two lines of code, is <i>a lot easier</i> when it comes to data-structures. While the Go programmer implements a multi-map, priority-queue or red-black tree, anyone else will have moved on to an actual topic of interest.<p>If you need a particular data-structure, surely having one ready in the toolbox is a net positive, not a negative.
unsignedqwordover 8 years ago
I&#x27;m not much of a Go programmer but I would definitely regard Go&#x27;s multiple return and error handling (save the &#x27;no assertions&#x27; clause) as very cool. I&#x27;m not sure if any other languages have experimented with that approach before the rise of Go, but to me at least it appears much saner than the prevalent ridiculousness of exception handling.
评论 #12331629 未加载
评论 #12334096 未加载
评论 #12333024 未加载
bpicoloover 8 years ago
&gt; Finally, in certain problem domains the power and flexibility of a hash-map is also unavoidable, therefore Go provides a Map built in<p>Not a fan of this sentence. Why try to make it sound like Maps are unusual or bad? Just as fundamental as the list to real programming.
Myrmornisover 8 years ago
&gt; Custom data structures can be composed from the well understood builtins, rolled in under 100 lines of code and can can exist close to the place they are used (yes repeated!). The effect of this approach on readability, maintainability, decoupling, ... adds so much more value to the whole lifecycle, than the cost of the omission.<p>It&#x27;s interesting to me that this philosophy comes from the Go designers at Google, and that Google is also well known for keeping vast amounts of source code advancing in lock-step in a single repository. From reading the recent article on Google&#x27;s source code repository structure, I believe that being able to reuse code (e.g. data structure implementations) without versioning headaches is one of the intended and actual benefits. It&#x27;s of course not that surprising that two different areas (Go design and repository structure) might pull in two different directions, but these are two important high level issues so it does seem a little inconsistent to me.
SZJXover 8 years ago
&gt; It is not ‘missing’ comprehensions, or inheritance, or generics, they are omitted (and I pray, always will be). In some way, in the context of the current fashion of returning to more functional languages, or the evolution of good old languages to include more functional paradigms (I’m looking at you Javascript and Python for two examples) then in a tenuous convoluted way Go has ‘innovated’ by avoiding that trend.<p>That&#x27;s such a weird statement. If anything, those are likely more OOP-related than FP-related, and he didn&#x27;t really point out what&#x27;s so bad about &quot;more functional paradigms&quot;, besides the implication that it might be harder for new hires to pick up etc.<p>Anyways, I see that Go reduces the learning curve and simplifies lifecycle of huge projects, but at considerable costs about language features and expressiveness. I myself if working as a developer would rather not bear those costs just for the sake of the whole clogs of the organization running a bit more smoothly, and also so that myself would not just program day-in day-out en masse with everybody else out there in an overly simplified language that potentially puts me at more of a disadvantage in my career path. Maybe the leaders of huge companies would have other thoughts and there will definitely be developers who are happy to fill those roles, it&#x27;s just not me.
bluejekyllover 8 years ago
&gt; “There is nothing new under the sun” rings true in all languages since the 80’s.<p>Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it&#x27;s not simple like Go.<p>Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to check an error result. This is a runtime thing you need to discover. Is this actually simpler?<p>Go made the decision to allow for Null, even after nearly every other modern language and other older ones are trying to kick it to the curb; Swift, Rust, Scala, Kotlin, no nulls (the JVM ones have a compatability problem, as does swift with ObjC, but still). Is it simpler to delay discovery of Null data to runtime?<p>Go decided to not have generics, to keep the language easier to learn and more approachable. It&#x27;s hard to argue with this one. Like lambdas, it can be a complicated concept to learn, but once you unlock this in you code, you write less code and accomplish more. So yes, it&#x27;s simpler, but at too high a cost IMO.<p>To me the innovative feature of Go is the small runtime built into the binary making deployment dead simple and easy. This is a million times better than JVM, Ruby, Python, Perl, etc. This is a huge improvement over Java, and something every language should have an option for. Ironically this is also the least innovative feature, because this is how static binaries in C and C++ have worked for years.<p>I think this article is very well written, but I don&#x27;t think it&#x27;s fair to the innovation going on in other languages.<p>(Disclaimer: I used Go, discovered the three primary flaws as I listed above, and then searched for a better language. It would be fair to call me a hater, usually I try to avoid this, but in this case that&#x27;s fine with me)
评论 #12331311 未加载
评论 #12331313 未加载
评论 #12342823 未加载
评论 #12331478 未加载
评论 #12331370 未加载
评论 #12331482 未加载
评论 #12332002 未加载
评论 #12331338 未加载
评论 #12331679 未加载
评论 #12331377 未加载
danmuxover 8 years ago
The irony in all of these comments is that they almost all fall back to, or start with, discussing language design, and on the whole ignore the tools and processes that have a consistency from Go team to Go team. The value of this power and consistency is probably overlooked in this and many other conversations because they are complex to discuss, and it is simply easier to focus on the almost provable value of the language features, missing or present (maybe another availability bias at work?). The point of the article was to try and refocus on Go as an engineering tool in a much broader context.
knucklesandwichover 8 years ago
Accusing other languages of suffering from paralysis of choice and fragmentation and offering &quot;go get&quot; as an example of solving this is truly ironic: <a href="https:&#x2F;&#x2F;github.com&#x2F;avelino&#x2F;awesome-go#package-management" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;avelino&#x2F;awesome-go#package-management</a>
评论 #12332188 未加载
scriptproofover 8 years ago
If you make a program that is executed a million of times or more a day, it make sense to have a language that is &quot;near the CPU&quot;, and allows to optimize and speed up the most. This is what Go is. It will be a mistake to use it elsewhere.
评论 #12331273 未加载
评论 #12331255 未加载
behnamohover 8 years ago
I&#x27;m not a Golang programmer, but the mere fact that GOOG decided Java for android is convincing enough that even GOOG does not believe in its Go.<p>(Frankly, I doubted that a little, until I realized Al-*-Go was not actually written in Go!)
评论 #12332746 未加载
评论 #12332605 未加载