
Things you probably don't know about Go (2012) [slides] - alexellisuk
https://talks.golang.org/2012/10things.slide
======
justwalt
> 6\. Mock out the file system

Does anyone know if this is possible to do in Rust? I’ve been searching the
last couple of days and I think my biggest problem is not knowing what
combination of search terms to use.

~~~
arve0
I went to lib.rs, searched for mock and found this:
[https://lib.rs/crates/filesystem](https://lib.rs/crates/filesystem)

~~~
justwalt
Well, I certainly knew about the filesystem crate before, but never thought to
see if it offered this functionality. Thanks for this.

------
workthrowaway12
i miss Andrew... haven't seen him talk lately. but anyways, not sure i
understand the mock file system slide -- it's still calling os.Open?

~~~
y4mi
Check the date in the URL. Might explain your confusion

------
snagglegaggle
I'm missing the context for some of these. A lot of them seem obvious, or just
thing+unicode?

I like the commandline godoc, still dislike gopath. And.. what is the gopher's
name?

~~~
badrequest
Some folks were really trying to make the Gopher's name "Gordon", but it never
really caught on. The gopher has no name.

~~~
pushpop
Presumably those people were British and referencing an iconic 90s kids TV
character?

~~~
badrequest
Oh neat, TIL about Gordon the Gopher.

------
thefounder
Other things:

reflect.StructOf is broken if you use embedded fields

~~~
ainar-g
Can't find that in the Bugs section of the documentation of package
reflect[1]. Is there a GitHub issue?

[1] [https://golang.org/pkg/reflect/#pkg-note-
BUG](https://golang.org/pkg/reflect/#pkg-note-BUG)

~~~
thefounder
There are various issues/comments(i.e [1] ) but in practice you find out about
them when your program crashes.

[https://github.com/golang/go/issues/15924#issuecomment-45557...](https://github.com/golang/go/issues/15924#issuecomment-455575431)

------
auraham
somebody knows how to create slides like that?

~~~
brainzap
I guess it is this
[https://godoc.org/golang.org/x/tools/present](https://godoc.org/golang.org/x/tools/present)

------
perlgeek
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

> If the title begins with a number or number + gratuitous adjective, we'd
> appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To
> Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is
> meaningful, e.g. "The 5 Platonic Solids."

~~~
mumblemumble
I dislike that guideline.

This time I clicked, but, in general, I'd rather have the original title,
gratuitous adjectives and all, so that I can have a clue that the link is
going to lead to a listicle.

~~~
kerkeslager
I'd like to have those flagged with [Listicle].

------
shurcooL
This is a talk from 2012, so I believe the title needs a “(2012)” suffix
according to what I’ve seen in the past on HN.

------
bsaul
HN-type rant : Guys , it’s 2019 already, why not have a presentation tool that
works on mobile browsers ?

That talk looks extremely interesting but i can’t browse past slide 4

~~~
kyrra
It's a slide tool written by the Go team, mainly used by them to present at
conferences. You'll also notice they've stopped using it as much recently.
There was no talks in 2018, and only 1 in 2019. Previous years had many more.

List of old talks: [https://talks.golang.org/](https://talks.golang.org/)

You can actually explore the entire source for the site here:
[https://github.com/golang/talks](https://github.com/golang/talks)

The specific talk linked on this post is here:
[https://github.com/golang/talks/blob/master/content/2012/10t...](https://github.com/golang/talks/blob/master/content/2012/10things.slide)

The tool to generate the HTML based on the linked .slide:
[https://godoc.org/golang.org/x/tools/cmd/present](https://godoc.org/golang.org/x/tools/cmd/present)

~~~
woah
What happened to PDFs?

~~~
naikrovek
Nothing. PDFs still exist; they haven't gone anywhere.

If you're asking why the Go team doesn't use PDFs for presentations, that's
probably a question for the Go team themselves or one of the golang-*
newsgroups on Google Groups.

------
LukeShu
(2012)

------
kerkeslager
1-7 of these features exist in C#, and in C# you get a real type system. C#
isn't even my favorite language that has all these features, just the most
mainstream.

8-10 are of dubious usefulness. It seems they break the principle of least
astonishment[1], but maybe they're idiomatic in Go.

So yeah, still waiting to see any reason to think Go's popularity is anything
more than hype and fanboyism.

[1]
[https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...](https://en.wikipedia.org/wiki/Principle_of_least_astonishment)

~~~
Spivak
Because Go is taking a strong stance that smaller languages are more
productive, and I think they’re right.

C# has all these features because C# has every single feature and facility
that every programming language has ever had thrown into a single ungodly soup
of keywords and syntax.

Don’t get me wrong, this means C# is bloody powerful but once you involve more
than one dev you get into the problems of every dev understanding and/or
preferring their subset of C#. Every PR is 50% policing style and structure
desperately trying to keep the codebase grokable by everyone and politics
about everyone’s favorite pet feature and design pattern. C# rewards
cleverness with incredibly slick looking but utterly incomprehensible code
unless you wrote it two minutes ago.

Not saying Go is the answer or the way but I think it’s scratching a lot of
people’s itches for something high level that’s restrictive enough that
there’s only one or two “right” ways to accomplish a given task.

~~~
kerkeslager
> Because Go is taking a strong stance that smaller languages are more
> productive, and I think they’re right.

As a face-value claim, that's obviously untrue. Forth, by any reasonable
metric, is a smaller language than Go, but I think you'd have a hard time
claiming it's more productive.

I'll generously assume that you mean that "languages with a carefully selected
set of features are more productive", and there I'd agree with you. That's
Python's "There should be one-- and preferably only one --obvious way to do
it." But then the question becomes, "Which features?"

A very key choice you have to make up-front is the type system, and it's
obvious that Go's type-system choices are bad[1]. Weak static types[2] gives
them the worst of both worlds: the types don't get out of your way like a
dynamic type system and they don't catch errors like a strong/flexible type
system. Single-pass compilation for speed is the only attempt at a
justification for this choice, but it's a bad justification: 1) this is solved
by partial recompilation for all but the largest use cases[1], and 2) if
you're using `go generate` to solve the obvious problems with the type system,
you're introducing a second pass that saves keystrokes in exchange for giving
up even more type safety. So you add a linter: congratulations, now your
single-pass compilation is three passes. This isn't a tradeoff, it's just
giving away all benefits of types in exchange for a veneer of minimalist
aesthetic.

I'm not going to quote what you said on C#--I'll only respond by saying that
if you read my post, you'll see I said it's not my favorite language. I'm not
espousing it.

> Not saying Go is the answer or the way but I think it’s scratching a lot of
> people’s itches for something high level that’s restrictive enough that
> there’s only one or two “right” ways to accomplish a given task.

...which is extremely short-sighted. The "only one right way to do it" only
lasts as long as there's no NPM-like ecosystem of libraries. Look at Python:
most projects pull in at least a few common dependencies, and there's immense
pressure on Python to integrate these back into the language--a pressure to
which they have succumbed in many cases (which isn't necessarily a bad thing).
Most projects also pull in some section of really, really bad dependencies
that should never have been released into the wild and probably never will be
updated. There's no way around subsetting: at least if you use the wrong
language features, they'll be supported and deprecated responsibly, unlike the
average 0.0.2-versioned 5 line function imported from NPM or PyPy[3].

Ideally you have a set of core features and a strong standard library that
don't push people to import a bunch of terrible libraries, which is why Python
has fared so well despite some really awful limitations (i.e. the GIL). But
again, Go isn't that.

[1] They're probably not bad for Google: the people who made Go made it to
solve Google's problems, and they're smart guys. But you are not Google
(unless you are Google), and if you're operating at Google's scale, you can
make your own programming language that solves your problems rather than
Google's.

[2] Go fanboys generally don't know that weak/strong and static/dynamic aren't
the same thing, and like to claim that Go has a strong type system because it
has a static type system. This reinforces my belief that people choose Go
because they don't understand type systems.

[3] NIH isn't even enforceable: good luck preventing people on your team from
"importing" code from Stack Overflow using their keyboard's copy/paste
function.

~~~
pushpop
I get really sick of people arguing personal preference as if it’s irrefutable
fact. I have written pretty sophisticated applications in more than a dozen
different languages over the last 3 decades and yes, you’re absolutely right
that Go does fall short in many respects, but then so does every other
language. There isn’t such thing as a perfect language; it’s _always_ about
weighing up benefits vs trade offs.

So how about we get off our proverbial soapbox and enjoy the fact that we are
lucky enough to work in an industry where we can choose the tools we like.

~~~
kerkeslager
> I get really sick of people arguing personal preference as if it’s
> irrefutable fact.

This reads as, "My personal preference is for people not to argue for their
personal preference." Before you go on to argue for your personal preference.

> So how about we get off our proverbial soapbox and enjoy the fact that we
> are lucky enough to work in an industry where we can choose the tools we
> like.

Sure, we can choose the tools we like provided those tools are popular enough
to have an ecosystem of jobs, or we're willing to shoehorn ourselves into a
narrow set of jobs.

...which is why I'm sick of languages getting popular based on hype rather
than pragmatics. Every Go job is a job that I've either got to reject based on
the tool, or use their terrible tool.

~~~
pushpop
> _This reads as, "My personal preference is for people not to argue for their
> personal preference." Before you go on to argue for your personal
> preference._

I haven’t argued my personal preference though. All I’m saying is that arguing
that your personal preference is anyway more “correct” than others is about as
sensible as trying to discuss the science behind religion.

~~~
kerkeslager
> I haven’t argued my personal preference though.

Yes you have, and you're still doing it.

Your "preference" in this case, which you are arguing for, is to not have
people argue for their language preferences.

