15 ms·

I Do Not Like Go

206 points by Liriel 8y ago

SideburnsOfDoom 8y ago
Seems to be from Feb 2018 https://github.com/grimoire-ca/bliki/commits/master/wiki/dev/go.md https://github.com/grimoire-ca/bliki/commits/master/wiki/dev... But I have seen similar sentiments before that
jeffrallen 8y ago
Congratulations, you have an opinion.
triodan 8y ago
This must've been quite an old article, because lo and behold, nearly every single complaint on that page is being addressed with gusto by the Go community! Proposals on generics and error handling is well underway, and his complaints regarding GOPATH and the go get has been solved with Go modules. EDIT: As I expected, the linked page is written on Feb 2018[1], things indeed have changed a lot since then. [1]: https://github.com/grimoire-ca/bliki/commits/master/wiki/dev/go.md https://github.com/grimoire-ca/bliki/commits/master/wiki/dev...
- xg15 8y ago
  Sorry, but the language existed for how long? I remember hearing about the same complaints about generics and error handling years ago - and they got answers back then with about the same level of arrogant dismissal like the quote about syntax highlighting in the article. It's good if the community is at least starting to listen now, but I don't think that is sufficient evidence that the language is good.
  - tinco 8y ago
    There is no discussion if the language is good, it's already quite convincingly proven it's good. The question was if generics would make the language even better. Some people think that's a no brainer, others are not so sure, and the latter group included the core maintainers. People use the language because it is good, I think at this point one can state that as objective fact. Once people use it, they'll complain when something is not as nice as it could be, like the error handling, and like the generics. I wonder if in 2000 people felt the way about Java 1.3 people feel about Go now. Java had a similar rise to prevalence, and it also lacked some features we now consider crucial, such as generics. I personally would never want to go back to Java 1.3. I feel I'd much rather code in Go instead, even if it lacks generics. But I still think it's worth considering if Go would turn out to become Java, if it now embraces generics.
    - edem 8y ago
      The language is crap. Just because people are using it does not mean it is good. Take a look at javascript. Same deal. You did not state any "fact"s why Go is good. Maybe it is good compared to Cobol or Fortran, but not compared to pretty much everything else.
      - tinco 8y ago
        Oh come on. People are forced to use Javascript, I don't think it would even exist today if it wasn't the only crossbrowser language. Almost no one is forced to use Go, and yet people flock to it. I don't feel I need to state the things that make Go good because it's already been done a thousand times, and everyone in this thread already knows why it is good. Have you ever built something in Go? I'm almost as productive in Go as I am in Ruby, and that was within a week of learning it. It's crazy good for a language that lacks so much expression.
        skohan 8y ago
        To be fair, I feel like go's simplicity makes it easy to get small things up and running, but the pain comes when your project starts getting large. That's when additional abstractions are missed.
        tinco 8y ago
        I don't think Go should be used for larger projects. Apparently though the community disagrees because they're really adding generics.
        stephenbez 8y ago
        It's interesting, I feel like it's the opposite and Go excels at large projects. Compared to other languages, Go doesn't let you use as many abstractions, so writing code takes longer, but it is much more straightforward to read. I work at a >1000 person company that codes mostly in Scala, and some in Go, and would prefer to read unknown Go code any day. With the Scala I run into things like implicit parameters and 7 layer of inheritance, but the Go code is straightforward. Go is somewhat of a lowest common denominator language. You could out perform it with a small team of strong developers, but when once your project gets to a certain size, it's unlikely all of the developers will be strong.
  - vonseel 8y ago
    Are you really arguing that the language is not “good”? Sure, there are things not to like about it, but the widespread adoption of Go as a systems programming language is evidence alone that it is a “good” language. Good is such an ambiguous term that I’m not sure it’s even worth using. For one person, only esoteric languages like Haskell are “good”, for another person, Python or Javascript are “good” enough.
    - 62747478182 8y ago
      > but the widespread adoption of Go as a systems programming language is evidence alone that it is a “good” language. Years ago PHP was the king of web development, and it was pretty awful in many ways (today is much better, though). People usually choice languages because of convenience, not because of how good they are.
- eptcyka 8y ago
  Judging by most responses form the Go team and/or the community around the language, it would seem that none of the issues listed in the article are actually valid. I.e. this is the _correct_ way to handle errors, sum types bring nothing, etc. Of course, things have changed since, but what does that say about the previously strongly held opinions of the team?
  - grumpydba 8y ago
    > Judging by most responses form the Go team and/or the community around the language, it would seem that none of the issues listed in the article are actually valid Generics have been considered for years by the core maintainers. See Ian Lance Taylor's proposals. So you're either lying or not informed enough to be so assertive.
- edem 8y ago
  It it is underway it is not solved. Go is crap.
  - akmittal 8y ago
    There are only two kinds of languages: the ones people complain about and the ones nobody uses. -Bjarne Stroustrup
    - eeZah7Ux 8y ago
      and Python.
    - joelfolksy 8y ago
      "There are two kinds of men: the ones complained about by their wives, and the ones who are single" - Me, before sleeping on the couch
    - edem 8y ago
      I don't see how this adds any value to the conversation.
      - akmittal 8y ago
        It says no language is perfect there are some or another compromise in all.
- dragonwriter 8y ago
  > This must've been quite an old article, because lo and behold, nearly every single complaint on that page is being addressed with gusto by the Go community! “Being addressed” = “not yet effectively addressed” = “still an issue”
- deleted 8y ago
  [deleted]
Sean1708 8y ago
> syntax highlighting, or as I prefer to call it, spitzensparken blinkelichtzen Google Translate reckons this means "peak parking", is that a correct translation? If so would somebody mind explaining what parking has to do with syntax highlighting? And if not, what is the correct translation?
- PeterisP 8y ago
  It's not something to be translated, it's a mock language. See https://en.wikipedia.org/wiki/Blinkenlights https://en.wikipedia.org/wiki/Blinkenlights
  - Sean1708 8y ago
    Ah, thank you. I suppose there are no prizes for guessing which generation I belong to then?
- rarestblog 8y ago
  Not a native German, but probably this: "spitzen sparken blinken lichtzen" -> "pointed sparkles flashing lights"
  - mirimir 8y ago
    Or maybe "brightly high-lighted pointers".
  - ncmncm 8y ago
    No, it means "spitting sparks". Like you see coming out of the control panels in the original Star Trek, when they got shot by Klingons. I guess they remrnbered about circuit breakers when they built the later Enterprisen.
- raister 8y ago
  I would call it Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz but that's me.
CodinM 8y ago
Go does not like you either.
knan 8y ago
you don't have to like go, I'm not "liking it" per say, but what's the alternative if you want static typing/compile language, Java, well the compile time is to big for my taste, do a change wait 30 seconds, also it needs to munch ram, Net core could not get it to run.
- gaius 8y ago
  Have you tried OCaml? It’s higher-level than Go and easily produces high performance self-contained binaries.
  - knan 8y ago
    be that, but the fact that I didn't heard of it, I just need to get shit done, not experimenting.
    - lucozade 8y ago
      > but the fact that I didn't heard of it Would suggest that you're not very familiar with the field that you're commenting on. Ignorance of a subject is perfectly fine. Everyone's ignorant of something. But flaunting your ignorance doesn't really strengthen your case appreciably.
- klohto 8y ago
  Rust
- Dzugaru 8y ago
  D or Rust?
  - knan 8y ago
    D is a mess, Rust maybe no, but seeing how firefix is lossing browser share, I doubt in 5 - 10 years, there will be any company behind it anymore, same for kotlin, with vscode beating jetbrains.
i_phish_cats 8y ago
My first Go project was a PDF parser. Rewrote it in C a similar number of lines because Go's capacity for polymorphism is as primitive as in C.
- martingxx 8y ago
  Can you explain more about why you re-wrote? You seem to have said you rewrote from Go because it has poor polymorphism, into C which is equally bad in this regard. If you find some language feature important, surely you would not rewrite into a language that doesn't have that feature?
  - i_phish_cats 8y ago
    C is equally bad, but it can be used anywhere -- it can be compiled into a dynamic lib and used in any language/framework, which is exactly what we did.
