I Do Not Like Go

https://grimoire.ca/dev/go

by Liriel • 8 years ago

206 210 8 years ago

grimoire.ca

SideburnsOfDoom3• 8 years ago

Seems to be from Feb 2018 https://github.com/grimoire-ca/bliki/commits/master/wiki/dev...

But I have seen similar sentiments before that

triodan• 8 years 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...

xg152• 8 years 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.

tinco6• 8 years 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.

vonseel2• 8 years 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.

eptcyka• 8 years 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• 8 years 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.

edem4• 8 years ago

It it is underway it is not solved. Go is crap.

akmittal2• 8 years ago

There are only two kinds of languages: the ones people complain about and the ones nobody uses. -Bjarne Stroustrup

dragonwriter• 8 years 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”

Sean17082• 8 years 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?

PeterisP2• 8 years ago

It's not something to be translated, it's a mock language.

See https://en.wikipedia.org/wiki/Blinkenlights

Sean17082• 8 years ago

Ah, thank you. I suppose there are no prizes for guessing which generation I belong to then?

rarestblog• 8 years ago

Not a native German, but probably this:

"spitzen sparken blinken lichtzen" -> "pointed sparkles flashing lights"

mirimir• 8 years ago

Or maybe "brightly high-lighted pointers".

ncmncm2• 8 years 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• 8 years ago

I would call it Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz but that's me.

TuringTest• 8 years ago

Du must be Deutsch

keedon• 8 years ago

This is mock German - Google translate is probably taking spitzens parken as peak parking. But it is probably a refernce to blinkenlights https://en.wikipedia.org/wiki/Blinkenlights

abrawill• 8 years ago

I'm not German, but I'd say it's close to: bells and whistles.

Or more directly: sparkles and flashing lights.

Seems like this Wikipedia entry is relevant: https://en.wikipedia.org/wiki/Blinkenlights

This was entertaining: ": ACHTUNG! ALLES TURISTEN UND NONTEKNISCHEN LOOKENPEEPERS! DAS KOMPUTERMASCHINE IST NICHT FÜR DER GEFINGERPOKEN UND MITTENGRABEN! ODERWISE IST EASY TO SCHNAPPEN DER SPRINGENWERK, BLOWENFUSEN UND POPPENCORKEN MIT SPITZENSPARKEN. IST NICHT FÜR GEWERKEN BEI DUMMKOPFEN. DER RUBBERNECKEN SIGHTSEEREN KEEPEN DAS COTTONPICKEN HÄNDER IN DAS POCKETS MUSS. ZO RELAXEN UND WATSCHEN DER BLINKENLICHTEN."

Seems to fit what our author was going for too.

Traubenfuchs• 8 years ago

German native speaker here with lots of assumptions.

For the first word, "spitze" can be "peak", but also the pattern/cloth as seen when you google doily. In this context, that's probably what he means. That means the "s" belongs together with the "parken", making it the English "spark". "sparken" could be "making sparks"

For the second word "Blinklicht" ist "blinking light", "Blinklichtchen" would be the diminutive, it's probably written "Blinkelichtzen" to make it look ever more German.

He appears to be kind of an unpleasant person.

rawland• 8 years ago

: ACHTUNG!

    ALLES TURISTEN UND NONTEKNISCHEN LOOKENPEEPERS!
    DAS KOMPUTERMASCHINE IST NICHT FÜR DER GEFINGERPOKEN UND 
    MITTENGRABEN! ODERWISE IST EASY TO SCHNAPPEN DER 
    SPRINGENWERK, BLOWENFUSEN UND POPPENCORKEN MIT 
    SPITZENSPARKEN.
    IST NICHT FÜR GEWERKEN BEI DUMMKOPFEN. DER RUBBERNECKEN 
    SIGHTSEEREN KEEPEN DAS COTTONPICKEN HÄNDER IN DAS POCKETS MUSS.
    ZO RELAXEN UND WATSCHEN DER BLINKENLICHTEN.

"This silliness dates back to least as far as 1955 at IBM and had already gone international by the early 1960s, when it was reported at the University of London's ATLAS computing site."

source: https://en.wikipedia.org/wiki/Blinkenlights

YeGoblynQueenne8• 8 years ago

