
Go and Dogma - zalmoxes
https://research.swtch.com/dogma
======
empath75
I think the reason you have those kinds of holy wars among users of a
particular technology, whether it's an OS or a gaming console or a programming
language, is network effects.

All of those things are more valuable the more people that use them, and if
you've invested money or time into any of them, you have more of a pay off on
your investment if more people also use them. So you might feel strongly
incentivized to defend your platform of choice while attacking competing
platforms, even if another platform might be marginally better, but not enough
to justify the switching costs.

If you're a language developer, you have dual incentives-- one is to get
people to use your language, which would seem to encourage you to engage in
holy wars, but the other is to _be good at developing languages_ which
requires you to think objectively about what you and other language developers
are doing, so even if you're publicly defending your choices, you should be
open to the idea that another way might be better.

~~~
gumby
> I think the reason you have those kinds of holy wars among users of a
> particular technology...is network effects.

I find the holy wars are usually fueled by "fans" \-- people less invested and
less knowledgable in the topic. This is true of movies, bands, sports teams,
phones, computers and cars.

The fact is if you work on the tech you appreciate that there are tradeoffs
and know what your overall objective is (so are less likely to argue about
things that don't get you there). Musicians tend to get along -- did the
Beatles hate the Stones (OK, the Stones released "Let it Bleed"). I doubt Mark
Hamill hates Star Trek or Shatner Star Wars. The catholic pope meets with the
grand mufti of Jarusalem. Obama and Bush talked a lot in 2008 and 2009.

It's like the joke about academia being so cutthroat as the stakes are so
small. Holy / Flame wars erupt among those on the periphery at best.

~~~
dragonwriter
> I find the holy wars are usually fueled by "fans" \-- people less invested
> and less knowledgable in the topic.

There seems, IME, to be a sizable contingent of people who have invested
heavily in a particular technology and are threatened, in their own market
value, by threats to its distribution, in most technology flamewars. They
aren't necessarily less knowledgeable, but frequently prefer depth in a
platform to breadth across platforms for developing their own skill set, which
creates a strong incentive to promote the platform.

------
rektide
Language designers are indeed often un-dogmatic about the language. The tool
builders in Go however have built a very structured distinct practice of using
Go that forces one to remain in dogma. Go is rather unique in how much Go-
tooling-specific tooling knowledge one has to have to even begin writing code,
owing to it's deeply inbuilt sense of workspaces (GOPATHs) and it's strict
directory structure.

I really think this is a great post, and emphasizes a strong danger in adopter
culture. But I do also think Go, in particular, is rigorously dogmatic _in it
's tooling._ To good effect, in that anyone can come to any project and
understand some basics, but the workspace decision is really hard to reconcile
with the project-by-project view of the world that most language tooling
assumes.

~~~
stcredzero
_Go is rather unique in how much Go-tooling-specific tooling knowledge one has
to have to even begin writing code_

There's not much of that. I think that most people who are put off by that are
actually angry that Go didn't affirm their own prejudices.

------
tiglionabbit
There are a lot of decisions in Go that I find very distasteful. It's
frustrating because Go comes very close to being something I'd want to use,
but falls short in all areas.

It has this great automatic interface system! Amazing! Except it also has
"primitive" types that can't participate, so many of my functions have to take
interface{} instead which is pretty much void*.

It can dispatch to different functions based on the argument types! It will
even automatically switch to the non-pointer type if you pass a pointer to a
non-pointer function. However, you can't write a pointer and non-pointer
version of the same function. Also why are we using pointers to represent
reference mutability and optionality these days? Other languages have
maybe/option which handles optionality much better.

Speaking of not having maybe/option, every other line of code is "if (err ==
nil)" and there's no way to abstract this out. Give me `option` dammit.
Exception handling exists via panic, but it's a little different than you're
used to and the language designers like to pretend it's not exception handling
at all.

There are built-in functions that use generics, but I'm not allowed to write
one? Hypocrites.

You have to name things starting with a capital letter to make them public.
Who came up with this convention? It is not shared by any language ever. It
also gets extremely annoying when you want to serialize json, serialize a
protocol buffer, or do a database query. Name your struct members in lowercase
and those libraries won't be able to see them, but name them in uppercase and
the output will be in the wrong case. Instead, you have to "annotate" those
struct fields repeatedly for every library you're going to pass them to. You
also have to manage "naming convention" systems that translate between the two
names, and these conventions are never the same between two libraries.

~~~
Kalium
> It also gets extremely annoying when you want to serialize json, serialize a
> protocol buffer, or do a database query.

This in particular is maddening when learning go. I lost hours to this when
deserializing JSON.

