20 ms·

Why I Don't Like Golang (2016)

296 points by Danieru 7y ago

mavelikara 7y ago
(2016)
- dang 7y ago
  Added. Thanks!
_bxg1 7y ago
Unrelated thoughts: > Structs do not explicitly declare which interfaces they implement. This is done implicitly by matching the method signatures. This design makes a fundamental error: It assumes that if two methods have the same signature, then they have the same contract. Isn't this just duck typing? Don't other languages renowned for their type systems do this? > There’s no ternary (?:) operator. Every C-like language has had this, and I miss it every day that I program in Go. The language is removing functional idioms right when everyone is agreeing that these are useful. Expressive if/else is much more readable. Of course if Go doesn't have that, removing the ternary operator is a bad call. > The tried and true approach of providing a compare method works great and has none of these drawbacks. Hmm... except in anonymous cases. This author clearly has some Java stockholm syndrome. > The append() function modifies the array in-place when it can, and only returns a different array if it has no place left. That's horrifying.
- networkimprov 7y ago
  My one-line workaround. (Yes, I ban go fmt.) v := a; if t { v = b } Sadly, this doesn't work well if a is a function call :-(
  - _bxg1 7y ago
    Out of curiosity, what's the motivating case for using Go in 2019's programming landscape? Edit: I didn't mean this as an insult, I meant it as a genuine question. I don't know much about the Go ecosystem, and I meant to find out what Go's killer feature is in 2019, when other languages now have strong and elegant concurrency, C-like performance with higher-level syntax and without manual memory management, etc.
    - blablabla123 7y ago
      Writing any type of network server from scratch is quite straight-forward if you know how to do it. Obviously concurrency is also available to the fullest.
    - 886 7y ago
      you make it sound like Go is not top tier in the 2019's programming landscape and there is a good alternative. Can you elaborate?
      - meddlepal 7y ago
        Yes it's called Java.
        dang 7y ago
        Maybe so, but please don't post unsubstantive comments here.
      - bluquark 7y ago
        Kotlin and Swift are both currently encroaching on Go's server-side use cases. For example, Go's star feature, goroutines, has recently been cloned by Kotlin. They are at least as equally pleasant to program in, and they're hitched to major client platforms which means they improve faster and will definitely have a pool of trained developers in the long term.
        apta 7y ago
        Java is getting a fiber implementation by means of project Loom, which will make golang even less appealing. The good thing is that because the fiber implementation will be built into the JVM, Kotlin and other languages can use them seamlessly.
        886 7y ago
        Points taken. I am full time on Go since few years ago and before that I was 100% Java. Haven't really kept myself up-to-date with the Java land. But from my experience with Java, Go, and Python, I find Go a very versatile programming language. Being able to compile binaries means it's great for infrastructure deployments and CLI tools. Goroutines, concurrency, and etc make it a great choice for server/micro service use cases as well. Some can say that not having a JVM is a plus as well. However, developers do have to be disciplined with error handling and dependency management. But one can argue that this is the case for software development in general.
  - holy_city 7y ago
    To be fair that's generally good practice since it eliminates a branch in the code, depending on the type of v and overhead of assignment.
    - DuskStar 7y ago
      Sounds like the sort of thing your compiler should choose for you.
  - DuskStar 7y ago
    Banning go fmt gets rid of one of the best parts of the go ecosystem, and I am horrified that you would do so. go fmt may not be anyone's favorite code style, but having go fmt is so much better than dealing with everyone else's favorite (incompatible!) styles.
    - networkimprov 7y ago
      There is no spec for go fmt. Its behavior has changed across releases. It has no switches to disable features. It destroys many nice single-line constructs, e.g. if err != nil { return err } Much of my code would be painful to read without that one. On the bright side, it artificially inflates your line count, so you appear more productive!
      - DuskStar 7y ago
        I think we're going to have to disagree there, then - yes that oneliner might reduce your LOC count and help you win at code golf, but it doesn't actually make things more readable and certainly isn't worth breaking from the rest of the community. The ecosystem-wide consistency of go fmt is its biggest strength. Adding switches to disable features would eliminate that.
        networkimprov 7y ago
        There is a lot more to effective code style than whitespace, and most Go code I've seen doesn't consider that, including the stdlib. I've put a lot of thought into my style guide, and anyone who hasn't done the same has no useful insight on whether go fmt is a help or a hindrance.
    - _bxg1 7y ago
      > one of the best parts of the go ecosystem Is it more powerful in some way than the auto-formatters that exist for nearly every other language?
      - DuskStar 7y ago
- weberc2 7y ago
  > Isn't this just duck typing? Don't other languages renowned for their type systems do this? It's "structural subtyping", which is the type-safe equivalent of duck typing. It's a feature that allows implementations to exist without needing to know exactly every interface they implement. TFA's concern is purely theoretical. > That's horrifying. append() doesn't operate on arrays, it operates on slices. Arrays are fixed-length, contiguous blocks of memory that can't be appended to. Slices are backed by arrays, and if you append to a slice whose backing array is full, it will "grow" by allocating a bigger array elsewhere and copying the original data into it. This is a pretty standard data structure in most languages.
  - gerbilly 7y ago
    > append() doesn't operate on arrays, it operates on slices. [...] This is a pretty standard data structure in most languages. If you say so. I know I should go read the docs more carefully, but this whole slice thing is confusing to me, and often yields surprises like this. I'm not a big fan of how this was implemented.
    - weberc2 7y ago
      How would you prefer it be implemented?
      - gerbilly 7y ago
        I don't know, I'll go and read up on it more. The feature leaves me 'meh'. I don't find slices as awesome as everyone is always saying, especially without negative indices. I guess part of it it that it isn't always clear to me when you're dealing with a slice, or an array, or whatever. I know, when it's confusing, there's always some reasonable sounding explanation after the fact, sure, but the whole thing feels like a confusing mess.
        Boxxed 7y ago
        Do you know any other systems languages, like C or C++? This kind of thing makes a lot more sense when you have some surrounding context.
- lmm 7y ago
  > Isn't this just duck typing? Yes > Don't other languages renowned for their type systems do this? No. In languages with good type systems, nominal types are very valuable. E.g. "known-immutable list" and "read-only view onto a mutable list" are very different types, but offer the same set of methods.
kstenerud 7y ago
This article is from 2016, but it's still relevant. Even in medium sized projects I've been bitten by many of these issues, and for a language that's supposed to eschew magic, there's an awful lot of wizardry going on. Stopping compilation with an error for every unused import & variable is particularly annoying, so much so that I've patched the go compiler to treat them as warnings instead [1]. Ultimately, I think the problem boils down to a language that outgrew its original design, and hasn't evolved elegantly (yet). [1] https://github.com/kstenerud/go https://github.com/kstenerud/go
- maxaf 7y ago
  Your fork of Go promotes poor code quality. How’s this different from driving a car with an unbuckled seatbelt draped surreptitiously over the shoulder? The feeling of smug superiority must be intoxicating, but the risk of a violent ejection after a crash and subsequent death is still there.
  - macintux 7y ago
    Certainly one difference is this: if I’m developing a one-off tool, or simply in early stages of development, it’s closer to being in a driving simulator with the seatbelt unbuckled. Not every line of code is life or death.
    - solarkraft 7y ago
      To expand on the metaphor: Imagine driving slowly and having to jump out of the car a lot.
      - stcredzero 7y ago
        A new car chassis in development might well get driven around with out a body and windshield attached, slowly around a test track.
  - solarkraft 7y ago
    Does it? In my explorations I had to add bogus operations to variables and imports so the compiler wouldn't explode on me while commenting stuff out.