Heh. Google translate actually recognises some of those, er, terms:

  ATTENTION!

     ALL TOURISTS AND NONTEKNISH LOOKENPEEPERS!
     THE COMPUTER MACHINE IS NOT FOR THE GEFINGERPOKEN AND
     CENTER DIG! ORWISE IS EASY TO SNAP THE
     SPRINGENWERK, BLOWENFUSEN AND POPPENCORKEN WITH
     TIP sparken.
     IS NOT FOR TRADE IN STUPID HEADS. THE RUBBER TIPS
     SIGHTSEARS KEEP THE COTTON PICK HANDS INTO THE POCKETS.
     ZO RELAXING AND WATCHING THE FLASHING LIGHT.

I'm kind of amazed that it can go even that far. But mostly, I'm amazed at the fact that I can just pick up and read a completely made-up language, or a severely garbled real language, depending on your point of view.

We got some way to go before machine translation can match human language abilities, eh.

em-bee3• 8 years ago

those seem to be based on german words. in german that reads as: pointy sparks, blinking lights.

knan4• 8 years 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.

gaius2• 8 years ago

Have you tried OCaml? It’s higher-level than Go and easily produces high performance self-contained binaries.

knan4• 8 years ago

be that, but the fact that I didn't heard of it, I just need to get shit done, not experimenting.

klohto• 8 years ago

Rust

Dzugaru• 8 years ago

D or Rust?

knan4• 8 years 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.

skohan10• 8 years ago

Swift

vbezhenar2• 8 years ago