~~~
ARolek
Helpful tool for this situation: [https://mholt.github.io/json-to-
go/](https://mholt.github.io/json-to-go/)

------
bjt
I completely agree with the author, though slightly surprised to see it come
from the Go community, which has seemed like one of the more dogmatic
languages. (E.g. all the "you don't need generics" arguments over the years.)

~~~
dmit
If you follow the history of that particular issue, you'll see that the Go
team's (official) view has always been that there are tradeoffs involved, and
that none of the existing proposals for implementing generics are sufficient
improvements over the status quo. Generics are not free, they bring a lot of
baggage with them. And I think most people will agree that Go has achieved a
lot of success without them, so perhaps most use cases _don 't_ require
generics after all.

~~~
hota_mazi
> Go has achieved a lot of success without them

This is a dangerous and slippery slope to engage on.

Java was also extremely successful in 2004, before it supported generics. Yet
you'd be hard pressed to find a Java developer who thinks that generics were
not overwhelmingly beneficial to the language, and probably one of the main
reasons why Java is even more dominant and powerful today than it was pre-
generics.

~~~
yarrel
Generics for a language with a common base class object are a category error.

Java's current popularity is due to Android, not the bloated corpse of
enterprise Java.

~~~
prodigal_erik
Types like Object and Comparable<T> allow heterogeneous collections and
algorithms, which are occasionally useful even in an otherwise statically-
typed language. Think of it as a set of types where otherwise you would have
required boxing everything within a single type and eventually reimplementing
the type system.

If Java had generics from day one, they could have put methods like equals and
hashCode in interfaces that some classes don't implement, instead of passing
static type checks and then blowing up at runtime because you did something
that never made sense.

------
twblalock
I think the Go team probably wanted to avoid the mess that C++ has become,
which to some extent has affected Scala as well. When a language tries to be
all things to all people, it becomes cluttered and inconsistent. It can also
become incompatible with previous versions in ways that prevent people from
upgrading, as we have seen with Python 3.

However, the Go team has gone further than most in their rejection of changes,
and I think it's reached the point where it hurts the adoption of the
language. When I write Go code, I feel like Rob Pike is standing behind me
telling me to do things the way he likes them done, or not at all.

There are plenty of examples of languages that have navigated this problem
better than Go. Rust and Haskell come to mind immediately. C# and F# should
also get more credit than they do for handling this kind of thing gracefully.
Even Java 8 has incorporated many of the things people found attractive about
Scala, without making them mandatory or alienating established developers.

~~~
camus2
> I think the Go team probably wanted to avoid the mess that C++ has become,

Ultimately, people will write a Go++ because the language isn't good enough.
That's not avoiding C++, that's forcing people to recreate C++ .

~~~
pjmlp
The solution "go generate" reminds me of the class generating tools that
Borland shipped with their C++ compilers, before they added support for
templates, back in the MS-DOS days!

------
zzzcpan
But this is not how languages are designed and even how Go was designed, where
three people had to agree on features, instead of making "engineering trade
offs". And this was a decent decision for familiarity and making the language
more approachable, even though it was all dogma. The reason is simple:
languages follow the same rules as user interfaces in general and as in user
interfaces first thing that comes to mind is usually a better choice, than
something overthought by a non-professional in UX, because you have it
engraved in your brain by your most often previous experience and therefore
it's very likely that many people do too. And having multiple people to agree
basically supercharges that.

But then you still have to follow the rules of the UX, consistency,
flexibility, all that, and none of the languages I know of are serious about
that. It's all just dogma everywhere, or "engineering trade offs" if you like.
We don't have much dogma only when it comes to performance, since it's the
only thing easily measurable.

------
AsyncAwait
I like generics, but why can't there be a language that doesn't have them?

If I want a simple language, no generics I go with Go, for everything else I
go with Rust and Swift.

Not every language has to have generics, when I want to use them, I simply
switch languages.

There is something nice about being able to keep Go in your head and I think
that it has shown that there is a market for such a language.

~~~
camus2
> I like generics, but why can't there be a language that doesn't have them?

Python,Ruby and Javascript don't have generics ... because they are
dynamically typed. Go has generics, maps and array are container types, you
just can't define your own. To say Go has no generics is stupid, it just
doesn't allow you to define your own. Instead you can use catch all
interface{} everywhere like dynamically typed languages.

> Not every language has to have generics, when I want to use them, I simply
> switch languages.

This statement makes no sense at all.

~~~
AsyncAwait
> Go has generics, maps and array are container types, you just can't define
> your own. To say Go has no generics is stupid, it just doesn't allow you to
> define your own.

That's usually what is indeed meant by the statement "Go doesn't have
generics", maybe it should be "Go doesn't have user-defined generics", but I
assume most people can infer that. I really hate the recent trend of having to
spell _everything_ out.

> This statement makes no sense at all.

Can you be more specific? What doesn't make sense _at all_ in saying that when
I have a simple problem that is unlikely to benefit greatly from a more
sophisticated type system, I reach for Go, otherwise I use a different
language?

------
ereyes01
This article brings to mind the challenge of enforcing empathy in an
engineering community. Software and other technical systems are coldly precise
and unambiguous. People, on the other hand, are rarely that precise and often
illogical without significant effort/investment into forcing themselves to be
rigorous about a though or claim.

I think it's too easy for community members to leave opinionated outsiders
with a bad taste in their mouth when they approach your system with opinions
and tendencies that were built up in other systems with different
circumstances and assumptions. The kneejerk response is "well, you're wrong,
we don't do it that way here," hence the dogma.

It takes serious effort to fight that instinct, and not everyone is good at
fighting it... especially when some community members suffer from the same
problem as the outsider, but with the affinity being toward their own system.
This is a hard problem to solve...

It's a good thing this article was written and there is a willingness to at
least acknowledge the problem in the Go community. It contrasts to the style
of say, Linus Torvalds, whose approach is basically "empathy? fuck that, I'd
rather call them names" :-)

------
athenot
This reminds me of Perl's motto:

 _There Is More Than One Way To Do It_.

Regardless of the community, we generally all strive for the most _efficient_
way to accomplish a goal, but the definition of "efficient" can vary:
execution performance, elegance, ease of developing, ease of integrating into
X... Often, one or a few leading solutions emerge but it's tempting to take
those pragmatic optimums and turn them into law—or worse: follow them for the
wrong reasons.

It's a good idea to know _why_ you're using a particular design tradeoff, and
remain flexible to change if you find your constraints have changed. Some
environments make this interchangeability easier than others but there's
almost always a choice.

------
coldtea
> _(for example both Go and Haskell need some kind of “green threads”, so
> there are more shared runtime challenges than you might expect)_

That's a very generous definition of similarities, as tons of languages have
green threads, even Java/JVM had them initially (and still has them in various
implementations over native threads). Could even add that most languages also
have GC, some type system, io, modules, etc.

~~~
szemet
Name a language having a compiler that most similar to Go in the threading
domain, e.g.:

compiles to machine code

have green threads

use non-blocking IO in the background

have parallel runtime

Haskell is the first that comes to my mind. (I guess that Common Lisp is a
safe bet too, as it had everything for ages before it was cool;), but I'm not
familiar with that domain to be sure) Erlang have everything except machine
code compilation.