- IshKebab 8y ago
  True, though that doesn't seem like a good reason to rewrite it in C. A PDF parser in C sounds like a security nightmare, and now you have to deal with C's archaic build systems.
deleted 8y ago
[deleted]
gaius 8y ago
the language embodies an extremely rigid caste hierarchy of "skilled programmers" and "unskilled programmers," enforced by the language itself. Scala also has this approach, a sharp distinction between library-writers and application developers.
- skohan 8y ago
  Sacla, IMO, suffers from exactly the opposite problems as Go. It's flexibility lends itself to abstractions for the sake of abstractions, and in practice it sometimes seems more like a platform for showing off "cleverness" than for solving actual problems.
- blablabla123 8y ago
  In my opinion this is a misconception that I saw in other people approaching the language as well. The thing is: nobody should use "advanced" features. Using `reflect` should be reserved for exceptional case where it's not possible to solve the problem differently. This has been pointed out in the Go website and the mailing list bizillion times. That said, the language doesn't have many features. So if you want to show off your skill, it's probably by structuring the code concisely which can be challenging at times. Using reflect is actually the easy way out and most functions of that package can panic easily...
- kjeetgill 8y ago
  I know it's not quite the same thing, but never have I seen this more pronounced than in LaTeX.
- kod 8y ago
  Even if you believe that distinction, Scala is different because library writers can use the same language as application developers. That's not true of the divide between implementing and using Go.
danpalmer 8y ago
> I can't speak for Go's genesis within Google, but outside of Google, this underanalysed political stance dividing programmers into "trustworthy" and "not" underlies many arguments about the language. This summarises my opinion of Go that has been forming recently, that it's a replacement for Java. Java was the "safe" choice. Many engineers knew it, bad engineers couldn't be _that_ bad in it and would manage to produce something. They could be handed an architecture spec and implement it word for word without doing much translation to the Java language. But I don't think good engineers could "shine" with it. It normalised all engineers around some median of productivity, and made projects predictable. I believe Go is doing the same thing in some ways. It's not supposed to allow good engineers to find great ways of expressing complex architectures (however necessary that may be), it's designed to let engineers of all skill levels hit all problems with a Go shaped hammer and get something that looks inoffensive, boring and predictable. This is very unsurprising given that it came out of a large engineering organisation. Google have many engineers of a wide range of skill levels, and normalising engineering is more important than doing it better. I realise Google probably has a higher than average engineering ability, maybe far higher than average, but they still have a wide range, and I also include in this engineers who might be fantastic frontend engineers, who have to get stuck into some system software, for example.
- dis-sys 8y ago
  > But I don't think good engineers could "shine" with it. any concrete example on what a good engineer couldn't achieve when using Go in its intended domain/role?
  - danpalmer 8y ago
    I've seen some amazing abstractions created in Rust and Haskell. Some of the Haskell ORMs are really nice abstractions over SQL for example, and there are many examples of Rust macros doing amazing things (I believe async/await was implemented as a macro?). Obviously you can write an ORM in Go, and you can write async code or code that will do whatever Rust macros can do, but the solutions will be less elegant, less re-usable, less useful. There's an argument to be made that this is all "clever" code, and that that is bad for maintainability. I'd agree they can be misused, but when used correctly they can level up how code is written in a very substantial way. Understanding the difference and when they are appropriate is what I really mean good engineering here.
hardwaresofton 8y ago
tl;dr - they said go was going to be simple. It is. Preface: It's perfectly OK to dislike languages, especially when you know of a better one that you're not using. I personally cannot help but think of all the better languages I could be using when I have to write some verbose bad abstraction in a less expressive/powerful language. Also, as I re-read this, the notion has struck me that I might be a Golang apologist. Also, as others have noticed, the Go 2 drafts mention just about every point in this article. That said, I think OP misses the point of Go -- it's meant to be simple, productive, and production-ready. Many of the points that OP makes about the mistakes I kind of shrugged at. > I've never met a language lead so openly hostile to the idea of developer ergonomics. I'm not sure I believe this C++/Java have similarly bad ergonomics, just in a different way -- they give/saddle you with abstractions that are easy to use wrongly and let you build a shit castle with amazing speed, while keeping yourself open to to a hornets nest of mistakes and pitfalls. Go sacrifices these features for a reason, and they stated it up front. That said, I do think they made a huge mistake not having proper union/sum types (AKA Algebraic Data Types/ADTs), but I can forgive them because building an excellent type system might have gotten in the way of their stated simplicity goals. > In Go's case, the language embodies an extremely rigid caste hierarchy of "skilled programmers" and "unskilled programmers," enforced by the language itself. I think this is a reflection of the Go, Google, and programming community in general. Whether it's the "10x engineer" or working-at-big-companies-means-you're-a-good-engineer mentality, this mindset is pervasive. It's the difference between a Senior Staff Software Engineer II and a Senior Engineer who just moved in from some other company -- it's trust. > Again, the Go team's "not our problem" response is disappointing and frustrating. Sucks that they didn't solve those problems up front, but I personally do not blame them for focusing on shipping, and fixing as they go. Honestly with the amount of work they've put in, they have built a runtime and language that have comparable performance and are more simple than Java + JVM. The JVM has millions of man hours dumped into it over decades. This is insane. Also, there's the fact that whether it's a complete farce or not, they have left open an avenue for changing the language. People could fork Go and change it if they really felt that strongly about this stuff. The thing is, people for the most part don't -- if you want a better type system go use (and convince your team to use) a better language. > The standard Go approach to operations which may fail involves returning multiple values (not a tuple; Go has no tuples) where the last value is of type error, which is an interface whose nil value means “no error occurred.” Yes, error handling in Golang is less than ideal, but I prefer the forcing of this as a default over the C++/Java approach -- this default makes it very hard to write code that doesn't deal with errors at the place you're most able to correct/work around them. Again, I'm also giving Golang a pass for not having errors-as-values in the way a language with a good type system would... because Go sacrificed their type system for simplicity. I don't think Go is a good programming language, but I do think it delivers on what it promises. It does what it set out to do -- be simple, productive, and production-ready (this is mostly because they hammered out all the bugs with tons of buy in from developers inside and outside google, and it's still not perfect of course). I've said it before and I'll say it again -- I think Go will supplant Java as the language most companies use on the backend in <10 years. Fundamentally, because of the developer fungibility benefits of Go -- it's going to be easier than ever to swap out Golang programmers than ever -- you won't even have to be a JVM master (which is normally one of the border points between Java amateurs and pros) to write good-enough code. Business thrives on good-enough code, not good code -- Golang is excellent for that, and gets proven more and more right every day with all the companies that are writing performant, statically compilable (thus easier to ship) code and just getting shit done. [0]: https://go.googlesource.com/proposal/+/master/design/go2draft.md https://go.googlesource.com/proposal/+/master/design/go2draf...
danpalmer 8y ago
An interesting tidbit I learnt from a former colleague: He wrote a small but non-trivial project in Go, and ended up re-writing in Python. Over time, he and his team measured both codebases and found that they had roughly the same number of bugs per line of code, but the Python codebase was 1/3rd of the lines of code, therefore had far fewer bugs. I wouldn't attribute this to inexperience either, this is one of the best engineers I've worked with.
- fouc 8y ago
  I think people write in Go because it's ostensibly faster in runtime (and maybe easier to deploy). It always was going to require more lines of code than languages like Python or Ruby, that's not a surprise at all?
  - danpalmer 8y ago
    The fact it required more lines was expected. The fact that despite the additional tooling, type system, safety, etc, it had 3x more bugs than a Python implementation was unexpected.
    - IshKebab 8y ago
      3x more bugs that you know about. I wouldn't be surprised if Go's static type system just found more bugs, and the Python program had just as many bugs but you didn't happen to hit them at runtime.
      - bb88 8y ago
        I would assume he's talking about non-type system bugs. In 2018, most people won't look at a PR unless it compiles and the unit tests works.
        danpalmer 8y ago
        I got the impression these were bugs that made it into a tracker of some sort, and I don’t think most engineers log “bugs” they encounter during local development before some notion of a release (be it to staging, the world, the master branch, whatever).
Almost2019 8y ago
It kind of comforts me in a way that someone as celebrated as Rob Pike is basicaly an imbecile.
lkramer 8y ago
As have already been pointed out most of these points ARE being addressed by the Go community, but it kinda reminded why I look towards Go 2.0 with some dread. Most of these things that he is asking for are things that will make the language harder to read, Generics and Exceptions (and not least this weird chimera that they have come up with in to Go 2 proposal last time I checked), will undoubtedly create popular libraries, which are almost impossible to understand for the uninitialised. The main strengths of Go is that it's easy to pick up for almost anyone with basic programming skills and be productive. The rigidity of the style, and the relative simplicity means that I can get a very fair idea about how almost any 3rd party library on Github works in an hour, and probably tweak the bits I may need to tweak. (The obvious exception to this is any library using a lot of reflection which can fulfill anyone's deepest desires to make code unreadable). C++ (which is my other main work language), have all these advanced features (often added in haphazard fashion late in the language specs), and I love writing C++ code, but I dread looking at other peoples code, because it can be almost impossible to figure out what is going on. I am tempted, when I see all these complaints about Go and comparing them to languages with different feature sets, to tell people that in that case they should use those. Of course, you might have the language dictated by an employer, but in that case there was probably a rationale behind choosing Go, and trying to change the language into being a clone of every other language will probably just result in someone else coming up with a new simple, statically typed compiled language, because I honestly believe the world needs that.
- dnautics 8y ago
  > The main strengths of Go is that it's easy to pick up for almost anyone with basic programming skills and be productive. This is passed around like gospel, but as a counterpoint my intern started this week at 30 hours a week. I taught him elixir from scratch, and today he finished writing a web server that serves GET and POST requests (which he didn't know) and stores states correctly. Also with low touch; he did much of the documentation reading himself and I was able to finish up about 1500 lines of code for a demo tomorrow. I feel like pretty much all modern languages except maybe rust are reasonably easy to pick up.
  - 8y ago