dang 7y ago
A thread from 2018: https://news.ycombinator.com/item?id=16414098 https://news.ycombinator.com/item?id=16414098 From 2016: https://news.ycombinator.com/item?id=12356823 https://news.ycombinator.com/item?id=12356823
losingthefight 7y ago
I have been using Go in production since 2015 and can honestly say that other than the ternary operator, none of these have been a major issue for me. Granted, I am doing mostly REST API development so my use cases may be different, but I have never had an issue with capitalization or which interfaces are implemented. The tooling is by far some of the best I have used in a language. Paired with a good editor (I personally use VS Code on Ubuntu 18.04 as my main setup) and I have yet to miss exceptions or wonder what my code is capable of doing. That being said, Go isn't perfect by any stretch. Sometimes panic ins Go routines can be very hard to trace. The transition to Go modules is challenging for larger projects with versions beyond 1.x (when I started it was Glide, then dep, now go mod, which has been a bit frustrating). However, I wouldn't go back to Java, C#, PHP, or NodeJS if I had the choice. My go to in the server space is Go and Elixir. I don't feel a desire or need for anything else, but again, that's me. You know your use case better than a stranger on the internet :)
- AlchemistCamp 7y ago
  That's really interesting. How do you use Go with Elixir? I've never really gotten into Go, partially because I feel like there's a lot of overlap with what it does and what Elixir does. I could see using it for CLIs and various Unix scripting, but I've been doing that with Ruby, for the most part. I also considered learning Go for creating some native binaries for a few critical paths, but Rust seems like the best choice for that. A NIF that crashes is one of the few things that will take down the Erlang VM, so Rust's strong safety guarantees (might) make it worth the steep learning curve.
  - Thaxll 7y ago
    For one Elixir is very slow compare to Go.
    - Herrin 7y ago
      For what purpose? See: https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixir/ https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixi...
bborud 7y ago
I'm surprised that someone can use Go for 3 years and still be hung up on the things that most people appear to get over in the first month.
- nkozyra 7y ago
  Well, it's preference. Some people "get over" things, but when there are so many tools at your disposal, why not use the one you like best?
  - bborud 7y ago
    To be fair, in a professional setting that is often not an option when it comes to programming languages. Usually you will have a situation where the language has already been chosen when you join a project. When you start a new project at a company, the language chosen is usually dictated by either what the company uses already or some process for reaching a consensus on what to use. What you don't really want in a professional setting is to use a lot of languages. For a large number of very good reasons. Picking a language involves compromise. I think what I perhaps reacted to were the somewhat superficial nature of the blogger's complaints. Especially when claiming to have done non-trivial projects in Go. Perhaps as a programmer, but it doesn't sound like someone who has lead development and had to make hard decisions. Non-trivial projects usually give you plenty of other things to worry about. For instance how good the language is for collaboration, how easy it is to model things, how clear is the code, how does it make use of the machine resources, will the language still have a following 10 years from now, what does the tooling look like, what quality are the open source contributions, is the standard library usable, do the third party libraries cover enough of what you need? And then there are the developers. You need to be able to recruit developers beyond your circle of friends. You want that pool to be as big as possible. This is why I avoid languages that have too little mainstream appeal. It doesn't help me much if I can hire some Common Lisp guru to build a lovely piece of software if I can't find anyone to maintain it once he or she leaves. Being the one to decide what language to use for a project is a thankless job because you will always disappoint someone. Not everyone will or can take in the larger perspective. As a manager I seriously do not want to hire developers that always want to program in some other language, often one with a small following. Or who want to change languages every 2 years. Because if they can't learn to live with one of a selection of mainstream languages that are "80% okay", why would I think they are any better at dealing with difficulties in other languages? I expect good programmers to adapt practices - to make languages work for them. To be professionals. When we switched from Java to Go in my department it was a team decision. As a manager I let my team decide what to use, HOWEVER, I made it clear that everyone will make an effort to learn whatever is chosen and I don't want any whining or excuses. If they found Go to be the wrong thing, fine, we have Java which is the devil we know to fall back on. But only after everyone has made a real effort. That was 3 years ago. We now have somewhere in the neighborhood of 100kLOC running in AWS and it has been astonishingly productive. Sure there has been _some_ whining about small details, but on the whole adopting Go was surprisingly fast and surprisingly pain free.
altmind 7y ago
There's a good website documenting go quirks: http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/ http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in... Some of the problems are really annoying and artificial such as "declared and not used/unused imports" trying to push golang opinion on code quality
diamondo25 7y ago
Most of the items explained are non-issues and part of why Golang is how it is today. Lets hope we can keep the language as-is and don't go back to old decisions and remove features like Scala have been doing the last years...
- norswap 7y ago
  <reference needed>
  - diamondo25 7y ago
    One of the praised functions in Scala 2.8 was postfix operators, allowing things like: Seq(1, 2) map _ + 100 They are getting rid of it: https://contributors.scala-lang.org/t/lets-drop-postfix-operators/1457 https://contributors.scala-lang.org/t/lets-drop-postfix-oper... Unit functions were a thing, just write: def A() { ... } This is inalid since 2.13. You have to specify its a unit: def A(): Unit = { ... } Most of the ideas in scala were to remove boilerplate, but they backfired. The top example had an issue, were the following conversion used to be made: z op () // would equal to z.op() // instead of (fixed in 2.13) z.op(()) Arrows are used for creating key-value pairs and such. Someone added nice Unicode equivalents for them. Those got deprecated in 2.13 Deprecated: ⇒, →, ← Use instead: =>, ->, <- https://github.com/scala/scala/releases/tag/v2.13.0 https://github.com/scala/scala/releases/tag/v2.13.0
    - twic 7y ago
      They've also significantly simplified the collections classes, removing quite a bit of abstraction. That was always one of the things that struck me as most ludicrous about Scala, so i was pleasantly surprised by that. Indeed, i've been impressed by the Scala team's recent willingness to remove complex features generally. I didn't see that coming.
    - clhodapp 7y ago
      Your first example is an infix operator, not a postfix operator. Further, postfix operators are not actually being removed (yet: this could change), they are just being put behind an explicit opt-in.