What else? I guess the rest is from the newer, lesser known or experimental
languages. So is there anything more popular than Haskell?

~~~
pjmlp
Active Oberon, initially developed in 1996.

\- compiles to machine code, check. A whole operating was written in it, AOS
(aka BlueBottle).

\- have green threads, check. That is where the name Active comes from. It
makes use of tasks.

\- use non-blocking IO in the background, check. Tasks are used everywhere
across whole OS.

\- have parallel runtime, check. The whole OS makes use of parallelism and its
compiler, Paco, does compilation of modules in parallel

[https://en.wikipedia.org/wiki/Active_Oberon](https://en.wikipedia.org/wiki/Active_Oberon)

[http://www.ocp.inf.ethz.ch/wiki/Documentation/Front](http://www.ocp.inf.ethz.ch/wiki/Documentation/Front)

[http://www.progtools.org/article.php?name=oberon&section=com...](http://www.progtools.org/article.php?name=oberon&section=compilers&type=tutorial)

~~~
Manishearth
I absolutely love how in PL discussions you and nickpsecurity always have
examples of random languages to fit every niche.

~~~
pjmlp
Thanks! :)

I majored in systems and distributed programming, and had the luck of having a
set of teachers that cared we should know the history of computing, making us
curious about our past and how those designs could influence current ones.

So the habit of hunting and reading papers stayed with me, even if during the
day I just do boring enterprise consulting.

Many times they are more entertaining than reading newspapers on the daily
commute.

~~~
Manishearth
You should blog about this stuff if you don't already and have the time :)

------
cyberpanther
The problem is when we form Groups or Tribes based around something we fall
into the trap of just whitelisting or blacklisting things. This is a natural
human algorithm to simplify things in our brain and make our decision
processes more efficient.

A way to fight this is to make sure you belong to more than one language
community. Then you'll be forced to not make such a simplified model.

------
visarga
/offtopic

"Go" is such a poor name, both for a language and game, because they collide
with the English word, it's impossible to perform targeted search or sometimes
even to know what an article is about.

Some TV shows like "24" suffered from the same fate. On reddit the game of Go
is represented by the Korean "baduk", probably to escape the confusion cone.

~~~
dmit
Agreed, but that is a technical problem that can (and should) be solved. For
example, "C" and "C++" are even more unfriendly terms for search engines, yet
Google handles them just fine:

[https://www.google.com/search?q=c+stdlib](https://www.google.com/search?q=c+stdlib)

[https://www.google.com/search?q=c%2B%2B+stdlib](https://www.google.com/search?q=c%2B%2B+stdlib)

~~~
nagvx
When you feed them unambiguous queries like that, yes. "stdlib" is a very
unique word specific to the domain of programming. Things get trickier with
terms that have more overlap, and irrelevant results tend to creep further up
the page.

~~~
lttlrck
that ambiguity is hardly limited to program languages.