crististm 8y ago
As Richard Hamming used to say ~"You can pretty much ignore those who discovered a field". Do not worry _at all_ that Rob Pike is finding colors juvenile. His opinion is just that. If it's worth anything, I'd put it in the same category as Linus's distaste for debugging tools.
- tokai 8y ago
  I love how childish it is to think that his personal experience of learning arithmetic, is worth anything regarding syntax highlighting. In some way it even undermines him. Why did he use coloured rods as a child? Because it helps reduce cognitive load! To define easier things as childish and harder things as adult, is elitist and hostile to other people.
  - thatswrong0 8y ago
    Rob Pike also thinks abstractions like map, reduce, and filter are pointless because you can just write a for loop. Hence, we have Go.
deleted 8y ago
[deleted]
dragonfly02 8y ago
I am a total beginner in Go but I feel like the enforced uniform formatting is actually a good thing because it makes everyone's code consistent and more readable. It can be extremely difficult to read other people's code if they use a totally different style even if both of you are good at the same language. And I feel there is litter point in telling people not to use one language simply because you don't like it. Everyone is different, if you don't like it just use something you like (maybe change job if you have to use it at your current job). There is and will never be a language that EVERYONE likes. Oh did I forget javascript? LOL...
- tinco 8y ago
  Yes it is, I don't think anyone disagrees with that enforced formatting is a good thing.
  - dragonfly02 8y ago
    Why am I not surprised:D
- spicyusername 8y ago
  Can't agree more. It's one thing to have a healthy debate about how to improve a language. It's another to keep circle jerking over these anti-x blog posts.
abtinf 8y ago
For quite some time, I’ve taken to wrapping the most common err case with a simple function: func dieOnErr(err error) { if err != nil { log.Fatal(err) } } It makes the code much easier to read (due to efficient use of vertical space) and much less tedious to write: dieOnErr(foo()) _, err := bar() dieOnErr(err)
- skohan 8y ago
  What kind of application would you use this in? Just exiting on every error seems you're just punting the whole problem of error handling, and wrapping every fail-able function in another function doesn't seem like the best thing for readability either. Also this doesn't really solve the problem sited in the article: it requires that all your functions return exactly two values with the error in the second place. What if you need to return two non-error values?
  - abtinf 8y ago
    I primarily use this in three areas: Command line tools: if any part of the command fails, you usually don't want to continue, unless it is a long-running batch process. In that case, I usually also write a logOnError() function to keep track of problematic work items. Servers: during server initialization, there are many circumstances where it doesn't make sense to continue, such as template compilation failure or failing to open the socket. Other: I use dieOnError anywhere it would otherwise make sense to use panic() - situations where continuing the program would mean running in an unknown state, like out-of-memory conditions. I've built systems with complex error handling before, but my teams have always run into the problem of trying to reason about complex, unpredictable program state. If the requirements can allow for the program to fail fast (as you say, "punting the whole problem"), then the code itself can be kept much simpler and easier to reason about. When errors do crop up, it is easier to look at logs to debug a simple program (or infrastructure issue) than to debug a complex program where you aren't sure how earlier errors affected state. In languages with exceptions, this is sort of the default - if you don't handle an exception, the program will crash. Often there will be a main level exception handler that logs otherwise uncaught errors. But a problem in Go is that programs are default-alive on errors. If you don't check the error status of every single function call that returns errors, then the program can get into unknown state. So in production code, especially code that just combines a few libraries, every function call ends up taking 3 or 4 lines (1 line of call and/or 3 lines of error checking). Regarding the number of return values, my dieOnError/logOnError only handles functions that return error and nothing else. If the function returns multiple values, I first call it, then call dieOnError with the err: foo, bar, err := baz() dieOnErr(err) //assume foo and bar are valid I suspect I could write a variadic error checking function that assumes the last parameter is error: func dieOnError(a ...interface{}) { //do some reflection magic? } func foo() (bar int, baz int, err error) { ... } //maybe needs some type assertions or something? bar, baz := dieOnError(foo())
divan 8y ago
This article is a bit outdated and has invalid claims and a lot of ad hominem and other fallacies, so I'd recommend to stick to the textbook for complaining about Go for maximum clicks: https://divan.github.io/posts/go_complain_howto/ https://divan.github.io/posts/go_complain_howto/
- hu3 8y ago
  You're not wrong. The article is at least 10 months old: https://old.reddit.com/r/golang/comments/7zmt8u/i_do_not_like_go/ https://old.reddit.com/r/golang/comments/7zmt8u/i_do_not_lik...
tempodox 8y ago
Good article, and I admire the author's patience. You don't bind yourself to the inner politics and philosophy of something like Google except when you are Google. Anyone's good taste should have prevented them from using a language with such severe and ludicrous restrictions, but that filter obviously didn't work.
yazr 8y ago
Off topic: Can i ask Go developers if the compiler is fast enough (for now), or is this still a (major) pain point ? Disclosure: i work on build systems and optimizers.
- remus 8y ago
  What do you mean by 'fast enough'? As compiled languages go I think it's generally accepted that go compiles relatively quickly, especially for large projects with lots of dependencies (as it has saner dependency rules than c/++).
- hu3 8y ago
  > still a (major) pain point What? Go compiler is blazing fast. It's one of the fastest compilers of major languages if not the fastest. Some discussion from 2016: https://stackoverflow.com/questions/2976630/how-does-go-compile-so-quickly https://stackoverflow.com/questions/2976630/how-does-go-comp...