deleted 7y ago
[deleted]
lkramer 7y ago
most of these seems reasonable, but they are not big enough for me to actively dislike the language. The capitalisation is maybe the most annoying for me, I think it was designed with an IDE in mind (which would be able to automatic update all references), but I still find it a flawed design to have to touch potentially a lot of files, many places to change something from private to not private. The problem with err has also bit me a few times. I don't like exceptions very much, but a solution like he suggests where a variable can only be ignore explicitly would solve it. Go is not perfect, but for me there is nothing else better for microservices that I have come across.
- _bxg1 7y ago
  > where a variable can only be ignore explicitly Like Rust :)
  - lkramer 7y ago
    I keep meaning to check it out :)
    - _bxg1 7y ago
      I'm still pretty new to it and I've never used Go, but Rust seems to address most if not all of these problems, while serving many of the same original design goals of Go. Probably its biggest disadvantage is the learning curve/iteration speed: it doesn't make it easy to just hack things together, especially when you're first learning.
      - weberc2 7y ago
        Yeah, iteration speed is a pretty big blocker for adoption in a lot of domains. Go isn’t perfect, but it lets me get things done today. That said, I appreciate that Rust exists for safety/performance critical domains, and as Rust matures (e.g., as it’s async story solidifies and consensus emerges around various HTTP libraries, etc), it will be more competitive for general purpose application development. But I suspect there will always be a significant productivity gap.
gerbilly 7y ago
Does anyone remember reading K&R for the first time? To me seemed like C was such a tight, perfect little design. Only thirty keywords, and simple consistent semantics.¹ When I first learned it, it was still pre ANSI, and you declared a function like this int f(a) char *a { } The ANSI style function declaration was maybe the only innovation that came after that that significantly improved the language. I remember in the late '80s knowing my compiler so well that I could tell you what the stack frame would look like pretty much anywhere in my code. It was awesome to have that level of familiarity. Soon after that things started to get more complicated, and I did a lot of Java, and I never again felt as dialed in to those languages as the late 80s C that I started out with. The K&R book is worth a read if anyone missed it. It's beautifully written. A far cry from the 'opinionated' copy that you often find on the Go website. Personally, I don't think you can make similar claims about Go's design or the 'because I told you so' tone that surrounds it. 1: Yes, I know, undefined behaviour, but this is my post and this is how I feel about C.
- AlchemistCamp 7y ago
  I just started digging into C a few years ago and was struck by the same. It's amazingly simple and the only "flaw" that leaps out at me is the precedence of & and | being higher than comparison operators. Other than that, and maybe the macro system, everything frustrating about learning it was due to the frustration of dealing with the machine rather than anything C itself imposed on me.
  - WalterBright 7y ago
    I love C, but it's biggest mistake is clearly the unstoppable decay of arrays to pointers: https://www.digitalmars.com/articles/b44.html https://www.digitalmars.com/articles/b44.html A mistake that C++ missed an opportunity to fix.
    - wbl 7y ago
      Arrays are for FORTRAN is I think the reason.
    - 7y ago
gerbilly 7y ago
My one line take on this: You don't use Go for the language design, you use it for the tooling.
- Boxxed 7y ago
  100% agreed -- it's crazy to me how much stuff you can just sweep under the rug when you have fast compilation, a decent debugger, static binaries, and so on. I always tell people, "I love everything about Go except for the language."
  - apta 7y ago
    > have fast compilation, a decent debugger, static binaries, and so on. See Java[1], C#[2]. Both have good compilation speeds (which don't really matter when you have incremental compilation anyway), as well strictly superior debuggers. [1] https://quarkus.io/ https://quarkus.io/ [2] https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen...
    - Boxxed 7y ago
      Oh thanks, haven't heard of those languages.
dbt00 7y ago
Go's certainly not perfect but I usually find it more productive than java or C++ for equivalent problems. For 2, I hate this example. Code that returns or takes booleans that requires reading a comment to understand the value is super error-prone to use. Don't write textually ambiguous interfaces in any language. I just haven't seen this particularly be a problem. #3 Re: checking errors, we wrote a trivial go vet plugin in house that checks for that. sort.Slice is probably new since this was written and is way better than sort.Interface if you're sorting a slice. Better vendoring and generics are finally acknowledged to be issues and solutions are coming. Hooray.
wwweston 7y ago
If there's anything I'd draw the most attention to from this, it'd be the conclusion: "If your program is small and can mostly be described by what it does... then Go is fine. If it’s large, if it has non-trivial data structures... or if it will be dealing with a lot of data from the outside, then the type system will fight you for no benefit and you’re better off using a different static language (where the type system helps) or a dynamic language (where it doesn’t get in your way)." That's a much better way to express my sense after almost a year of working with it that I'd ended up with a Pascal-like subset of Java with most of the liabilities of the former. And I wanted to like it going in ("hey, some people love it, and it's more or less Gosling's statement about Java w/o classes come to life!").
jrs95 7y ago
Biggest issues for me here were generics & the dependency situation, both of which are being fixed. But even back then, I loved using Go, mostly for what it DIDN'T have. Even ternaries, while convenient, inevitably lead to someone using them to write some really stupid shit that's hard to read. Overall, I'm a fan of losing a few helpful abstractions in order to get rid of all the bad ones, whether in the language itself or in it's ecosystem. And Go delivers on that.
betandr 7y ago
I totally get all of these points and understand them, and they're really why I do like Go. Implicit interfaces, for example, means you don't need to change code for something to implement this interface. It's a powerful thing that I find really great, especially coming from years of Java having to update everything I want to implement the new interface. If I don't have access to the code, then it's more boilerplate to do that. With Go, I create the interface I want and anything that implements it immediately works. I understand why people might dislike a particular language and that's cool. That's why there are many languages and we have the ability to choice what works best for us.
dawkins 7y ago
I have been using Go in production since 2012 and I find it a fantastic tool. Except for point 8 ("The sort.Interface approach is clumsy") the rest are features for me. I am so grateful for the Go creators for having made it as it is. What worries me is the recent changes: modules (never had a problem with GOPATH) and Go 2 proposals. I hope they are able to keep their vision as it started.
- baby 7y ago
  Same here, people can complain but the reality is that more and more people find Golang a great language to use day-to-day. Honestly I think it's here to replace Java and to stay. Same as Rust replaced C and C++. That anyone would want to write C/C++ or Java today is absurd, except if they're old.
  - thrower123 7y ago
    These are still very niche languages. Go has a better shot, albeit still long, with the weight of Google behind it, but there is an unbelievable amount of inertia. Rust certainly hasn't replaced C/C++ to any real degree yet. Maybe time will tell, but I'd lay money that there will be a lot of people still working on C, C++ and Java codebases in fifty years, just like there is a boatload of COBOL and even MUMPS software still out there in the wild today.
    - baby 7y ago
      I'm not saying that these languages have replaced their older versions, but that one would be crazy if given the choice to choose to do Java/C/C++ for work :)
- hliyan 7y ago
  > modules (never had a problem with GOPATH) I actually fall into the opposite camp. I never felt comfortable with GOPATH, but found modules extremely natural, perhaps because it's somewhat analogous to how NPM works: go mod init -> nom init; go get -> nom install...