You can use Java in a lightweight manner. That's what I'm doing lately. Use built-in com.sun.net.httpserver or add undertow dependency. Enough for HTTP, uses few MB memory (I'm running one app on a 256 MB OpenBSD server), starts in a fraction of second. Use JDBC without all those ORM nonsense, you'll have somewhat verbose but pretty obvious code. It's pretty productive environment for me.

vram223• 8 years ago

Use built-in com.sun.net.httpserver or add undertow dependency.

Haven't used Java for a while, but IIRC, (some of) those star.sun.star classes (as opposed to star.java.star ones) used to be mentioned as liable to be deprecated, so not to be relied on (long term at least). Is that still the case now?

repolfx• 8 years ago

You shouldn't need to wait 30 seconds on any change to a Java app. It supports incremental compilation. My own projects usually take 2-3 seconds to recompile and launch, and they're large.

i_phish_cats2• 8 years 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• 8 years 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_cats2• 8 years 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.

IshKebab2• 8 years 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.

gaius2• 8 years 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.

skohan10• 8 years 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.

kjeetgill4• 8 years ago

I know it's not quite the same thing, but never have I seen this more pronounced than in LaTeX.

blablabla123• 8 years 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...

kod• 8 years 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.

danpalmer11• 8 years 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• 8 years 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?

danpalmer11• 8 years 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.

pm90• 8 years ago

I don’t think this theory holds much water.

Go code is very opinionated but still flexible; it seems to be C but with superpowers and great tooling out of the box. A whole bunch of complex software is written and in production using go; I don’t think it limits the productive/clever engineers from doing what they would do with Java.

danpalmer11• 8 years ago

Interesting. You could be right!

My experience with Go is very limited, but I tend to see interesting abstractions built with other languages. Ruby, Haskell, Swift, JS, even some Python – I see engineers building DSLs and architectures that strongly fit particular use-cases. In Go, everything just tends to be functions and structs, and the lack of expressiveness make it difficult to do anything with nicer ergonomics.

I would agree that it is C with superpowers in some respects though.

A whole bunch of complex software is written and in production using go

This is true, but my point isn't that you can't write the software, just that it might have been better code in another language (easier to understand, reason about, more reliable, more maintainable?). The biggest benefit along these lines that Go seems to have is that lots of other software is written in it, which comes back to a similar argument as Java.

YeGoblynQueenne8• 8 years ago

> A whole bunch of complex software is written and in production using go

And also in Java, javascript, COBOL, FORTRAN, R, and many other languages that are associated in software developer circles with all sorts of developer-unfriendly nastiness. The truth is that most programming languages we use today are a bit shit, because they have to make hard choices to overcome limitations of hardware and, well, human brains. In my view, the real reason programmers are highly valued is because we can endure the hardship of using those primitive tools and make them shine despite their inherent limitations, not because we are so brilliant we can't keep ourselves from programming the equivalent of the Capella Sistina in the process of gluing together a bunch of library interfaces.

Otherwise- well, you can write complex software in Brainfuck, if you really put your mind to it. Hell, a whole bunch of very complex software is written in assembly languages. So what? That's a testament to the ability of humans to express themselves in very restricted formalisms, not to the quality of those formalisms.

gralx• 8 years ago

... it's a replacement for Java.

Kotlin is the Java replacement I keep reading about.

danpalmer11• 8 years ago

My point isn't a technical one, but more a cultural/political one.

hardwaresofton5• 8 years 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/go2draf...

nurpax• 8 years ago

made a huge mistake not having proper union/sum types (AKA Abstract Data Types/ADTs)

Did you mean algebraic data types?

hardwaresofton5• 8 years ago

Yes I definitely did, thanks for the catch -- edited the comment.

skohan10• 8 years ago

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.

So what this immediately makes me think is what about Swift? Swift has many similar goals as far as avoiding the common pitfalls of C++ and Java, and moving more of the work of problem detection from runtime to compile-time, but it manages to do so while embracing the advancements in programming language design over the past 20 years. The go way seems to throw out an awful lot of baby out with the bathwater.

hardwaresofton5• 8 years ago

I would love to hear from someone who actually uses Swift day to day, but everything I read about Swift disappoints me (in the "why was that even a problem in such a modern language??" sense) along with some brief conversations with an iOS developer from a startup I was at for a while. I don't have any specific blog posts I can point to right now but a more defensible point might be why would I pick Swift over Rust, if I wasn't forced to (by doing recent iOS development)?

Features seem to be very similar, but without Rust has/is:

- A more expressive compiler + type system

- Better memory management via the borrowing/ownership paradigm

- More F/OSS friendly, community steered

- Usable from embedded (no runtime) to web services tiers (maybe I just don't know a lot about embedded Swift outside of iOS)

- No cost abstractions

Swift is indeed a huge step forward from Objective-C or some other languages like C++/Java but I don't personally try and use it outside iOS because there are better options. If I'm going to bring a long a runtime why not use Haskell or Golang?

These days if I get to choose my language I spend my time trying to decide between Rust or Haskell -- then again most of my projects are small, and make no money.

danpalmer11• 8 years 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• 8 years 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?

danpalmer11• 8 years 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.

defertoreptar• 8 years ago

So during the rewrite, he had the providence of the go codebase to look back on, and the Python version still had as many bugs per lines? That sounds like an argument for go, if anything.

danpalmer11• 8 years ago

This is true, I don't know the specifics, but I would trust that my former colleague wouldn't make such a claim based on such incorrect data. My guess these bugs were "code" bugs rather than "product" bugs, if that distinction makes sense.

theonemind• 8 years ago

From what I've seen (though I can't find any sources to back it up, apply the appropriate amount of salt), having a number of bugs or defects proportional to the lines of code constitutes one of the robust findings in that pretty muddy area of the world (Does OO increase productivity? Static typing superior? .. at least we know, I think, that bugs run in proportion to lines of code, regardless of language)

weberc28• 8 years ago

I have the opposite experience. I've rewritten several services from Python to Go; while Go ends up being more lines of code, the type checker actually found far more bugs. When I'm ready to deploy the new service, I'll route a copy of the production traffic to the new service and observe differences in behavior, and the Go version (despite being very young) typically has ~10 percent of the bugs (_especially_ in error paths). Further, the performance usually improves by one or two orders of magnitude, depending on whether or not the old Python code was async (async Python is even buggier than sync Python in our experience) and how CPU-intensive the program was. Lastly, I iterate much more quickly in Go despite having more experience in Python, entirely because the type checker catches silly errors that I would otherwise have to find and fix in a test loop.

fierro2• 8 years ago

Just having strong typing alone has reduced the number of bugs for me, speaking anecdotally

lkramer• 8 years 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• 8 years 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.

spicyusername4• 8 years ago

I taught him elixir from scratch, and today he finished writing a web server that serves GET and POST requests

This is an anecdotal sample size of 1. If something is "gospel" there is usually a real truth behind it that one should try to understand.

I feel like pretty much all modern languages except maybe rust are reasonably easy to pick up

Simply not true for most of the industry. Perhaps in some corners of the silicon valley monoculture machine, but most of software engineering is comprised of a diverse range of people with diverse backgrounds and skill sets for which mastering a new programming language is time consuming.

eitland2• 8 years ago

Hehe, I haven't tried Elixir, so I cannot say.

FWIW I taught a 16 y.o. intern enough perl and vba to automate what was a very non trivial reporting job.

He did it in 14 days, after hours only (attending school at week days) and he only asked me a few times.

Doesn't mean I'll say perl is easy (I cannot even understand my own perl code from back then anymore), only I got a really really bright intern.

It might be the same in your case but I obviously cannot say for sure since I've never programmed Elixir or met your intern :-)

xg152• 8 years ago

... often added in haphazard fashion late in the language specs

Agreeing with this point. I feel, there seems to be a vicious cycle in "pragmatic" language design that goes something like this:

1) Let's design language n. It will be like language n-1 in spirit but much more lightweight and without all the historical baggage!

