
Changes I would make to Go - jaxondu
http://sitr.us/2017/02/21/changes-i-would-make-to-go.html
======
hhsnopek
> First, functional programming is particularly difficult in Go. In fact the
> language discourages functional programming.

Then it seems that Go isn't the language for you. With that Go nor any
language, unless intended, is suppose to be a one-all solution for every
problem. We can accomplish a majority, if not all, problems in a language, but
this shouldn't assumed that a language is intended to do so.

~~~
burke
While I understand the argument for simplicity and agree with the premise in
most cases, I find it pretty hard to argue for this code:

    
    
        ys := []byte{}
        for _, x in xs {
          ys = append(ys, f(x))
        }
        

over something like this code, which is more obvious, less error-prone, and,
though it relies on an additional concept, it's an extremely broadly-known
concept:

    
    
        ys := collections.map(xs, f)
    

I don't think a proper collections library would require very invasive runtime
changes -- though, once you start down this path, you and up at "but what if
`f` returns `(myType, error)`, and then you're wishing for Option/Maybe types
(which is another feature that I believe Go should have implemented, but is
more obviously outside of the apparent mandate).

 _EDIT: It would make static analysis significantly more complex too._

~~~
jakewins
Go can't do this, because you can't define `map` as returning "a collection of
whatever `f` returns".

If they build a collections API like this now, without generics, and they then
add generic types later, they will be in the same position Java found itself
in - lots of painful API migrations.

While the generics debate is legendary in go, it does still seem very much
like the intention is to eventually include it. Given that, I think it makes
perfect sense to wait to introduce more special cases (like `append`).

In the meantime:

    
    
        func Map(in []interface{}, f func(interface{}) interface{}) []interface{} {
        	out := make([]interface{}, len(in))
        	for i, v := range in {
        		out[i] = f(v)
        	}
        	return out
        }
    

:)

~~~
couchand
It looks like you're making the same point as burke and the original article:
Go lacks common-sense features that would make writing safe, simple code easy.

~~~
jakewins
I guess we're agreeing on the fact that Go lacks generics. I don't know that I
agree that those makes "writing safe and simple code easy". As we both know,
simple and easy are two very different things.

Generics do make a lot of problems easy, but I don't think they inherently
make problem solving simple. I absolutely miss them in Go - but I also
remember how confused my high school programming teacher and I both were about
them.

So far, Go seems to err on the side of Simple, if a choice has to be made.
And, so far, the proposals for generics in Go seem to force that decision. I'm
glad to see how seriously the Go authors take weighing the design and decision
to include them.

~~~
couchand
Well I guess I misread your comment, then. I had assumed your code sample for
a type-unsafe implementation of Map, followed by the smiley, was a recognition
of the major lacking on Go, not just of generics but of the ability to operate
on collections. I read burke's comment as suggesting a privileged collections
library that doesn't go all the way to user-space generics, but perhaps I
misread that, too.

I would strongly disagree with the definition of "simple" that you seem to be
using. I don't think it's important for a language designed for software
professionals to have only features that are easy for high schoolers to
understand. It's far more important that experienced developers be able to
write a common idiom like map with as little cognitive overhead as possible,
that's the meaning of simple that I find valuable in this context.

------
jrobn
OK, go will never have generics (except that it does in "make", "range",
"chan", ok whatever...). That's fine with me. But including even just a few
suggestions in the parent article would make Go a more approachable language
to everybody.

* Pattern matching is intuitive and can be extremely powerful. * It's pretty clear that Null should not exist anymore. * Multiple return values, but no tuples?!

The go designers seem to not have a problem with special cases so why didn't
they include special cases for an Option<T> and Result<T,E>, two things that,
with pattern matching, would fit right into Go's explicit error checking
philosophy.

~~~
sjellis
> OK, go will never have generics (except that it does in "make", "range",
> "chan", ok whatever...). That's fine with me. But including even just a few
> suggestions in the parent article would make Go a more approachable language
> to everybody.

The current position is that the core team will only include generics if they
can find a design that satisfies them. Which has sounded a lot like "no,
never" but Russ Cox has said that he wants to look into implementing generics
again this year.