nilsocket 7y ago
Most of them are silly reasons. The actual problems like versioning, error handling and generics (may be) are being worked on. I have seen many new learners find it hard to learn what packages mean, and how about teaching them private, public, static, ...
amedvednikov 7y ago
I created a new language [0] that is very similar to Go, but it fixes many things people often complain about, including all of the points in this article (except #2, but I don't think it's a drawback, really). It got lots of attention in a couple of months since the public release, and I often hear people say that they feel like this is "Go done right". It'll be open sourced by June 20. [0]: https://vlang.io https://vlang.io
- Aeolun 7y ago
  This looks interesting. I might give it a go.
- AH2mdte8kPnJS 7y ago
  This looks really cool!
- baby 7y ago
  Options :) But generics :( I'm really hopping that Golang finds a way to either not add generics, or add them in contrained ways. Your example code for generics are very hard to read for example. Rust somehow tackles that with associated types, but since generics are still allowed it's not great imo.
  - amedvednikov 7y ago
    Always interested in feedback, thanks. Why do you find them unreadable, because of the angle brackets? I've considered using struct Repo ⟨T⟩ { db DB } Instead of struct Repo <T> { db DB } The conversion would be done automatically by vfmt.
    - baby 7y ago
      Because they are too general. The ultimate test is to read someone else's code and try to figure out what is the actual struct being used in place. You will see that you often have to jump through many many files in order to get a sense of what is actually used in place. This problem becomes even harder when people start nesting generics. Take a look at associated types in Rust. I think it is a better way to do generics because it forces you to specify the type early. It also prevents nested types that are hard to read like <T<A, Cat<B>>> (and this is nothing)
abvdasker 7y ago
> Capitalization also restricts visiblity to two levels (package and completely public). I frequently want file-private identifiers for functions and constants, but there isn’t even a nice way for Go to introduce such a thing now. To me this is more of an issue with not understanding some of the conventions the language pushes you towards. An example of this common stylistic mistake is when some repos will have a `lib` package with a large number of utility functions spread across different files. It runs into the author's issue of function and constant collisions. The solution is to group together utility functions into many small packages, which has the added benefit of changing the code at the call site from something like this: lib.NewUUID() To something terse like this: uuid.New() I've found that Go has lots of these sorts of nudges — dependency cycles generating a compiler error, for example — where the language enforces good style and organization. However, if the Go compiler is going to enforce these rules, maybe it could be more helpful by suggesting the design tweaks that would help to avoid them, rather than forcing developers new to Golang to go through a kind of trial and error process.
DaveInTucson 7y ago
I thought one of the basic lessons we learned from the last 70 years of programming language design is that it's a bad idea to make semantics depend on lexical structure. I'm really surprised people like Rob Pike and Ken Thompson would design a language where the visibility of an identifier depends on the case of its identifier.
- sim_card_map 7y ago
  Interesting. Do you have links? Or maybe a short summary why this is bad?
  - apta 7y ago
    It becomes very annoying and tedious to refactor when you need to change visibility. Suddenly, a single line change (e.g. changing private to public) needs an IDE to refactor it and make sure it gets all instances (which is quite ironic given that golang proponents generally shun IDEs). Now depending on how many instances changed, you would need to split up your diff for readability, or clutter your diff with needless changes.
    - zemo 7y ago
      > a single line change (e.g. changing private to public) needs an IDE to refactor it the language comes with a rewriting tool that rewrites arbitrary expressions. gofmt -w -r 'thing -> Thing' *.go
      - apta 7y ago
        Still more and unnecessary effort compared to changing one word.
  - DaveInTucson 7y ago
    The linked article discusses this in the first point: * Changing the visibility of a variable requires changing its name, everywhere it's used. * It also cuts contrary to some very long-standing traditions, like using all caps for global constant names, using title case for class names, and starting with lower case for most everything else.
trpc 7y ago
it's a mediocre language, in fact it's the most mediocre language I have ever seen, that is being pushed by managers who want to lower hosting costs and faster time to market with good runtime performance.
- astrange 7y ago
  That's not true, C# is a far more mediocre language. At least top 5.
  - GenericsMotors 7y ago
    Nuh-uh!
    - LucasLarson 7y ago
      Thanks. I was wondering.
      - GenericsMotors 7y ago
        Assertions made without evidence dismissed without evidence, and all that jaz...
- hu3 7y ago
  - lower hosting costs - faster time to market - good runtime performance Looks good to me.
  - trpc 7y ago
    good if you're the manager not if you're the dev
kjgkjhfkjf 7y ago
You’re not forced to use the "imperative verbosity" in the article. The following is shorter and more idiomatic. serializeType := model.SerializeNonArchivedOnly if showArchived { serializeType = model.SerializeAll }
- buzzerbetrayed 7y ago
  How is this not imperative verbosity? Not to mention you are mutating an already assigned variable. You run in to problems when you want to know the type of serializeType and you look at the first assignment but don't see that there is a second one.
  - masklinn 7y ago
    > You run in to problems when you want to know the type of serializeType and you look at the first assignment but don't see that there is a second one. Go is statically typed, so the type of serializeType doesn't change, only the value.
deleted 7y ago
[deleted]
Skunkleton 7y ago
My biggest issue is how nil works with interface types. If nil gets cast to an interface type, you end up with something that doesn't equal nil.
solidsnack9000 7y ago
Really enjoyed the same author’s Java for Everything: https://www.teamten.com/lawrence/writings/java-for-everything.html https://www.teamten.com/lawrence/writings/java-for-everythin...
ajross 7y ago
From the very first item: > Idiomatic Go uses shorter names like u, but I stopped using one-letter variables 35 years ago when I left TRS-80 Basic behind. Ignorant snobbery. Skip.
SomeOldThrow 7y ago
Why doesn't go enforce using return values (or explicitly swallowing them)?
Animats 7y ago
Being able to ignore return values is something that C had before they had function prototypes. The compiler didn't know if something returned a value, so it couldn't check. There's no good reason for that misfeature in a newer language. Go apparently does it that way to make "defer" work.[1] [1] https://github.com/golang/go/issues/20803 https://github.com/golang/go/issues/20803
- Ace17 7y ago
  When was the last time you checked the return value of 'printf' ? Would you consider it a good thing to be forced to do? Moreover, there are functions for which "not ignoring" the return value isn't the same as "checking it" (e.g malloc, fopen, etc.). (CppCon about error handling: https://www.youtube.com/watch?v=GC4cp4U2f2E https://www.youtube.com/watch?v=GC4cp4U2f2E )
sriharis 7y ago
O hey, there's a subreddit dedicated to this: https://www.reddit.com/r/gobashing/ https://www.reddit.com/r/gobashing/
lamida 7y ago
I don't understand with the claim source file with name i_love_linux.go wouldn't compile in mac. I tried it and it is fine.
jasonhansel 7y ago
insert rant about how you need generics for functional programming here
- masklinn 7y ago
  Nothing a preprocessor and a smattering of syllabics can't fix.
ajxs 7y ago
At the risk of courting controversy, I'll confess that I haven't even so much as considered using Golang on the basis that it's a language ostensibly controlled by Google. I have reason to believe that my moral stance against Google is shared by many in the development community, but I don't recall ever seeing this sentiment extended to Golang. The anti-Oracle sentiment is thick and heavy in the development community, mainly surrounding Oracle's predatory business practices and how they leverage them via Java. I've completely avoided investing in Golang for that very reason, I don't want to ever become beholden to Google's services in order to maintain further development in this language.
Otnix 7y ago
Golang is difficult to learn especially for new programmer.. less support community

296 points by Danieru 7y ago

mavelikara 7y ago

(2016)

dang 7y ago
Added. Thanks!

_bxg1 7y ago

Unrelated thoughts: > Structs do not explicitly declare which interfaces they implement. This is done implicitly by matching the method signatures. This design makes a fundamental error: It assumes that if two methods have the same signature, then they have the same contract. Isn't this just duck typing? Don't other languages renowned for their type systems do this? > There’s no ternary (?:) operator. Every C-like language has had this, and I miss it every day that I program in Go. The language is removing functional idioms right when everyone is agreeing that these are useful. Expressive if/else is much more readable. Of course if Go doesn't have that, removing the ternary operator is a bad call. > The tried and true approach of providing a compare method works great and has none of these drawbacks. Hmm... except in anonymous cases. This author clearly has some Java stockholm syndrome. > The append() function modifies the array in-place when it can, and only returns a different array if it has no place left. That's horrifying.

networkimprov 7y ago
My one-line workaround. (Yes, I ban go fmt.) v := a; if t { v = b } Sadly, this doesn't work well if a is a function call :-(
- _bxg1 7y ago
  Out of curiosity, what's the motivating case for using Go in 2019's programming landscape? Edit: I didn't mean this as an insult, I meant it as a genuine question. I don't know much about the Go ecosystem, and I meant to find out what Go's killer feature is in 2019, when other languages now have strong and elegant concurrency, C-like performance with higher-level syntax and without manual memory management, etc.
  - blablabla123 7y ago
    Writing any type of network server from scratch is quite straight-forward if you know how to do it. Obviously concurrency is also available to the fullest.
  - 886 7y ago
    you make it sound like Go is not top tier in the 2019's programming landscape and there is a good alternative. Can you elaborate?
    - meddlepal 7y ago
      Yes it's called Java.
      - dang 7y ago
        Maybe so, but please don't post unsubstantive comments here.
    - bluquark 7y ago
      Kotlin and Swift are both currently encroaching on Go's server-side use cases. For example, Go's star feature, goroutines, has recently been cloned by Kotlin. They are at least as equally pleasant to program in, and they're hitched to major client platforms which means they improve faster and will definitely have a pool of trained developers in the long term.
      - apta 7y ago
        Java is getting a fiber implementation by means of project Loom, which will make golang even less appealing. The good thing is that because the fiber implementation will be built into the JVM, Kotlin and other languages can use them seamlessly.
      - 886 7y ago
        Points taken. I am full time on Go since few years ago and before that I was 100% Java. Haven't really kept myself up-to-date with the Java land. But from my experience with Java, Go, and Python, I find Go a very versatile programming language. Being able to compile binaries means it's great for infrastructure deployments and CLI tools. Goroutines, concurrency, and etc make it a great choice for server/micro service use cases as well. Some can say that not having a JVM is a plus as well. However, developers do have to be disciplined with error handling and dependency management. But one can argue that this is the case for software development in general.
- holy_city 7y ago
  To be fair that's generally good practice since it eliminates a branch in the code, depending on the type of v and overhead of assignment.
  - DuskStar 7y ago
    Sounds like the sort of thing your compiler should choose for you.
- DuskStar 7y ago
  Banning go fmt gets rid of one of the best parts of the go ecosystem, and I am horrified that you would do so. go fmt may not be anyone's favorite code style, but having go fmt is so much better than dealing with everyone else's favorite (incompatible!) styles.
  - networkimprov 7y ago
    There is no spec for go fmt. Its behavior has changed across releases. It has no switches to disable features. It destroys many nice single-line constructs, e.g. if err != nil { return err } Much of my code would be painful to read without that one. On the bright side, it artificially inflates your line count, so you appear more productive!
    - DuskStar 7y ago
      I think we're going to have to disagree there, then - yes that oneliner might reduce your LOC count and help you win at code golf, but it doesn't actually make things more readable and certainly isn't worth breaking from the rest of the community. The ecosystem-wide consistency of go fmt is its biggest strength. Adding switches to disable features would eliminate that.
      - networkimprov 7y ago
        There is a lot more to effective code style than whitespace, and most Go code I've seen doesn't consider that, including the stdlib. I've put a lot of thought into my style guide, and anyone who hasn't done the same has no useful insight on whether go fmt is a help or a hindrance.
  - _bxg1 7y ago
    > one of the best parts of the go ecosystem Is it more powerful in some way than the auto-formatters that exist for nearly every other language?
    - DuskStar 7y ago
weberc2 7y ago
> Isn't this just duck typing? Don't other languages renowned for their type systems do this? It's "structural subtyping", which is the type-safe equivalent of duck typing. It's a feature that allows implementations to exist without needing to know exactly every interface they implement. TFA's concern is purely theoretical. > That's horrifying. append() doesn't operate on arrays, it operates on slices. Arrays are fixed-length, contiguous blocks of memory that can't be appended to. Slices are backed by arrays, and if you append to a slice whose backing array is full, it will "grow" by allocating a bigger array elsewhere and copying the original data into it. This is a pretty standard data structure in most languages.
- gerbilly 7y ago
  > append() doesn't operate on arrays, it operates on slices. [...] This is a pretty standard data structure in most languages. If you say so. I know I should go read the docs more carefully, but this whole slice thing is confusing to me, and often yields surprises like this. I'm not a big fan of how this was implemented.
  - weberc2 7y ago
    How would you prefer it be implemented?
    - gerbilly 7y ago
      I don't know, I'll go and read up on it more. The feature leaves me 'meh'. I don't find slices as awesome as everyone is always saying, especially without negative indices. I guess part of it it that it isn't always clear to me when you're dealing with a slice, or an array, or whatever. I know, when it's confusing, there's always some reasonable sounding explanation after the fact, sure, but the whole thing feels like a confusing mess.
      - Boxxed 7y ago
        Do you know any other systems languages, like C or C++? This kind of thing makes a lot more sense when you have some surrounding context.
lmm 7y ago
> Isn't this just duck typing? Yes > Don't other languages renowned for their type systems do this? No. In languages with good type systems, nominal types are very valuable. E.g. "known-immutable list" and "read-only view onto a mutable list" are very different types, but offer the same set of methods.

kstenerud 7y ago

This article is from 2016, but it's still relevant. Even in medium sized projects I've been bitten by many of these issues, and for a language that's supposed to eschew magic, there's an awful lot of wizardry going on. Stopping compilation with an error for every unused import & variable is particularly annoying, so much so that I've patched the go compiler to treat them as warnings instead [1]. Ultimately, I think the problem boils down to a language that outgrew its original design, and hasn't evolved elegantly (yet). [1] https://github.com/kstenerud/go https://github.com/kstenerud/go

maxaf 7y ago
Your fork of Go promotes poor code quality. How’s this different from driving a car with an unbuckled seatbelt draped surreptitiously over the shoulder? The feeling of smug superiority must be intoxicating, but the risk of a violent ejection after a crash and subsequent death is still there.
- macintux 7y ago
  Certainly one difference is this: if I’m developing a one-off tool, or simply in early stages of development, it’s closer to being in a driving simulator with the seatbelt unbuckled. Not every line of code is life or death.
  - solarkraft 7y ago
    To expand on the metaphor: Imagine driving slowly and having to jump out of the car a lot.
    - stcredzero 7y ago
      A new car chassis in development might well get driven around with out a body and windshield attached, slowly around a test track.
- solarkraft 7y ago
  Does it? In my explorations I had to add bogus operations to variables and imports so the compiler wouldn't explode on me while commenting stuff out.

dang 7y ago

A thread from 2018: https://news.ycombinator.com/item?id=16414098 https://news.ycombinator.com/item?id=16414098 From 2016: https://news.ycombinator.com/item?id=12356823 https://news.ycombinator.com/item?id=12356823

losingthefight 7y ago

I have been using Go in production since 2015 and can honestly say that other than the ternary operator, none of these have been a major issue for me. Granted, I am doing mostly REST API development so my use cases may be different, but I have never had an issue with capitalization or which interfaces are implemented. The tooling is by far some of the best I have used in a language. Paired with a good editor (I personally use VS Code on Ubuntu 18.04 as my main setup) and I have yet to miss exceptions or wonder what my code is capable of doing. That being said, Go isn't perfect by any stretch. Sometimes panic ins Go routines can be very hard to trace. The transition to Go modules is challenging for larger projects with versions beyond 1.x (when I started it was Glide, then dep, now go mod, which has been a bit frustrating). However, I wouldn't go back to Java, C#, PHP, or NodeJS if I had the choice. My go to in the server space is Go and Elixir. I don't feel a desire or need for anything else, but again, that's me. You know your use case better than a stranger on the internet :)

AlchemistCamp 7y ago
That's really interesting. How do you use Go with Elixir? I've never really gotten into Go, partially because I feel like there's a lot of overlap with what it does and what Elixir does. I could see using it for CLIs and various Unix scripting, but I've been doing that with Ruby, for the most part. I also considered learning Go for creating some native binaries for a few critical paths, but Rust seems like the best choice for that. A NIF that crashes is one of the few things that will take down the Erlang VM, so Rust's strong safety guarantees (might) make it worth the steep learning curve.
- Thaxll 7y ago
  For one Elixir is very slow compare to Go.
  - Herrin 7y ago
    For what purpose? See: https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixir/ https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixi...

bborud 7y ago

I'm surprised that someone can use Go for 3 years and still be hung up on the things that most people appear to get over in the first month.

nkozyra 7y ago
Well, it's preference. Some people "get over" things, but when there are so many tools at your disposal, why not use the one you like best?
- bborud 7y ago
  To be fair, in a professional setting that is often not an option when it comes to programming languages. Usually you will have a situation where the language has already been chosen when you join a project. When you start a new project at a company, the language chosen is usually dictated by either what the company uses already or some process for reaching a consensus on what to use. What you don't really want in a professional setting is to use a lot of languages. For a large number of very good reasons. Picking a language involves compromise. I think what I perhaps reacted to were the somewhat superficial nature of the blogger's complaints. Especially when claiming to have done non-trivial projects in Go. Perhaps as a programmer, but it doesn't sound like someone who has lead development and had to make hard decisions. Non-trivial projects usually give you plenty of other things to worry about. For instance how good the language is for collaboration, how easy it is to model things, how clear is the code, how does it make use of the machine resources, will the language still have a following 10 years from now, what does the tooling look like, what quality are the open source contributions, is the standard library usable, do the third party libraries cover enough of what you need? And then there are the developers. You need to be able to recruit developers beyond your circle of friends. You want that pool to be as big as possible. This is why I avoid languages that have too little mainstream appeal. It doesn't help me much if I can hire some Common Lisp guru to build a lovely piece of software if I can't find anyone to maintain it once he or she leaves. Being the one to decide what language to use for a project is a thankless job because you will always disappoint someone. Not everyone will or can take in the larger perspective. As a manager I seriously do not want to hire developers that always want to program in some other language, often one with a small following. Or who want to change languages every 2 years. Because if they can't learn to live with one of a selection of mainstream languages that are "80% okay", why would I think they are any better at dealing with difficulties in other languages? I expect good programmers to adapt practices - to make languages work for them. To be professionals. When we switched from Java to Go in my department it was a team decision. As a manager I let my team decide what to use, HOWEVER, I made it clear that everyone will make an effort to learn whatever is chosen and I don't want any whining or excuses. If they found Go to be the wrong thing, fine, we have Java which is the devil we know to fall back on. But only after everyone has made a real effort. That was 3 years ago. We now have somewhere in the neighborhood of 100kLOC running in AWS and it has been astonishingly productive. Sure there has been _some_ whining about small details, but on the whole adopting Go was surprisingly fast and surprisingly pain free.

altmind 7y ago

There's a good website documenting go quirks: http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/ http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in... Some of the problems are really annoying and artificial such as "declared and not used/unused imports" trying to push golang opinion on code quality

diamondo25 7y ago

Most of the items explained are non-issues and part of why Golang is how it is today. Lets hope we can keep the language as-is and don't go back to old decisions and remove features like Scala have been doing the last years...

norswap 7y ago
<reference needed>
- diamondo25 7y ago
  One of the praised functions in Scala 2.8 was postfix operators, allowing things like: Seq(1, 2) map _ + 100 They are getting rid of it: https://contributors.scala-lang.org/t/lets-drop-postfix-operators/1457 https://contributors.scala-lang.org/t/lets-drop-postfix-oper... Unit functions were a thing, just write: def A() { ... } This is inalid since 2.13. You have to specify its a unit: def A(): Unit = { ... } Most of the ideas in scala were to remove boilerplate, but they backfired. The top example had an issue, were the following conversion used to be made: z op () // would equal to z.op() // instead of (fixed in 2.13) z.op(()) Arrows are used for creating key-value pairs and such. Someone added nice Unicode equivalents for them. Those got deprecated in 2.13 Deprecated: ⇒, →, ← Use instead: =>, ->, <- https://github.com/scala/scala/releases/tag/v2.13.0 https://github.com/scala/scala/releases/tag/v2.13.0
  - twic 7y ago
    They've also significantly simplified the collections classes, removing quite a bit of abstraction. That was always one of the things that struck me as most ludicrous about Scala, so i was pleasantly surprised by that. Indeed, i've been impressed by the Scala team's recent willingness to remove complex features generally. I didn't see that coming.
  - clhodapp 7y ago
    Your first example is an infix operator, not a postfix operator. Further, postfix operators are not actually being removed (yet: this could change), they are just being put behind an explicit opt-in.

deleted 7y ago

[deleted]

lkramer 7y ago

most of these seems reasonable, but they are not big enough for me to actively dislike the language. The capitalisation is maybe the most annoying for me, I think it was designed with an IDE in mind (which would be able to automatic update all references), but I still find it a flawed design to have to touch potentially a lot of files, many places to change something from private to not private. The problem with err has also bit me a few times. I don't like exceptions very much, but a solution like he suggests where a variable can only be ignore explicitly would solve it. Go is not perfect, but for me there is nothing else better for microservices that I have come across.

_bxg1 7y ago
> where a variable can only be ignore explicitly Like Rust :)
- lkramer 7y ago
  I keep meaning to check it out :)
  - _bxg1 7y ago
    I'm still pretty new to it and I've never used Go, but Rust seems to address most if not all of these problems, while serving many of the same original design goals of Go. Probably its biggest disadvantage is the learning curve/iteration speed: it doesn't make it easy to just hack things together, especially when you're first learning.
    - weberc2 7y ago
      Yeah, iteration speed is a pretty big blocker for adoption in a lot of domains. Go isn’t perfect, but it lets me get things done today. That said, I appreciate that Rust exists for safety/performance critical domains, and as Rust matures (e.g., as it’s async story solidifies and consensus emerges around various HTTP libraries, etc), it will be more competitive for general purpose application development. But I suspect there will always be a significant productivity gap.