oxplot 8y ago
I've learnt that programming languages, just like food and fashion, are a matter of taste to a high degree. You can point at awful smelling, too sugary meal and call it crap. Someone else spends years perfecting it. One's taste however can change: food with high sugar leads to heart disease and diabetes, so I better stop eating that favorite dish of mine. You keep doing that for a while and taste of sugar (or salt, or fat) becomes disgusting. Statements like "Go is crap, it has no generics" originate from one's taste in programming languages so there is no arguing with that. However, talks about what generics (or exceptions etc.) does to the health of the programs you write that span time and other contributors, are no longer subjective matter, but an argument worth having. This is, where I think, Go's strength comes in: its careful development process that puts programs' and programmers' health at the top of the priority list. Health is not the same as comfort. Taste of a dish you've had for years is comforting. You're not going to feel comfortable when the ingredients you've come to expect are taken away. But if you can get past that, you may end up living longer and healthier. Similarly, your programs may become more maintainable and long lasting. No one, who is familiar with the philosophy and motivation behind Go, can claim that what I've said above is false. You can say that Go team is slow in progress, but that's what methodical and evidence based approach is like: slow. You need time to experiment, learn and evolve. You other favorite languages act like the general public who at hearing in the news that "coffee is good for you", starts drinking 10 cups a day. Go's approach is more along the scientific way.
- vram22 8y ago
  >I've learnt that programming languages, just like food and fashion, are a matter of taste to a high degree. You can point at awful smelling, too sugary meal and call it crap. Someone else spends years perfecting it. Programming languages ... food ... fashion ... taste ... Time to pull out that old chestnut: https://en.wikipedia.org/wiki/De_gustibus_non_est_disputandum https://en.wikipedia.org/wiki/De_gustibus_non_est_disputandu... I agree.
- deleted 8y ago
  [deleted]
- opless 8y ago
  Sugar is not a direct cause of diabetes. So you might want to rethink your analogies in future. https://www.diabetes.org.uk/guide-to-diabetes/enjoy-food/eating-with-diabetes/diabetes-food-myths/myth-sugar-causes-diabetes https://www.diabetes.org.uk/guide-to-diabetes/enjoy-food/eat...
luord 8y ago
I can get past most of Go's weird idiosyncracies... Except for the odious error handling. Reading go code makes my eye twitch, and the biggest reason is its error handling. And sadly I'm now stuck with it, and not even the changes for Go 2 are encouraging because, even though its new error handling is saner, it is still needlessly different for the sake of it.
- weberc2 8y ago
  I quite like Go's error handling. It adds visual structure and makes it apparent which things can fail and how they're handled. It's a welcome relief from the likes of Python where you only see (and consequently think about) the happy path. This is definitely a big driver of our 500s in our production Python services. While there are many who are genuinely aggrieved by the number of keystrokes, I think a lot of people are annoyed at error handling in Go simply because you have to think about error handling.
  - ernst_klim 8y ago
    >simply because you have to think about error handling. until you write x, _ := some_code () Besides, Go errors are used in pair with the return value, so you have to check 4 possible combinations of value/nil and error/nil instead of 2 due to the absence of sum types. Oh, and no generics, so your errors are either string or you have to check the interface in runtime which and can't statically check which exact errors could your code return. Oh, and no monadic chains/exception mechanism, so feel free to write x, err := if (err != nil) { return err } y, err = ... if (err != nil) { return err } instead of do x <- fun1 () y <- fun2 () ... and then just check the proper subset of possible errors, carefully inferred by the type system. There are a bunch of different possible approaches for error handling: exceptions, monads, erlnags failures as possible case, Go crowd had just invented the worst and least error-prone one.
    - weberc2 8y ago
      > until you write Yeah, you can definitely opt out of it and there are even cases where the compiler doesn't guarantee that you're handling the errors, but assuming you're making a good faith effort to adhere to conventions, then you're thinking about your errors. > Besides, Go errors are used in pair with the return value, so you have to check 4 possible combinations of value/nil and error/nil instead of 2 due to the absence of sum types. No, you don't. If the error is not nil, there's an error. Sum types would be nice, but they wouldn't reduce the number of checks, they'd just formalize the idiom. > Oh, and no monadic chains/exception mechanism, so feel free to write I'm fine with this. Monads are hard for people to understand, and I'm not playing code golf... > Go crowd had just invented the worst and least error-prone one. I don't think it's the least error-prone, but it's not bad.
