
Go makes it easier to write correct, clear and efficient code - csmnils
https://yourbasic.org/golang/advantages-over-java-python/
======
founderling
I love programming languages. And I love to reason about them. When I see an
article comparing languages, I'm all in.

So I clicked on this one. Started skimming through it, looking for _code_.
Found none. Came back here to share my disappointment.

I'm always confused about articles that talk about code and have little code
to show. Are there programmers who enjoy reading them? Or are these articles
made for non-programmers?

Another thing that always throws me off is fluff. The article starts with
"Choosing a programming language isn’t easy.". What does this add to the
article? It immediately makes me think the author stuffed this article for no
reason. So I have to skim even faster to not being cheated of my time. Is
there anybody out there who thinks having the article prefixed with "Choosing
a programming language isn’t easy." makes it _more_ valuable?

~~~
sacado2
This article deals with "big picture" aspects, not specific syntactic details,
so there is no reason for it to include code.

Backward compatibility, compilation speed, circular dependencies, small vs big
specs, etc. What code do you want to show about these aspects?

> The article starts with "Choosing a programming language isn’t easy.". What
> does this add to the article?

It's an introduction. It's a very common writing technique. You don't start
with the core content of the article, you start with a paragraph or a sentence
about _why_ you wrote the article in the first place. You did the same with
you "I love programming language" opening.

~~~
founderling

        Backward compatibility, compilation speed,
        circular dependencies, small vs big specs,
        etc. What code do you want to show about
        these aspects?
    

Code that shows these aspects. What broke in Java because of language changes
and why. How handling circular dependencies in one language makes code uglier
then in the other. Examples of the specs.

    
    
        You did the same with you "I love
        programming language" opening.
    

That I love programming languages and to reason about them is an information
about myself that the reader does not know in advance. That choosing a
programming language is not easy is public knowledge that the readers already
know. At least if they are programmers.

That is the point of my post. Asking who the target audience is. And how it is
different from myself.

~~~
chrismorgan
Please do not use code formatting for quotations. Use the old _de facto_
standard of a “> ” prefix.

~~~
founderling

        Please do not use code formatting for quotations.
    

Why not? I think it looks pretty good.

~~~
ColinCochrane
Code formatting is difficult to read on mobile because the text doesn't wrap
properly. You end up having to scroll horizontally to read it all.

~~~
Fnoord
FWIW, not only on mobile.

------
siscia
I do like go, but really this arguments start to be a little unprofessional if
you ask me.

All those arguments are fine and correct in small projects or libraries, there
go is perfect.

But they really don't hold on big project like docker or containerd.

While it is clear what lines of code does, at a tactical level, it is
extremely difficult to follow what happen in the big picture, the strategic
level. Where the values comes from and where they go? When? How and why?

Honestly I keep seeing this in all big go project, despite the lack of
generics.

Again if you need a small micorservice, use go! It is the best option right
now. But I wouldn't bet any big codebase on it.

~~~
codr7
And yet, people are building big code bases on top of both C and Go without
generics all the time. Like C, Go lacks support for elaborate abstractions.
It's still a better C for many problems.

~~~
giornogiovanna
People have probably reinvented generics thousands of times in C, mostly using
function pointers or macro hacks.

Edit: And the intrusive data structures commonly used in C are way more
complicated than the equivalent generic code (in my opinion).