gerbilly 7y ago

Does anyone remember reading K&R for the first time? To me seemed like C was such a tight, perfect little design. Only thirty keywords, and simple consistent semantics.¹ When I first learned it, it was still pre ANSI, and you declared a function like this int f(a) char *a { } The ANSI style function declaration was maybe the only innovation that came after that that significantly improved the language. I remember in the late '80s knowing my compiler so well that I could tell you what the stack frame would look like pretty much anywhere in my code. It was awesome to have that level of familiarity. Soon after that things started to get more complicated, and I did a lot of Java, and I never again felt as dialed in to those languages as the late 80s C that I started out with. The K&R book is worth a read if anyone missed it. It's beautifully written. A far cry from the 'opinionated' copy that you often find on the Go website. Personally, I don't think you can make similar claims about Go's design or the 'because I told you so' tone that surrounds it. 1: Yes, I know, undefined behaviour, but this is my post and this is how I feel about C.

AlchemistCamp 7y ago
I just started digging into C a few years ago and was struck by the same. It's amazingly simple and the only "flaw" that leaps out at me is the precedence of & and | being higher than comparison operators. Other than that, and maybe the macro system, everything frustrating about learning it was due to the frustration of dealing with the machine rather than anything C itself imposed on me.
- WalterBright 7y ago
  I love C, but it's biggest mistake is clearly the unstoppable decay of arrays to pointers: https://www.digitalmars.com/articles/b44.html https://www.digitalmars.com/articles/b44.html A mistake that C++ missed an opportunity to fix.
  - wbl 7y ago
    Arrays are for FORTRAN is I think the reason.
  - 7y ago