weberc2 8y ago
This article lists a few issues, some valid, others not, but all exaggerated. No mention whatsoever of the many advantages Go brings much less a comparison between the pros and cons. There are a lot of interesting critiques of Go; sadly, this isn't one of them.
black-tea 8y ago
I've done lots of work in C, Python and Common Lisp. I've done a fair bit in go and for me it's just not fun to use. I feel like I'm playing in a little sandbox with a few prescribed tools.
kureikain 8y ago
These are author opinion and I respect and understand where he came from. People should have ability to share about their opinions with the world. That's great. But argue about the syntax highlight are silly to me. Argue about leadership though on that syntax highlight is fine. Below are mine. Let's look at Go from 2 angles: - Go the language - Go the leadership Go, the language is great to me. In the article, OP talk about `go get`, GOPATH, Error Handling. To me they are fine. I love `go get` because it was so easy to install binary that way and get update too. It fall short when have conflict because you have a single global tree which thing depend on. This is obviously not gonna work in long run, and in fact they always said they use it different way at google and expect community standarize and find ways through it. Which eventually lead to where we are now with go module. But let's take a step back. Let's say if everything work great, do you like `go get`. It's just feel like `homebrew` and a game changer to me. What if we can abstract everything out, make `go get` works great as it's without population the global tree. Technologies will evolve. Look at how JavaScript evolve and become a great language and platform as it's right now. Give Go time. Same with error handling. Exception is just as annying too. You either handle it or just swallow up or let's it buble up. I prefer Go style. Read Go code force me to think about error right at that point. I would love Go to have thing like Result or Maybe :( instead of return multiple value which is just a convention right now. Go bring lots of toolchain and interesting idea. gofmt gofix etc... However, Go the leadership isn't up to Go the language. I think they feel to the trap when they made a language which many big project use(influxdb k8s docker...) and they get defensive when people talk about Go or criticize it. Look at how friendly Jose of Elixir or Matz of Ruby is. I would love Go leadership reach that. I read in other thread where someone say `Golang` and one of Go core dev just dismiss because he written `Golang` instead of `Go`. I think eventually the leadership will change. Go is opensource after all. And we will see a day where Go is great both at language and leadership.
kerng 8y ago
Been working with Go a bit and also reviewed and saw tons of production code at places. The one thing that stands out is how messy and unorganized code is written often. It's more of a "write only" language to me it seems. Java or Python are much more readable.
tmaly 8y ago
I was just having a discussion yesterday with a co-worker on Go. He deals with security and encryption and does not do development work. While I enjoy Go for its strengths, it was his opinion that Go did not offer anything above and beyond other languages.
- kjeetgill 8y ago
  Well yeah, I'd agree that he wouldn't. Most of the specialness comes at the application level: He gets nothing out of specific blend of garbage collection, allocation options, typing, and green threading that sorta defines go.
watergatorman 8y ago
If anyone who has tried Modula-2, Go appears to be very close, at some core level, to m2, but m2 has a cleaner syntax, IMHO?
- atombender 8y ago
  Go was influenced by Modula-2, but even more so by Oberon, which one of Go's designers, Robert Griesemer, worked on with Wirth at ETH Zürich. Oberon is in many ways a minimalist version of Modula-2.
sershe 8y ago
One thing I definitely dislike are value/reference semantics, where arbitrary nested object structures are passed by value by default, but maps and slices are somehow magical and are passed by reference. I don't even care which one it is, but either everything non-primitive should be by reference by default, or by value.
- hu3 8y ago
  Nope. Everything is passed by value including maps and slices. Here's an article from 2011 that might help you understand that: https://blog.golang.org/go-slices-usage-and-internals https://blog.golang.org/go-slices-usage-and-internals
sebchris 8y ago
My expectations surrounding Go were born from my intense admiration for Python, which has grown so much as a language from its humble genesis at Google and proudly stood the test the time. Needless to say, I was beyond disappointed. Barring its concurrency module, which is some half-backed mixture of STM and async, I was astonished at the absurdity of the language. It reminds me of JavaScript, which as I recall was originally written as a sort of joke. So yeah, Go's like a bad joke.
- dustycat 8y ago
  Python did not have a genesis at Google. It existed before Google did. JavaScript was written by Brendan Eich as the browser-side scripting language for the Netscape browser, originally based on Lisp I believe. It was not meant to be a joke.
dsirola 8y ago
I feel like The Blub Paradox should be the mandatory read here http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
dishwasher1999 8y ago
Correct me if I am wrong but does Go enforce the curly brace (opening) of a function definition be on the same line as the function's name?

206 points by Liriel 8y ago

Seems to be from Feb 2018 https://github.com/grimoire-ca/bliki/commits/master/wiki/dev/go.md https://github.com/grimoire-ca/bliki/commits/master/wiki/dev... But I have seen similar sentiments before that

jeffrallen 8y ago

Congratulations, you have an opinion.

triodan 8y ago

This must've been quite an old article, because lo and behold, nearly every single complaint on that page is being addressed with gusto by the Go community! Proposals on generics and error handling is well underway, and his complaints regarding GOPATH and the go get has been solved with Go modules. EDIT: As I expected, the linked page is written on Feb 2018[1], things indeed have changed a lot since then. [1]: https://github.com/grimoire-ca/bliki/commits/master/wiki/dev/go.md https://github.com/grimoire-ca/bliki/commits/master/wiki/dev...

xg15 8y ago
Sorry, but the language existed for how long? I remember hearing about the same complaints about generics and error handling years ago - and they got answers back then with about the same level of arrogant dismissal like the quote about syntax highlighting in the article. It's good if the community is at least starting to listen now, but I don't think that is sufficient evidence that the language is good.
- tinco 8y ago
  There is no discussion if the language is good, it's already quite convincingly proven it's good. The question was if generics would make the language even better. Some people think that's a no brainer, others are not so sure, and the latter group included the core maintainers. People use the language because it is good, I think at this point one can state that as objective fact. Once people use it, they'll complain when something is not as nice as it could be, like the error handling, and like the generics. I wonder if in 2000 people felt the way about Java 1.3 people feel about Go now. Java had a similar rise to prevalence, and it also lacked some features we now consider crucial, such as generics. I personally would never want to go back to Java 1.3. I feel I'd much rather code in Go instead, even if it lacks generics. But I still think it's worth considering if Go would turn out to become Java, if it now embraces generics.
  - edem 8y ago
    The language is crap. Just because people are using it does not mean it is good. Take a look at javascript. Same deal. You did not state any "fact"s why Go is good. Maybe it is good compared to Cobol or Fortran, but not compared to pretty much everything else.
    - tinco 8y ago
      Oh come on. People are forced to use Javascript, I don't think it would even exist today if it wasn't the only crossbrowser language. Almost no one is forced to use Go, and yet people flock to it. I don't feel I need to state the things that make Go good because it's already been done a thousand times, and everyone in this thread already knows why it is good. Have you ever built something in Go? I'm almost as productive in Go as I am in Ruby, and that was within a week of learning it. It's crazy good for a language that lacks so much expression.
      - skohan 8y ago
        To be fair, I feel like go's simplicity makes it easy to get small things up and running, but the pain comes when your project starts getting large. That's when additional abstractions are missed.
        tinco 8y ago
        I don't think Go should be used for larger projects. Apparently though the community disagrees because they're really adding generics.
        stephenbez 8y ago
        It's interesting, I feel like it's the opposite and Go excels at large projects. Compared to other languages, Go doesn't let you use as many abstractions, so writing code takes longer, but it is much more straightforward to read. I work at a >1000 person company that codes mostly in Scala, and some in Go, and would prefer to read unknown Go code any day. With the Scala I run into things like implicit parameters and 7 layer of inheritance, but the Go code is straightforward. Go is somewhat of a lowest common denominator language. You could out perform it with a small team of strong developers, but when once your project gets to a certain size, it's unlikely all of the developers will be strong.
- vonseel 8y ago
  Are you really arguing that the language is not “good”? Sure, there are things not to like about it, but the widespread adoption of Go as a systems programming language is evidence alone that it is a “good” language. Good is such an ambiguous term that I’m not sure it’s even worth using. For one person, only esoteric languages like Haskell are “good”, for another person, Python or Javascript are “good” enough.
  - 62747478182 8y ago
    > but the widespread adoption of Go as a systems programming language is evidence alone that it is a “good” language. Years ago PHP was the king of web development, and it was pretty awful in many ways (today is much better, though). People usually choice languages because of convenience, not because of how good they are.
eptcyka 8y ago
Judging by most responses form the Go team and/or the community around the language, it would seem that none of the issues listed in the article are actually valid. I.e. this is the _correct_ way to handle errors, sum types bring nothing, etc. Of course, things have changed since, but what does that say about the previously strongly held opinions of the team?
- grumpydba 8y ago
  > Judging by most responses form the Go team and/or the community around the language, it would seem that none of the issues listed in the article are actually valid Generics have been considered for years by the core maintainers. See Ian Lance Taylor's proposals. So you're either lying or not informed enough to be so assertive.
edem 8y ago
It it is underway it is not solved. Go is crap.
- akmittal 8y ago
  There are only two kinds of languages: the ones people complain about and the ones nobody uses. -Bjarne Stroustrup
  - eeZah7Ux 8y ago
    and Python.
  - joelfolksy 8y ago
    "There are two kinds of men: the ones complained about by their wives, and the ones who are single" - Me, before sleeping on the couch
  - edem 8y ago
    I don't see how this adds any value to the conversation.
    - akmittal 8y ago
      It says no language is perfect there are some or another compromise in all.
dragonwriter 8y ago
> This must've been quite an old article, because lo and behold, nearly every single complaint on that page is being addressed with gusto by the Go community! “Being addressed” = “not yet effectively addressed” = “still an issue”
deleted 8y ago
[deleted]

Sean1708 8y ago

> syntax highlighting, or as I prefer to call it, spitzensparken blinkelichtzen Google Translate reckons this means "peak parking", is that a correct translation? If so would somebody mind explaining what parking has to do with syntax highlighting? And if not, what is the correct translation?

PeterisP 8y ago
It's not something to be translated, it's a mock language. See https://en.wikipedia.org/wiki/Blinkenlights https://en.wikipedia.org/wiki/Blinkenlights
- Sean1708 8y ago
  Ah, thank you. I suppose there are no prizes for guessing which generation I belong to then?
rarestblog 8y ago
Not a native German, but probably this: "spitzen sparken blinken lichtzen" -> "pointed sparkles flashing lights"
- mirimir 8y ago
  Or maybe "brightly high-lighted pointers".
- ncmncm 8y ago
  No, it means "spitting sparks". Like you see coming out of the control panels in the original Star Trek, when they got shot by Klingons. I guess they remrnbered about circuit breakers when they built the later Enterprisen.
raister 8y ago
I would call it Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz but that's me.

CodinM 8y ago

Go does not like you either.

knan 8y ago

you don't have to like go, I'm not "liking it" per say, but what's the alternative if you want static typing/compile language, Java, well the compile time is to big for my taste, do a change wait 30 seconds, also it needs to munch ram, Net core could not get it to run.

gaius 8y ago
Have you tried OCaml? It’s higher-level than Go and easily produces high performance self-contained binaries.
- knan 8y ago
  be that, but the fact that I didn't heard of it, I just need to get shit done, not experimenting.
  - lucozade 8y ago
    > but the fact that I didn't heard of it Would suggest that you're not very familiar with the field that you're commenting on. Ignorance of a subject is perfectly fine. Everyone's ignorant of something. But flaunting your ignorance doesn't really strengthen your case appreciably.
klohto 8y ago
Rust
Dzugaru 8y ago
D or Rust?
- knan 8y ago
  D is a mess, Rust maybe no, but seeing how firefix is lossing browser share, I doubt in 5 - 10 years, there will be any company behind it anymore, same for kotlin, with vscode beating jetbrains.

i_phish_cats 8y ago

My first Go project was a PDF parser. Rewrote it in C a similar number of lines because Go's capacity for polymorphism is as primitive as in C.

martingxx 8y ago
Can you explain more about why you re-wrote? You seem to have said you rewrote from Go because it has poor polymorphism, into C which is equally bad in this regard. If you find some language feature important, surely you would not rewrite into a language that doesn't have that feature?
- i_phish_cats 8y ago
  C is equally bad, but it can be used anywhere -- it can be compiled into a dynamic lib and used in any language/framework, which is exactly what we did.
IshKebab 8y ago
True, though that doesn't seem like a good reason to rewrite it in C. A PDF parser in C sounds like a security nightmare, and now you have to deal with C's archaic build systems.

deleted 8y ago

[deleted]

gaius 8y ago

the language embodies an extremely rigid caste hierarchy of "skilled programmers" and "unskilled programmers," enforced by the language itself. Scala also has this approach, a sharp distinction between library-writers and application developers.

skohan 8y ago
Sacla, IMO, suffers from exactly the opposite problems as Go. It's flexibility lends itself to abstractions for the sake of abstractions, and in practice it sometimes seems more like a platform for showing off "cleverness" than for solving actual problems.
blablabla123 8y ago
In my opinion this is a misconception that I saw in other people approaching the language as well. The thing is: nobody should use "advanced" features. Using `reflect` should be reserved for exceptional case where it's not possible to solve the problem differently. This has been pointed out in the Go website and the mailing list bizillion times. That said, the language doesn't have many features. So if you want to show off your skill, it's probably by structuring the code concisely which can be challenging at times. Using reflect is actually the easy way out and most functions of that package can panic easily...
kjeetgill 8y ago
I know it's not quite the same thing, but never have I seen this more pronounced than in LaTeX.
kod 8y ago
Even if you believe that distinction, Scala is different because library writers can use the same language as application developers. That's not true of the divide between implementing and using Go.

danpalmer 8y ago

> I can't speak for Go's genesis within Google, but outside of Google, this underanalysed political stance dividing programmers into "trustworthy" and "not" underlies many arguments about the language. This summarises my opinion of Go that has been forming recently, that it's a replacement for Java. Java was the "safe" choice. Many engineers knew it, bad engineers couldn't be _that_ bad in it and would manage to produce something. They could be handed an architecture spec and implement it word for word without doing much translation to the Java language. But I don't think good engineers could "shine" with it. It normalised all engineers around some median of productivity, and made projects predictable. I believe Go is doing the same thing in some ways. It's not supposed to allow good engineers to find great ways of expressing complex architectures (however necessary that may be), it's designed to let engineers of all skill levels hit all problems with a Go shaped hammer and get something that looks inoffensive, boring and predictable. This is very unsurprising given that it came out of a large engineering organisation. Google have many engineers of a wide range of skill levels, and normalising engineering is more important than doing it better. I realise Google probably has a higher than average engineering ability, maybe far higher than average, but they still have a wide range, and I also include in this engineers who might be fantastic frontend engineers, who have to get stuck into some system software, for example.

dis-sys 8y ago
> But I don't think good engineers could "shine" with it. any concrete example on what a good engineer couldn't achieve when using Go in its intended domain/role?
- danpalmer 8y ago
  I've seen some amazing abstractions created in Rust and Haskell. Some of the Haskell ORMs are really nice abstractions over SQL for example, and there are many examples of Rust macros doing amazing things (I believe async/await was implemented as a macro?). Obviously you can write an ORM in Go, and you can write async code or code that will do whatever Rust macros can do, but the solutions will be less elegant, less re-usable, less useful. There's an argument to be made that this is all "clever" code, and that that is bad for maintainability. I'd agree they can be misused, but when used correctly they can level up how code is written in a very substantial way. Understanding the difference and when they are appropriate is what I really mean good engineering here.

hardwaresofton 8y ago

tl;dr - they said go was going to be simple. It is. Preface: It's perfectly OK to dislike languages, especially when you know of a better one that you're not using. I personally cannot help but think of all the better languages I could be using when I have to write some verbose bad abstraction in a less expressive/powerful language. Also, as I re-read this, the notion has struck me that I might be a Golang apologist. Also, as others have noticed, the Go 2 drafts mention just about every point in this article. That said, I think OP misses the point of Go -- it's meant to be simple, productive, and production-ready. Many of the points that OP makes about the mistakes I kind of shrugged at. > I've never met a language lead so openly hostile to the idea of developer ergonomics. I'm not sure I believe this C++/Java have similarly bad ergonomics, just in a different way -- they give/saddle you with abstractions that are easy to use wrongly and let you build a shit castle with amazing speed, while keeping yourself open to to a hornets nest of mistakes and pitfalls. Go sacrifices these features for a reason, and they stated it up front. That said, I do think they made a huge mistake not having proper union/sum types (AKA Algebraic Data Types/ADTs), but I can forgive them because building an excellent type system might have gotten in the way of their stated simplicity goals. > In Go's case, the language embodies an extremely rigid caste hierarchy of "skilled programmers" and "unskilled programmers," enforced by the language itself. I think this is a reflection of the Go, Google, and programming community in general. Whether it's the "10x engineer" or working-at-big-companies-means-you're-a-good-engineer mentality, this mindset is pervasive. It's the difference between a Senior Staff Software Engineer II and a Senior Engineer who just moved in from some other company -- it's trust. > Again, the Go team's "not our problem" response is disappointing and frustrating. Sucks that they didn't solve those problems up front, but I personally do not blame them for focusing on shipping, and fixing as they go. Honestly with the amount of work they've put in, they have built a runtime and language that have comparable performance and are more simple than Java + JVM. The JVM has millions of man hours dumped into it over decades. This is insane. Also, there's the fact that whether it's a complete farce or not, they have left open an avenue for changing the language. People could fork Go and change it if they really felt that strongly about this stuff. The thing is, people for the most part don't -- if you want a better type system go use (and convince your team to use) a better language. > The standard Go approach to operations which may fail involves returning multiple values (not a tuple; Go has no tuples) where the last value is of type error, which is an interface whose nil value means “no error occurred.” Yes, error handling in Golang is less than ideal, but I prefer the forcing of this as a default over the C++/Java approach -- this default makes it very hard to write code that doesn't deal with errors at the place you're most able to correct/work around them. Again, I'm also giving Golang a pass for not having errors-as-values in the way a language with a good type system would... because Go sacrificed their type system for simplicity. I don't think Go is a good programming language, but I do think it delivers on what it promises. It does what it set out to do -- be simple, productive, and production-ready (this is mostly because they hammered out all the bugs with tons of buy in from developers inside and outside google, and it's still not perfect of course). I've said it before and I'll say it again -- I think Go will supplant Java as the language most companies use on the backend in <10 years. Fundamentally, because of the developer fungibility benefits of Go -- it's going to be easier than ever to swap out Golang programmers than ever -- you won't even have to be a JVM master (which is normally one of the border points between Java amateurs and pros) to write good-enough code. Business thrives on good-enough code, not good code -- Golang is excellent for that, and gets proven more and more right every day with all the companies that are writing performant, statically compilable (thus easier to ship) code and just getting shit done. [0]: https://go.googlesource.com/proposal/+/master/design/go2draft.md https://go.googlesource.com/proposal/+/master/design/go2draf...

danpalmer 8y ago

An interesting tidbit I learnt from a former colleague: He wrote a small but non-trivial project in Go, and ended up re-writing in Python. Over time, he and his team measured both codebases and found that they had roughly the same number of bugs per line of code, but the Python codebase was 1/3rd of the lines of code, therefore had far fewer bugs. I wouldn't attribute this to inexperience either, this is one of the best engineers I've worked with.

fouc 8y ago
I think people write in Go because it's ostensibly faster in runtime (and maybe easier to deploy). It always was going to require more lines of code than languages like Python or Ruby, that's not a surprise at all?
- danpalmer 8y ago
  The fact it required more lines was expected. The fact that despite the additional tooling, type system, safety, etc, it had 3x more bugs than a Python implementation was unexpected.
  - IshKebab 8y ago
    3x more bugs that you know about. I wouldn't be surprised if Go's static type system just found more bugs, and the Python program had just as many bugs but you didn't happen to hit them at runtime.
    - bb88 8y ago
      I would assume he's talking about non-type system bugs. In 2018, most people won't look at a PR unless it compiles and the unit tests works.
      - danpalmer 8y ago
        I got the impression these were bugs that made it into a tracker of some sort, and I don’t think most engineers log “bugs” they encounter during local development before some notion of a release (be it to staging, the world, the master branch, whatever).

Almost2019 8y ago

It kind of comforts me in a way that someone as celebrated as Rob Pike is basicaly an imbecile.

lkramer 8y ago

As have already been pointed out most of these points ARE being addressed by the Go community, but it kinda reminded why I look towards Go 2.0 with some dread. Most of these things that he is asking for are things that will make the language harder to read, Generics and Exceptions (and not least this weird chimera that they have come up with in to Go 2 proposal last time I checked), will undoubtedly create popular libraries, which are almost impossible to understand for the uninitialised. The main strengths of Go is that it's easy to pick up for almost anyone with basic programming skills and be productive. The rigidity of the style, and the relative simplicity means that I can get a very fair idea about how almost any 3rd party library on Github works in an hour, and probably tweak the bits I may need to tweak. (The obvious exception to this is any library using a lot of reflection which can fulfill anyone's deepest desires to make code unreadable). C++ (which is my other main work language), have all these advanced features (often added in haphazard fashion late in the language specs), and I love writing C++ code, but I dread looking at other peoples code, because it can be almost impossible to figure out what is going on. I am tempted, when I see all these complaints about Go and comparing them to languages with different feature sets, to tell people that in that case they should use those. Of course, you might have the language dictated by an employer, but in that case there was probably a rationale behind choosing Go, and trying to change the language into being a clone of every other language will probably just result in someone else coming up with a new simple, statically typed compiled language, because I honestly believe the world needs that.

dnautics 8y ago
> The main strengths of Go is that it's easy to pick up for almost anyone with basic programming skills and be productive. This is passed around like gospel, but as a counterpoint my intern started this week at 30 hours a week. I taught him elixir from scratch, and today he finished writing a web server that serves GET and POST requests (which he didn't know) and stores states correctly. Also with low touch; he did much of the documentation reading himself and I was able to finish up about 1500 lines of code for a demo tomorrow. I feel like pretty much all modern languages except maybe rust are reasonably easy to pick up.
- 8y ago