------
spraak
I really want to love Rust, but it's so visually unappealing :/ I love how
clean Go looks. I know it's vain..

~~~
beefsack
Like all things superficial, the more time you spend looking at something, the
more the visual appeal (or lack thereof) normalises to average.

I think one tangibly good thing about Go though is how readable it is and how
easy it is to grok, even with all the error handling boilerplate. I'd argue
that Rust is also very readable though, and if the features of the language
appeal to you I'd suggest giving it some time to get over the visual hurdle.

From a personal standpoint having spent years working in both languages, it's
rare I'll choose Go over Rust nowadays purely for practical reasons. I'm
roughly equally productive in both, but the end result tends to be much more
performant, maintainable and robust on the Rust side.

~~~
spraak
Thanks for the encouragement!

------
geodel
These are the changes that if made Go wouldn't be language it is. Go is
simple, straightforward if little verbose. To me Go fits perfectly for
business apps that I write currently in Java.

~~~
nemothekid
I'm not sure - I've been writing Go for 4 years in a production setting, when
we switched our API service from Python to Go at the release of Go 1.1. Since
then our default language is Go, and I write Go everyday. Things like Generics
I haven't been really bothered by.

But where I thought he brought up really good points are

1\. nil. He's right compared to more recent languages, nil is awkward. I've
been bit multiple times by the 'nil checks sometimes fail.' concept.
Option/Sum types are so much cleaner, and having non-nullable types make a lot
of things easier to reason about.

2\. error checking. My main gripe is when you are writing a process that
involves calling multiple functions that could return errors. You then need
more boiler plate in order to stay sane and DRY - and I've admittedly bitten
myself with the 'err' shadowing that happens sometimes.

I don't think a Maybe type would have made Go more complex, and I think it
would have fit in nicely with the 'Zero Value' concept.

~~~
richardwhiuk
Maybe/Option/Result types don't work without generics, because you
significantly reduce the type checking.

~~~
saghm
I'm not a Go programmer, but from what I understand, things like Go's map
implementation in the standard library are usable as if they're generic.
Couldn't they add a few more types like this (e.g. Option and Result) in the
same way without exposing generics as a language feature?

~~~
jimsmart
I program some Go - I believe you are talking about the 'empty interface',
e.g. map[string]interface{} The problem with that is that you instantly lose
compile-time type checking, and have to check/assert the types yourself at
runtime after accessing the map. In a strongly-typed language this kinda goes
against the grain, and is a PITA. (Although it still can be useful at times).
My 2p.

~~~
sbov
The point is that a map can be type safe because it's built into the language,
and that the designers could do exactly the same with a maybe/option/result
feature.

------
kristianp
Like C, Go is a small language. Given that the creators of go like its
smallness and simplicity, all those features are never going to be added to
Go.

When Bjarne Stroustrup wanted to add OO features to C, he created C++,
initially as a translator that output C. If someone wants to add features to
Go, they can create a "Go++" to Go translator, with pattern matching,
generics, tagged unions. Clearly it's guaranteed to be very popular! /s

~~~
ngrilly
It's the approach Robert Griesemer (member of the Go core team) chose to
prototype implementation of operator methods in Go:
[https://github.com/griesemer/dotGo2016](https://github.com/griesemer/dotGo2016)

~~~
kristianp
Actually it looks like he forked and modified the go compiler itself.

------
CalChris
> First, functional programming is particularly difficult in Go. In fact the
> language discourages functional programming.

Well, if I were the king of the forest, I'd move functional programming from
Rust to Go. With Rust, there's a lot of this higher level stuff in a
supposably lower level language that would be more at home and useful over in
the two letter language.

~~~
tps5
> _there 's a lot of this higher level stuff in a supposably lower level
> language_

I feel like you're suggesting that "high level stuff" is bad because it's
"high level stuff."

In my opinion, the goal of low level languages is to operate under certain
constraints. If you can operate under those constraints and still include
"high level stuff," then you should.

------
Risord
For Go people: How (learning) Go made you better programmer?

I haven't written any of these two languages but I have read Rust doc few
times in depth and I constantly miss many of it's features in my daily .net
work since then.

Example: -Optional over null -Union types -Trait implementation is independent
from source and target models

~~~
mtalantikite
Go made me appreciate static typing and a compiler.

Before picking up Go around the 1.0 release, the last time I spent any
significant time with those tools was 10 years prior as an undergrad using
Java. Java really made me hate those things. I spent the years in between with
languages like Ruby, JavaScript, and Python.

Now I actually prefer using compiled, statically typed languages, Rust being
the most recent one for me (and I still dislike Java).

~~~
Risord
Welcome to the dark side =)