gerbilly 7y ago

My one line take on this: You don't use Go for the language design, you use it for the tooling.

Boxxed 7y ago
100% agreed -- it's crazy to me how much stuff you can just sweep under the rug when you have fast compilation, a decent debugger, static binaries, and so on. I always tell people, "I love everything about Go except for the language."
- apta 7y ago
  > have fast compilation, a decent debugger, static binaries, and so on. See Java[1], C#[2]. Both have good compilation speeds (which don't really matter when you have incremental compilation anyway), as well strictly superior debuggers. [1] https://quarkus.io/ https://quarkus.io/ [2] https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen...
  - Boxxed 7y ago
    Oh thanks, haven't heard of those languages.

dbt00 7y ago

Go's certainly not perfect but I usually find it more productive than java or C++ for equivalent problems. For 2, I hate this example. Code that returns or takes booleans that requires reading a comment to understand the value is super error-prone to use. Don't write textually ambiguous interfaces in any language. I just haven't seen this particularly be a problem. #3 Re: checking errors, we wrote a trivial go vet plugin in house that checks for that. sort.Slice is probably new since this was written and is way better than sort.Interface if you're sorting a slice. Better vendoring and generics are finally acknowledged to be issues and solutions are coming. Hooray.

wwweston 7y ago

If there's anything I'd draw the most attention to from this, it'd be the conclusion: "If your program is small and can mostly be described by what it does... then Go is fine. If it’s large, if it has non-trivial data structures... or if it will be dealing with a lot of data from the outside, then the type system will fight you for no benefit and you’re better off using a different static language (where the type system helps) or a dynamic language (where it doesn’t get in your way)." That's a much better way to express my sense after almost a year of working with it that I'd ended up with a Pascal-like subset of Java with most of the liabilities of the former. And I wanted to like it going in ("hey, some people love it, and it's more or less Gosling's statement about Java w/o classes come to life!").