crististm 8y ago

As Richard Hamming used to say ~"You can pretty much ignore those who discovered a field". Do not worry _at all_ that Rob Pike is finding colors juvenile. His opinion is just that. If it's worth anything, I'd put it in the same category as Linus's distaste for debugging tools.

tokai 8y ago
I love how childish it is to think that his personal experience of learning arithmetic, is worth anything regarding syntax highlighting. In some way it even undermines him. Why did he use coloured rods as a child? Because it helps reduce cognitive load! To define easier things as childish and harder things as adult, is elitist and hostile to other people.
- thatswrong0 8y ago
  Rob Pike also thinks abstractions like map, reduce, and filter are pointless because you can just write a for loop. Hence, we have Go.

deleted 8y ago

[deleted]

dragonfly02 8y ago

I am a total beginner in Go but I feel like the enforced uniform formatting is actually a good thing because it makes everyone's code consistent and more readable. It can be extremely difficult to read other people's code if they use a totally different style even if both of you are good at the same language. And I feel there is litter point in telling people not to use one language simply because you don't like it. Everyone is different, if you don't like it just use something you like (maybe change job if you have to use it at your current job). There is and will never be a language that EVERYONE likes. Oh did I forget javascript? LOL...

tinco 8y ago
Yes it is, I don't think anyone disagrees with that enforced formatting is a good thing.
- dragonfly02 8y ago
  Why am I not surprised:D