I am not a Java fan either but I felt dynamic languages even worst. Since then
I have loved to modern static type systems like in Rust (in theory) and
Elm/Haskell.

------
alphabettsy
This article should be called, "Things I'd like to see in Go from Rust".

~~~
bluejekyll
Rust is really a language that pulled a lot of concepts that were done
elsewhere, into a really solid nice package.

Go is unusual in the new language space in that in eschewed many of these
modern techniques. Swift comes to mind as a comparison, which has many of the
features that the author misses.

Personally I like the examples offset by a single other language as it's less
context switching.

~~~
stouset
That's the feeling I get when using Rust: all of the bits of the language
appear to work well together. People clearly thought about how all of the
features in Rust would interoperate; it was _designed_.

Go, on the other hand, continually feels like a language that wasn't designed
as much as it accumulated. None of the parts seem to work in concert. Nil by
itself was a bad idea, but when combined with actually-nil-but-not-really
interfaces, it leads to subtly broken code. Tuples feel bolted on as second-
class citizens, and tuple-based error patterns combined with sometimes-
nonsensical zero values for types makes it uncomfortably easy to accidentally
use invalid values when you have a typo in error-handling. Implicitly
implementing interfaces makes sense until you type-switch on interfaces at
runtime, and then through edits elsewhere one interface becomes a distinct
subset of the other interface — depending on how they're ordered, you may
never hit the other code.

Some of the decisions made in golang make sense in isolation, but in concert
they lead to confusion, subtle bugs, and copy-pasted code everywhere.

~~~
nortiero
I feel the exact opposite... Go is a bold design, if not an elegant one, yet
powerful. Rust is a design-by-committee language, built from accretion and
removal. Its origins as a managed language, pivoted and is now a second system
C++ replacement -- the only one, to be fair.

~~~
thatswrong0
Elegant is.. not the first word I'd use to describe Go. Maybe the core of the
language is, but in practice it is anything but, between the error handling,
PRY (please repeat yourself), relative inability to create abstractions, and
neutered type system.

------
CalmStorm
It seems to me golang and Rust are often being compared with each other. Given
that Swift starts to be used on server side, I would love to see some
comparison between golang and Swift, or Rust and Swift.

------
sdogruyol
Crystal would be a great choice for the author.

------
justicezyx
Do language​ debaters all think every human should speak one language?...

~~~
int_19h
Yes. And it should be Lojban. ~

~~~
omginternets
I'm not sure I understand. Could you please translate your comment into
Lojban?

------
hubert123
Just another generic complaint about Go's lack of bloat. It's all completely
naive, never understanding why Go doesnt want generics beyond a simple "b-b-
but look, the pattern matching of Rust is simple too!" No it isnt simple just
because you say it is. It is the opposite of simple. I've read the Rust docs
on it several times and I still dont have a clear mental picture of how to
read a match statement out loud. "match result with Some(number) .. then do..?
But match HOW?" I've been thinking of a clearer syntax/naming for match and in
my humble opinion it should literally just be called 'if' and any
inconsistency that doesnt align with that be removed from the language.
Calling 'match' match is haskell programmers gone wild. Programmers in the
real world dont have a clue how to read 'match'

~~~
steveklabnik
If you have the time and inclination, I'd love to know if the second edition
of the book makes it more clear to you [http://rust-
lang.github.io/book/second-edition/ch06-02-match...](http://rust-
lang.github.io/book/second-edition/ch06-02-match.html)

------
alvil
I can't believe you can look at that ugly colorscheme whole day working in
even uglier language which rust really is.

------
astdb
Here we Go

~~~
stcredzero
_Here we Go_

We're rewarding these posts with attention. I guess on some level, these
language wars are gratifying.