jrs95 7y ago

Biggest issues for me here were generics & the dependency situation, both of which are being fixed. But even back then, I loved using Go, mostly for what it DIDN'T have. Even ternaries, while convenient, inevitably lead to someone using them to write some really stupid shit that's hard to read. Overall, I'm a fan of losing a few helpful abstractions in order to get rid of all the bad ones, whether in the language itself or in it's ecosystem. And Go delivers on that.

betandr 7y ago

I totally get all of these points and understand them, and they're really why I do like Go. Implicit interfaces, for example, means you don't need to change code for something to implement this interface. It's a powerful thing that I find really great, especially coming from years of Java having to update everything I want to implement the new interface. If I don't have access to the code, then it's more boilerplate to do that. With Go, I create the interface I want and anything that implements it immediately works. I understand why people might dislike a particular language and that's cool. That's why there are many languages and we have the ability to choice what works best for us.

dawkins 7y ago

I have been using Go in production since 2012 and I find it a fantastic tool. Except for point 8 ("The sort.Interface approach is clumsy") the rest are features for me. I am so grateful for the Go creators for having made it as it is. What worries me is the recent changes: modules (never had a problem with GOPATH) and Go 2 proposals. I hope they are able to keep their vision as it started.

baby 7y ago
Same here, people can complain but the reality is that more and more people find Golang a great language to use day-to-day. Honestly I think it's here to replace Java and to stay. Same as Rust replaced C and C++. That anyone would want to write C/C++ or Java today is absurd, except if they're old.
- thrower123 7y ago
  These are still very niche languages. Go has a better shot, albeit still long, with the weight of Google behind it, but there is an unbelievable amount of inertia. Rust certainly hasn't replaced C/C++ to any real degree yet. Maybe time will tell, but I'd lay money that there will be a lot of people still working on C, C++ and Java codebases in fifty years, just like there is a boatload of COBOL and even MUMPS software still out there in the wild today.
  - baby 7y ago
    I'm not saying that these languages have replaced their older versions, but that one would be crazy if given the choice to choose to do Java/C/C++ for work :)
hliyan 7y ago
> modules (never had a problem with GOPATH) I actually fall into the opposite camp. I never felt comfortable with GOPATH, but found modules extremely natural, perhaps because it's somewhat analogous to how NPM works: go mod init -> nom init; go get -> nom install...

nilsocket 7y ago

Most of them are silly reasons. The actual problems like versioning, error handling and generics (may be) are being worked on. I have seen many new learners find it hard to learn what packages mean, and how about teaching them private, public, static, ...

amedvednikov 7y ago