spicyusername 8y ago
Can't agree more. It's one thing to have a healthy debate about how to improve a language. It's another to keep circle jerking over these anti-x blog posts.

abtinf 8y ago

For quite some time, I’ve taken to wrapping the most common err case with a simple function: func dieOnErr(err error) { if err != nil { log.Fatal(err) } } It makes the code much easier to read (due to efficient use of vertical space) and much less tedious to write: dieOnErr(foo()) _, err := bar() dieOnErr(err)

skohan 8y ago
What kind of application would you use this in? Just exiting on every error seems you're just punting the whole problem of error handling, and wrapping every fail-able function in another function doesn't seem like the best thing for readability either. Also this doesn't really solve the problem sited in the article: it requires that all your functions return exactly two values with the error in the second place. What if you need to return two non-error values?
- abtinf 8y ago
  I primarily use this in three areas: Command line tools: if any part of the command fails, you usually don't want to continue, unless it is a long-running batch process. In that case, I usually also write a logOnError() function to keep track of problematic work items. Servers: during server initialization, there are many circumstances where it doesn't make sense to continue, such as template compilation failure or failing to open the socket. Other: I use dieOnError anywhere it would otherwise make sense to use panic() - situations where continuing the program would mean running in an unknown state, like out-of-memory conditions. I've built systems with complex error handling before, but my teams have always run into the problem of trying to reason about complex, unpredictable program state. If the requirements can allow for the program to fail fast (as you say, "punting the whole problem"), then the code itself can be kept much simpler and easier to reason about. When errors do crop up, it is easier to look at logs to debug a simple program (or infrastructure issue) than to debug a complex program where you aren't sure how earlier errors affected state. In languages with exceptions, this is sort of the default - if you don't handle an exception, the program will crash. Often there will be a main level exception handler that logs otherwise uncaught errors. But a problem in Go is that programs are default-alive on errors. If you don't check the error status of every single function call that returns errors, then the program can get into unknown state. So in production code, especially code that just combines a few libraries, every function call ends up taking 3 or 4 lines (1 line of call and/or 3 lines of error checking). Regarding the number of return values, my dieOnError/logOnError only handles functions that return error and nothing else. If the function returns multiple values, I first call it, then call dieOnError with the err: foo, bar, err := baz() dieOnErr(err) //assume foo and bar are valid I suspect I could write a variadic error checking function that assumes the last parameter is error: func dieOnError(a ...interface{}) { //do some reflection magic? } func foo() (bar int, baz int, err error) { ... } //maybe needs some type assertions or something? bar, baz := dieOnError(foo())

divan 8y ago

This article is a bit outdated and has invalid claims and a lot of ad hominem and other fallacies, so I'd recommend to stick to the textbook for complaining about Go for maximum clicks: https://divan.github.io/posts/go_complain_howto/ https://divan.github.io/posts/go_complain_howto/

hu3 8y ago
You're not wrong. The article is at least 10 months old: https://old.reddit.com/r/golang/comments/7zmt8u/i_do_not_like_go/ https://old.reddit.com/r/golang/comments/7zmt8u/i_do_not_lik...

tempodox 8y ago

Good article, and I admire the author's patience. You don't bind yourself to the inner politics and philosophy of something like Google except when you are Google. Anyone's good taste should have prevented them from using a language with such severe and ludicrous restrictions, but that filter obviously didn't work.

yazr 8y ago

Off topic: Can i ask Go developers if the compiler is fast enough (for now), or is this still a (major) pain point ? Disclosure: i work on build systems and optimizers.

remus 8y ago
What do you mean by 'fast enough'? As compiled languages go I think it's generally accepted that go compiles relatively quickly, especially for large projects with lots of dependencies (as it has saner dependency rules than c/++).
hu3 8y ago
> still a (major) pain point What? Go compiler is blazing fast. It's one of the fastest compilers of major languages if not the fastest. Some discussion from 2016: https://stackoverflow.com/questions/2976630/how-does-go-compile-so-quickly https://stackoverflow.com/questions/2976630/how-does-go-comp...

oxplot 8y ago

I've learnt that programming languages, just like food and fashion, are a matter of taste to a high degree. You can point at awful smelling, too sugary meal and call it crap. Someone else spends years perfecting it. One's taste however can change: food with high sugar leads to heart disease and diabetes, so I better stop eating that favorite dish of mine. You keep doing that for a while and taste of sugar (or salt, or fat) becomes disgusting. Statements like "Go is crap, it has no generics" originate from one's taste in programming languages so there is no arguing with that. However, talks about what generics (or exceptions etc.) does to the health of the programs you write that span time and other contributors, are no longer subjective matter, but an argument worth having. This is, where I think, Go's strength comes in: its careful development process that puts programs' and programmers' health at the top of the priority list. Health is not the same as comfort. Taste of a dish you've had for years is comforting. You're not going to feel comfortable when the ingredients you've come to expect are taken away. But if you can get past that, you may end up living longer and healthier. Similarly, your programs may become more maintainable and long lasting. No one, who is familiar with the philosophy and motivation behind Go, can claim that what I've said above is false. You can say that Go team is slow in progress, but that's what methodical and evidence based approach is like: slow. You need time to experiment, learn and evolve. You other favorite languages act like the general public who at hearing in the news that "coffee is good for you", starts drinking 10 cups a day. Go's approach is more along the scientific way.