[https://lwn.net/Articles/184495/](https://lwn.net/Articles/184495/)

~~~
rumcajz
The question of intrusive containers is kind of orthogonal. You can implement
intrusive containers using generics. Aslo, kernel code would use intrusive
containers even if there were easy-to-user non-intrusives available directly
in C. The reason, of course, being that with intrusive containers you can
avoid huge amount of memory allocations.

------
lifeisstillgood
Is it just me - but writing correct and clear code depends less on the
language and more on the problem being solved and the domain - and ones
_understanding_ of both.

Someone with a detailed grasp of both can write clear code in C, Haskell,
Python even BASIC

If you don't grasp either and have no time to be allowed to do it, no language
will save you.

~~~
mattnewport
Given a certain level of understanding of the problem, certain languages can
make it easier to write clear and correct code. For example, code that does
physics or 3D graphics calculations is clearer in a language that can
represent matrices and vectors as types providing the expected operations
(e.g. C++ over C) and if the code involves physical quantities it can be
easier to enforce correctness in a language that supports units in the type
system.

~~~
jcora
This. I hate this relativism about the merits of languages. There's an entire
field of study dedicated to that and just because you can write a web app in
all your languages of choice doesn't actually invalidate the vast conceptual
differences that exist and have real effects on how you program

~~~
majkinetor
what field of study?

~~~
vraivroo
Programming Language Theory

------
jeswin
Go succeeded because it compiles to native code, has good performance and an
efficient standard lib - but in spite of being a terrible programming
language. There are a great many programmers who cared about producing great
software rather dwell on the quality of PLs, and for these people Go hit a
particular sweet spot.

I have really tried to like Go, but the imperativeness is just something I
struggled with. Even good Go code is littered with breaks, mid-function
returns and imperative loops. For those who want cross-platform native code
but find Rust too complicated, hopefully C# will fill the void once CoreRT
ships.

~~~
skybrian
Hmm, I've never heard anyone else object to mid-function returns. Usually
guard clauses are considered a good thing. What's your objection to them?

~~~
jayd16
Like GOTO it makes the execution harder to reason about as you could easily
miss it. It doesn't bother me personally but I can sort of see an argument for
it.

~~~
icholy
Avoiding early returns usually makes code harder to read. It's outdated advice
which was meant for writing assembly.

~~~
apta
It's not outdated, it depends on context. Several modern languages, including
Rust, Swift, Scala, Kotlin, and F# are built around having expressions as
constructs (if, match, try, etc. are all expressions). Once you have that
powerful feature it makes sense to write code in a certain way to make use of
that, and it ends up being clearer a lot of the time.

------
bayesian_horse
Maybe it's because of the way my brain works, but I prefer clarity and brevity
above almost everything else.

That's why I like Python over Go, C# and others. Python lets me fit more
functionality (expressed as code) in my working memory, and I have to ignore
less line noise and boilerplate.

~~~
erk__
The other side of the extreme is functional languages which have yet to have
the big breakthrough in business.

~~~
bayesian_horse
I would not want to teach novice programmers a purely functional language...

And that's what it comes down to, almost always. How hard is it to hire other
people to work on your code, and how hard is it to bring people up to speed,
who need to code, but aren't programmers. Scientists, mostly. Business people
increasingly.

~~~
wtetzner
I don't think you have to go for _purely_ functional.

Jane Street, for example, went with OCaml in part because the business people
found the code easier to review than other languages.

~~~
bayesian_horse
I've heard good things about OCaml, but it's extremely niche.

~~~
icxa
I am in no way a OCaml fan, and I primarily use Go at work.

That said, the fact that OCaml is used by Bloomberg and Facebook (on multiple
apps and products) alone make it not niche
[http://www.ocaml.org/learn/companies.html](http://www.ocaml.org/learn/companies.html)

That plus ReasonML's growing popularity, which is essentially just a syntax
extension of OCaml, makes it even further not niche.

~~~
bayesian_horse
Oh I don't doubt, that SOMEONE is using these nice languages. Still, the
community of OCaml or Haskell is not nearly as big and diverse as the Python
community.

And that counts in all sorts of ways. You'll have much more trouble finding
answers to any questions you have. You'll have less chances for community
meetings or educational content. You'll definitely have more trouble finding
new developers for your projects, both in business and in open source.

~~~
icxa
Again I am not trying to be a contrarian, but in my experience quantity !=
quality. You can take this statement the other way and say too much
information is bad. There is a reason there are so few Go Stack Overflow
questions and answers: most of Go's documentation is excellent and easy to
follow and learn and they have excellent community resources, videos and
guides. From what I have seen so far, the OCaml and Reason docs are great, and
their communities are extremely supportive.

------
jcadam
No language supports the commoditization of programming talent quite like Go.
Java gave it a good shot, but Go is much closer to "perfection" in this
regard. Using Go feels like mindless clerical work.

My industry (defense and govt contracting) is still big into Java, but we
traditionally run at least 10 years behind the state of the art. At some point
(maybe in another 10 years) I expect to see the cube farms full of Java code
monkeys replaced by cube farms full of Golang code monkeys. Big body shops
(which is what the majority of my industry is) love mediocrity and overstaffed
programs.

By that time the cool kids will have moved on to something else. Maybe they'll
rediscover OOP or some such.

~~~
raducu
I fail to see what's wrong with the commoditization of programming -- I assume
you think there's something wrong because you use the term "code monkey".

Is there some language that's used by cool programmers that allows them to
write complex code(equivalent of millions of lines of code written by "code
monkeys" \-- or 10 lines of code written by the gods) ?

Is there a conspiracy against said language that these god programmers write
that prevents it from taking over the world (besides the "code monkeys" not
being able to learn it?

Because in my experience once you get to decently complex projects, the
(modern)language doesn't really matter that much.

My intuition is the above is applicable even for small projects, and that
beyond hand picked examples, the programming language doesn't really matter as
long as you're comparing apples to apples -- that is some business
functionality, the choice is based just on the ecosystem.

~~~
CoolGuySteve
Yeah but you won't like the answer. It's C.

~~~
sosodev
Writing your web services in C sounds like a great idea.

~~~
CoolGuySteve
I've seen enough presentations from Facebook/Google to believe that on a long
enough timescale all web services are rewritten in C/C++.

~~~
alexhutcheson
C++ is a completely different beast from C though. C++ actually has strings.

------
KaiserPro
I think Go has many fun features.

However, to argue that its easier to write "good" code, is hyperbole of the
highest order.

A programming language is a brush with which to paint your logic. If your
picture is murky its because you, the programmer has made it murky.

There are many tradeoffs with "good" code. Readability, speed, compactness,
modularisation, use of libraries. As with any other practical subject, your
skill comes from practice. Yes, new tools can make it _easier_ to be more
efficient, or faster. They might even badger you into good habits.

But

They cannot make you "good". Its the expensive camera fallacy. Sure a Medium
format SLR will take _spectacular_ pictures, but only if you use it properly.
A good photographer will be able to take wonderful images using a camera phone
from 2006.

~~~
KaiserPro
To underscore the point:

    
    
      The Python code snippet del a[i] deletes the element at index i from a list a. This code certainly is quite readable, but not so transparent: it’s easy to miss that the time complexity is O(n), where n is the number of elements in the list.
    
      Go doesn’t have a similar utility function. This is definitely less convenient, but also more transparent. Your code needs to explicitly state if it copies a section of the list. See 2 ways to delete an element from a slice for a Go code example.
    

I think this assertion is wrong. _del_ in python does exactly what it says it
does. There are precisely three reasons to not use _del_ :

    
    
      o Because you have written your program, got all the low hanging performance fruits, and now need to optimise how you delete from (large) lists, and dequeue doesn't work for you
      o you are arrogant and want to show everyone how clever you are because you understand how list operation are handled under the hood. So you have written your own.
      o  a.remove()/a.pop() you think is more readable.
    

It is far more important to be readable than to be fast in 90% of cases. If we
all really cared about speed, then React/electron/et al would never be a
thing.

~~~
zaphar
React is actually faster than most other approaches. It was created because it
was a DSL for faster and more performant DOM updating.

~~~
KaiserPro
I think you're missing my point here. Firstly all of it is far slower than a
native toolkit. secondly client side DOM rendering is almost never fast,
compared to server side HTML/CSS.

------
chvid
"Go makes it easier (than Java or Python) to write correct, clear and
efficient code."

I really appreciate taking a minimalist and opinionated approach to language
design but all design choices done in Go comes at a cost and the above broad
statement simply is not correct. And to me it just adds to the impression of
the Go community of being on the immature and almost cultish side.

~~~
pishpash
Immature or cultish might be too strong, but I will say it is very fitting for
being a language associated with Google, which is also very opiniated and
arrogant, but maybe 80% of the time right. It's that 20% of the time though
that you hope for some humility and open-mindedness.

------
JanSt
Yes, Java does have its weaknesses. It's an old language and people were still
figuring out a lot of the stuff. But the ecosystem is huge and if you know the
quirks, it's still a heck of a productive language.

> Java inner classes suddenly appeared in 1997; it took more than a year to
> update the specification, and it became almost twice as big as a result.
> That’s a high price to pay for a non-essential feature.

I can't talk about the doubling of the specification but you can learn
everything you need to about inner classes on 5 pages or so. It's over 20
years old now.

> generic arrays aren’t supported

So you can't use something with arrays that go doesn't even support ;-)

> type wildcards with upper and lower bounds are quite complicated.

Well, it's two words (extends and super) and some syntax. How could it be much
easier?

> Enum [...] It’s certainly nice to have, but offers little that couldn’t be
> done with ordinary classes

Yes, and generics offer little that couldn't be done by implementing
specialised classes. Enums are there to help you. You see an enum? You know
what happens, you know what it offers, you know it's not a "normal" class but
is there for a special reason.

Yes, Java does have its inconsistencies. Why is String Immutable when in a OO-
language the opposite would be taken for granted? Why can't you use int as a
datatype for an ArrayList but Integer? What's up with Stack and Deque and
Vector? You have to know Java to work with it effectively. We are
professionals after all. It can be expected that we know the language. Java
gets the job done.

That's not to say that Go couldn't get ahead of Java and may be the better
language (especially in the future). But the ecosystem is far from it for now
and Go has to prove it won't suffer from the same problems Java is now.

------
deckarep
After being fully invested in Go for close to 6 years and working at primarily
Go based shops...I want to disagree with this headline.

Folks new and old to Go still write data-race riddled code unless they put in
the extreme mental effort and care into avoiding data-races. Also, if they
write good unit tests that help them spin through the code they can often
double-down on ensuring their code is correct by using the race-detector.

Even if you do all of this...sorry but there’s no guarantees.

In my opinion this is why we are seeing languages like Rust invest heavily in
something like the borrow checker...to prove at compile time when you have
racy code.

If Go had a compile time ability to do this it would be really amazing.

Yes, this all my experience and opinion.

~~~
acuozzo
> to prove at compile time when you have racy code

Check out Pony.

~~~
AnimalMuppet
I can't tell. Is that just a pun, or does Pony actually help with this?

~~~
deckarep
It’s not a joke see Pony’s front-page. I’ve also heard that other languages
are considering moving to this provable compile time model such as Swift.

I’d be happy to offload such mental hoops to the compiler.

------
valw
Any comparison of languages in the form "language X is generally better than
language Y" with no additional project context or problem domain is going to
be an extremely naive one, to the point it's not relevant to anyone having to
make pragmatic tech choices.

This article is no exception.

I'm not partial to Go, Java or Python, but I do wish this sort of article
stopped making headlines, leaving room for finer analyses and experience
reports. These are what we really need.

------
hamilyon2
Well, arguments in favor of go are made up.

For instance, you have to add literally one line of code to terminate Java
application at the end of main function. Why would such a minute feature of
language make Java programs harder to reason about? Why would anyone even
present this argument as a serious one?

------
dvfjsdhgfv
This is interesting:

> The Python code snippet del a[i] deletes the element at index i from a list
> a. This code certainly is quite readable, but not so transparent: it’s easy
> to miss that the time complexity is O(n), where n is the number of elements
> in the list. Go doesn’t have a similar utility function. This is definitely
> less convenient, but also more transparent. Your code needs to explicitly
> state if it copies a section of the list. See 2 ways to delete an element
> from a slice[0] for a Go code example.

But the examples given in [0] could also be implemented in Python as well
with, I dare say, the same time complexity.

------
shusson
> Similarly, there is an error handling draft design than may replace the
> current bare-bones error handling.

I actually really like the error handling in Go and think it makes it easer to
write good code. At least for simple programs.

------
isacikgoz
Despite all critic comments here, I think the article is great because it
clearly identifies what is minimalism in Go and how it is easy to learn and
use compared to Java or Python. Still, there could be code snippets or more
details on context but these are huge subjects and even if he tried it would
be a hard read.

------
oconnor663
> Go is strongly and statically typed with __no implicit conversions __

This is one glaring exception: Concretely typed objects can be silently
converted to interface objects. In particular, a `*MyErrorStruct` can be
silently converted to an `error`. The giant footgun associated with this
conversion is that because the resulting interface object "remembers" its
concrete type, it won't compare equal to `nil`, even if the original value was
in fact `nil`.

This is a pretty big exception, which I've seen cause bugs in production. It's
common to have one function that returns a concrete type wrapped by another
function that returns an interface. That means the silent type conversion is
happening in the `return` statement, which is extremely easy to overlook. (Or
which can be introduced after the fact by changing the signature of either
function.)

------
i_phish_cats
I wrote a PDF parser in golang a few years ago and it was an extremely
unpleasant experience. No polymorphism means I essentially have to cast
everything to void* aka interface{}. Rewrote it in C (the rewrite was quite
easy actually) which at least made the lib accessible to other languages.

~~~
codr7
There's plenty of polymorphism in Go, that's what interfaces are for. In C you
would typically use a struct stuffed with function pointers, how is that an
improvement?

Its still a better C in many ways, strings and character sets is a big one.

------
akerro
Agree with the title, but I would like to add that learning Go (and Rust) made
me look differently at many concepts in Java and made me better Java
developer.

------
amelius
How well would a library like NumPy work in Go, given that much of its ease of
use comes from operator overloading?

------
oromier
SO is Ruby, and who uses Ruby still ?

I love ruby I would like to work with Ruby 100% of the time but yeah... too
many downsides.

------
gerbilly
Ugh, go is fine but is seems like a regressive design with guardrails all over
the place to prevent programmers from hurting themselves.

I use it, but feel its design insults my intelligence.

------
ecmascript
No matter how good Go is I would never use it just because it is from Google,
a corporation I consider to be evil.

Sure Oracle may not be the wonderchild, but at least they don't store
everything they can about me without me having any say in the matter.

~~~
chimen
Do you use React? MySql? VsCode? YouTube? Chrome? Not all departments have to
share the same vision. Go is open source and its code up on a repository, open
and visible.

~~~
zelpo
In other words, you cant escape the wrath of google, so what you should do is
give up. It's like showing up at a Greenpeace march and pointing out to a
protester they they are wearing shoes that were made in a facility that
probably contributed to the destruction of the planet. Why bother protesting
you imperfect hypocrite?

~~~
chimen
I'm not protesting anything. Sure I would like to use something else but I
don't see any other search engine with better, more relevant results yet. Nor
do I see a better video platform or a better webmail (I am being subjective
here ofc). You can't tell people to give up good things just because [insert
evil things here] and offer no better alternative. You can escape the wrath of
google of course, there's always Bing, Duckgo and others; Python, Ruby,
Elixir, PHP, Java; Proton, yahoo mail, Zoho; Vimeo, DailyMotion;

Gmail, Search and Go (yes it's my fav language so far) runs or helps my
business greatly and with a direct impact on my income so yes...I'll gladly
share my fetishes with the big brother. I don;t want to but I have no better
alternatives. Do you?

I think your frustration comes from the fact that you want to avoid using
their products but can't find better alternatives. Also, no need to call
people names and...use your own username; don't go green in fear of internet
points.

~~~
mrgriffin
FWIW I read

> Why bother protesting you imperfect hypocrite?

As a thing that people are saying to the hypothetical Greenpeace protester,
not a thing that GP is directing at you.