I created a new language [0] that is very similar to Go, but it fixes many things people often complain about, including all of the points in this article (except #2, but I don't think it's a drawback, really). It got lots of attention in a couple of months since the public release, and I often hear people say that they feel like this is "Go done right". It'll be open sourced by June 20. [0]: https://vlang.io https://vlang.io

Aeolun 7y ago
This looks interesting. I might give it a go.
AH2mdte8kPnJS 7y ago
This looks really cool!
baby 7y ago
Options :) But generics :( I'm really hopping that Golang finds a way to either not add generics, or add them in contrained ways. Your example code for generics are very hard to read for example. Rust somehow tackles that with associated types, but since generics are still allowed it's not great imo.
- amedvednikov 7y ago
  Always interested in feedback, thanks. Why do you find them unreadable, because of the angle brackets? I've considered using struct Repo ⟨T⟩ { db DB } Instead of struct Repo <T> { db DB } The conversion would be done automatically by vfmt.
  - baby 7y ago
    Because they are too general. The ultimate test is to read someone else's code and try to figure out what is the actual struct being used in place. You will see that you often have to jump through many many files in order to get a sense of what is actually used in place. This problem becomes even harder when people start nesting generics. Take a look at associated types in Rust. I think it is a better way to do generics because it forces you to specify the type early. It also prevents nested types that are hard to read like <T<A, Cat<B>>> (and this is nothing)

abvdasker 7y ago

> Capitalization also restricts visiblity to two levels (package and completely public). I frequently want file-private identifiers for functions and constants, but there isn’t even a nice way for Go to introduce such a thing now. To me this is more of an issue with not understanding some of the conventions the language pushes you towards. An example of this common stylistic mistake is when some repos will have a `lib` package with a large number of utility functions spread across different files. It runs into the author's issue of function and constant collisions. The solution is to group together utility functions into many small packages, which has the added benefit of changing the code at the call site from something like this: lib.NewUUID() To something terse like this: uuid.New() I've found that Go has lots of these sorts of nudges — dependency cycles generating a compiler error, for example — where the language enforces good style and organization. However, if the Go compiler is going to enforce these rules, maybe it could be more helpful by suggesting the design tweaks that would help to avoid them, rather than forcing developers new to Golang to go through a kind of trial and error process.

DaveInTucson 7y ago

I thought one of the basic lessons we learned from the last 70 years of programming language design is that it's a bad idea to make semantics depend on lexical structure. I'm really surprised people like Rob Pike and Ken Thompson would design a language where the visibility of an identifier depends on the case of its identifier.

sim_card_map 7y ago
Interesting. Do you have links? Or maybe a short summary why this is bad?
- apta 7y ago
  It becomes very annoying and tedious to refactor when you need to change visibility. Suddenly, a single line change (e.g. changing private to public) needs an IDE to refactor it and make sure it gets all instances (which is quite ironic given that golang proponents generally shun IDEs). Now depending on how many instances changed, you would need to split up your diff for readability, or clutter your diff with needless changes.
  - zemo 7y ago
    > a single line change (e.g. changing private to public) needs an IDE to refactor it the language comes with a rewriting tool that rewrites arbitrary expressions. gofmt -w -r 'thing -> Thing' *.go
    - apta 7y ago
      Still more and unnecessary effort compared to changing one word.
- DaveInTucson 7y ago
  The linked article discusses this in the first point: * Changing the visibility of a variable requires changing its name, everywhere it's used. * It also cuts contrary to some very long-standing traditions, like using all caps for global constant names, using title case for class names, and starting with lower case for most everything else.

trpc 7y ago

it's a mediocre language, in fact it's the most mediocre language I have ever seen, that is being pushed by managers who want to lower hosting costs and faster time to market with good runtime performance.

astrange 7y ago
That's not true, C# is a far more mediocre language. At least top 5.
- GenericsMotors 7y ago
  Nuh-uh!
  - LucasLarson 7y ago
    Thanks. I was wondering.
    - GenericsMotors 7y ago
      Assertions made without evidence dismissed without evidence, and all that jaz...
hu3 7y ago
- lower hosting costs - faster time to market - good runtime performance Looks good to me.
- trpc 7y ago
  good if you're the manager not if you're the dev

kjgkjhfkjf 7y ago

You’re not forced to use the "imperative verbosity" in the article. The following is shorter and more idiomatic. serializeType := model.SerializeNonArchivedOnly if showArchived { serializeType = model.SerializeAll }

buzzerbetrayed 7y ago
How is this not imperative verbosity? Not to mention you are mutating an already assigned variable. You run in to problems when you want to know the type of serializeType and you look at the first assignment but don't see that there is a second one.
- masklinn 7y ago
  > You run in to problems when you want to know the type of serializeType and you look at the first assignment but don't see that there is a second one. Go is statically typed, so the type of serializeType doesn't change, only the value.

deleted 7y ago

[deleted]

Skunkleton 7y ago

My biggest issue is how nil works with interface types. If nil gets cast to an interface type, you end up with something that doesn't equal nil.

solidsnack9000 7y ago

Really enjoyed the same author’s Java for Everything: https://www.teamten.com/lawrence/writings/java-for-everything.html https://www.teamten.com/lawrence/writings/java-for-everythin...

ajross 7y ago

From the very first item: > Idiomatic Go uses shorter names like u, but I stopped using one-letter variables 35 years ago when I left TRS-80 Basic behind. Ignorant snobbery. Skip.

SomeOldThrow 7y ago

Why doesn't go enforce using return values (or explicitly swallowing them)?

Animats 7y ago

Being able to ignore return values is something that C had before they had function prototypes. The compiler didn't know if something returned a value, so it couldn't check. There's no good reason for that misfeature in a newer language. Go apparently does it that way to make "defer" work.[1] [1] https://github.com/golang/go/issues/20803 https://github.com/golang/go/issues/20803

Ace17 7y ago
When was the last time you checked the return value of 'printf' ? Would you consider it a good thing to be forced to do? Moreover, there are functions for which "not ignoring" the return value isn't the same as "checking it" (e.g malloc, fopen, etc.). (CppCon about error handling: https://www.youtube.com/watch?v=GC4cp4U2f2E https://www.youtube.com/watch?v=GC4cp4U2f2E )

sriharis 7y ago

O hey, there's a subreddit dedicated to this: https://www.reddit.com/r/gobashing/ https://www.reddit.com/r/gobashing/

lamida 7y ago

I don't understand with the claim source file with name i_love_linux.go wouldn't compile in mac. I tried it and it is fine.

jasonhansel 7y ago

insert rant about how you need generics for functional programming here

masklinn 7y ago
Nothing a preprocessor and a smattering of syllabics can't fix.

ajxs 7y ago

At the risk of courting controversy, I'll confess that I haven't even so much as considered using Golang on the basis that it's a language ostensibly controlled by Google. I have reason to believe that my moral stance against Google is shared by many in the development community, but I don't recall ever seeing this sentiment extended to Golang. The anti-Oracle sentiment is thick and heavy in the development community, mainly surrounding Oracle's predatory business practices and how they leverage them via Java. I've completely avoided investing in Golang for that very reason, I don't want to ever become beholden to Google's services in order to maintain further development in this language.

Otnix 7y ago

Golang is difficult to learn especially for new programmer.. less support community