vram22 8y ago
>I've learnt that programming languages, just like food and fashion, are a matter of taste to a high degree. You can point at awful smelling, too sugary meal and call it crap. Someone else spends years perfecting it. Programming languages ... food ... fashion ... taste ... Time to pull out that old chestnut: https://en.wikipedia.org/wiki/De_gustibus_non_est_disputandum https://en.wikipedia.org/wiki/De_gustibus_non_est_disputandu... I agree.
deleted 8y ago
[deleted]
opless 8y ago
Sugar is not a direct cause of diabetes. So you might want to rethink your analogies in future. https://www.diabetes.org.uk/guide-to-diabetes/enjoy-food/eating-with-diabetes/diabetes-food-myths/myth-sugar-causes-diabetes https://www.diabetes.org.uk/guide-to-diabetes/enjoy-food/eat...

luord 8y ago

I can get past most of Go's weird idiosyncracies... Except for the odious error handling. Reading go code makes my eye twitch, and the biggest reason is its error handling. And sadly I'm now stuck with it, and not even the changes for Go 2 are encouraging because, even though its new error handling is saner, it is still needlessly different for the sake of it.

weberc2 8y ago
I quite like Go's error handling. It adds visual structure and makes it apparent which things can fail and how they're handled. It's a welcome relief from the likes of Python where you only see (and consequently think about) the happy path. This is definitely a big driver of our 500s in our production Python services. While there are many who are genuinely aggrieved by the number of keystrokes, I think a lot of people are annoyed at error handling in Go simply because you have to think about error handling.
- ernst_klim 8y ago
  >simply because you have to think about error handling. until you write x, _ := some_code () Besides, Go errors are used in pair with the return value, so you have to check 4 possible combinations of value/nil and error/nil instead of 2 due to the absence of sum types. Oh, and no generics, so your errors are either string or you have to check the interface in runtime which and can't statically check which exact errors could your code return. Oh, and no monadic chains/exception mechanism, so feel free to write x, err := if (err != nil) { return err } y, err = ... if (err != nil) { return err } instead of do x <- fun1 () y <- fun2 () ... and then just check the proper subset of possible errors, carefully inferred by the type system. There are a bunch of different possible approaches for error handling: exceptions, monads, erlnags failures as possible case, Go crowd had just invented the worst and least error-prone one.
  - weberc2 8y ago
    > until you write Yeah, you can definitely opt out of it and there are even cases where the compiler doesn't guarantee that you're handling the errors, but assuming you're making a good faith effort to adhere to conventions, then you're thinking about your errors. > Besides, Go errors are used in pair with the return value, so you have to check 4 possible combinations of value/nil and error/nil instead of 2 due to the absence of sum types. No, you don't. If the error is not nil, there's an error. Sum types would be nice, but they wouldn't reduce the number of checks, they'd just formalize the idiom. > Oh, and no monadic chains/exception mechanism, so feel free to write I'm fine with this. Monads are hard for people to understand, and I'm not playing code golf... > Go crowd had just invented the worst and least error-prone one. I don't think it's the least error-prone, but it's not bad.

weberc2 8y ago

This article lists a few issues, some valid, others not, but all exaggerated. No mention whatsoever of the many advantages Go brings much less a comparison between the pros and cons. There are a lot of interesting critiques of Go; sadly, this isn't one of them.

black-tea 8y ago

I've done lots of work in C, Python and Common Lisp. I've done a fair bit in go and for me it's just not fun to use. I feel like I'm playing in a little sandbox with a few prescribed tools.

kureikain 8y ago

These are author opinion and I respect and understand where he came from. People should have ability to share about their opinions with the world. That's great. But argue about the syntax highlight are silly to me. Argue about leadership though on that syntax highlight is fine. Below are mine. Let's look at Go from 2 angles: - Go the language - Go the leadership Go, the language is great to me. In the article, OP talk about `go get`, GOPATH, Error Handling. To me they are fine. I love `go get` because it was so easy to install binary that way and get update too. It fall short when have conflict because you have a single global tree which thing depend on. This is obviously not gonna work in long run, and in fact they always said they use it different way at google and expect community standarize and find ways through it. Which eventually lead to where we are now with go module. But let's take a step back. Let's say if everything work great, do you like `go get`. It's just feel like `homebrew` and a game changer to me. What if we can abstract everything out, make `go get` works great as it's without population the global tree. Technologies will evolve. Look at how JavaScript evolve and become a great language and platform as it's right now. Give Go time. Same with error handling. Exception is just as annying too. You either handle it or just swallow up or let's it buble up. I prefer Go style. Read Go code force me to think about error right at that point. I would love Go to have thing like Result or Maybe :( instead of return multiple value which is just a convention right now. Go bring lots of toolchain and interesting idea. gofmt gofix etc... However, Go the leadership isn't up to Go the language. I think they feel to the trap when they made a language which many big project use(influxdb k8s docker...) and they get defensive when people talk about Go or criticize it. Look at how friendly Jose of Elixir or Matz of Ruby is. I would love Go leadership reach that. I read in other thread where someone say `Golang` and one of Go core dev just dismiss because he written `Golang` instead of `Go`. I think eventually the leadership will change. Go is opensource after all. And we will see a day where Go is great both at language and leadership.

kerng 8y ago

Been working with Go a bit and also reviewed and saw tons of production code at places. The one thing that stands out is how messy and unorganized code is written often. It's more of a "write only" language to me it seems. Java or Python are much more readable.

tmaly 8y ago

I was just having a discussion yesterday with a co-worker on Go. He deals with security and encryption and does not do development work. While I enjoy Go for its strengths, it was his opinion that Go did not offer anything above and beyond other languages.

kjeetgill 8y ago
Well yeah, I'd agree that he wouldn't. Most of the specialness comes at the application level: He gets nothing out of specific blend of garbage collection, allocation options, typing, and green threading that sorta defines go.

watergatorman 8y ago

If anyone who has tried Modula-2, Go appears to be very close, at some core level, to m2, but m2 has a cleaner syntax, IMHO?

atombender 8y ago
Go was influenced by Modula-2, but even more so by Oberon, which one of Go's designers, Robert Griesemer, worked on with Wirth at ETH Zürich. Oberon is in many ways a minimalist version of Modula-2.

sershe 8y ago

One thing I definitely dislike are value/reference semantics, where arbitrary nested object structures are passed by value by default, but maps and slices are somehow magical and are passed by reference. I don't even care which one it is, but either everything non-primitive should be by reference by default, or by value.

hu3 8y ago
Nope. Everything is passed by value including maps and slices. Here's an article from 2011 that might help you understand that: https://blog.golang.org/go-slices-usage-and-internals https://blog.golang.org/go-slices-usage-and-internals

sebchris 8y ago

My expectations surrounding Go were born from my intense admiration for Python, which has grown so much as a language from its humble genesis at Google and proudly stood the test the time. Needless to say, I was beyond disappointed. Barring its concurrency module, which is some half-backed mixture of STM and async, I was astonished at the absurdity of the language. It reminds me of JavaScript, which as I recall was originally written as a sort of joke. So yeah, Go's like a bad joke.

dustycat 8y ago
Python did not have a genesis at Google. It existed before Google did. JavaScript was written by Brendan Eich as the browser-side scripting language for the Netscape browser, originally based on Lisp I believe. It was not meant to be a joke.

dsirola 8y ago

I feel like The Blub Paradox should be the mandatory read here http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html

dishwasher1999 8y ago

Correct me if I am wrong but does Go enforce the curly brace (opening) of a function definition be on the same line as the function's name?