2) In particular, let's leave out generics. They have been a never-ending source of bugs and confusion in n-1 development, with all the gotchas and awkward special cases you need to remember - and we can't really think of any compelling real-world use-cases for them anyway...

(... some years later ...)

3) Sigh... the community keeps pestering us about generics... so alright, we'll think about some way to add generics to the language so you guys finally stop complaining.

4) Behold: We made n', a language extension to n with generics. However, because all of our existing ecosystem is written in the old way, without generics, we had to prioritize backwards compatibility over all else during the design. That's why you'll have to live with counter-intuitive behavior A, awkward special case B and arbitrary-looking restriction C when using them. We're sorry, guys!

5) Let's design language n+1. It will be like language n in spirit but much more lightweight and without all the historical baggage! Especially generics!

How about for a change designing a language where generics are part of the initial design instead of just getting bolted on later?

SideburnsOfDoom3• 8 years ago

How about for a change designing a language where generics are part of the initial design instead of just getting bolted on later?

Muttering about Rust at this point.

Exactly. Generics being there from the get-go makes a difference to the language design. The most visible example being how values are returned from functions, when the result is tuple return for success case or error case. Bolting that on later is unlikely to work well.

https://doc.rust-lang.org/std/result/

eitland2• 8 years ago

Well, C# and TypeScript both seems to have gotten a whole lot more right (I'll cut TypesScript some extra slack here since it has to take extra care not to step on JavaScripts toes now or in the future.)

crististm• 8 years 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• 8 years 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• 8 years 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.

dragonfly022• 8 years 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...

tinco6• 8 years ago

Yes it is, I don't think anyone disagrees with that enforced formatting is a good thing.

dragonfly022• 8 years ago

Why am I not surprised:D

spicyusername4• 8 years 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.

abtinf2• 8 years 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)

skohan10• 8 years 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?

abtinf2• 8 years 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())

divan2• 8 years 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/

hu33• 8 years ago

You're not wrong. The article is at least 10 months old:

https://old.reddit.com/r/golang/comments/7zmt8u/i_do_not_lik...

tempodox• 8 years 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• 8 years 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• 8 years 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/++).

hu33• 8 years 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-comp...

oxplot• 8 years 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.

vram223• 8 years 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_disputandu...

I agree.

opless• 8 years 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/eat...

Valmar2• 8 years ago

Right ~ sugar, namely fructose, is an indirect cause of diabetes.

Fructose over-consumption -> insulin resistance -> diabetes. Heart disease follows.

Cholesterol is just the scapegoat for fructose over-consumption's horrifying effects. Cholesterol is used by the body to try and patch up all of the damage it causes. Cholesterol is used almost literally everywhere in the body, from hormones, to cell linings, etc.

luord• 8 years 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.

weberc28• 8 years 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_klim7• 8 years 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.

kerkeslager• 8 years ago

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.

Okay, so let's say you're using Python. You get some 500s in production, but if you're written things in a clean fashion, they provide clear error messages and you can fix them quickly. 500 is error handling--not ideal, but it's also probably better than the "Pretend this error didn't happen" type error handling that programmers write when they are forced to handler the 80% of possible errors that will never occur.

And if you need a high-reliability system where 500 errors aren't acceptable, then Go is the wrong language, period. Its static type system is a joke and it doesn't provide any real formal verification beyond that.

weberc28• 8 years 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• 8 years 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• 8 years 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• 8 years 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• 8 years 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.

kjeetgill4• 8 years 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• 8 years 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?

atombender4• 8 years 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• 8 years 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.

hu33• 8 years 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

sebchris• 8 years 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• 8 years 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• 8 years ago

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

dishwasher1999• 8 years 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?

I Do Not Like Go

Related Stories