Hacker News new | past | comments | ask | show | jobs | submit login
Creating the Go Programming Language [audio] (changelog.com)
221 points by wwarner 17 days ago | hide | past | web | favorite | 131 comments



HN comments seem to lack focus on the podcast's contents (which isn't too surprising, as the podcast is nearly as long as the post is old.) Having already listened, here are some highlights:

* How work started on the language in the beginning, including social factors such as support from their managers.

* The value of starting a language with its spec instead of an implementation. Why it's a good idea and when it's maybe not.

* Learning how to work in on an open source project coming from a closed source world, how to make that project successful.

* Feature rich vs feature parse languages. What Go chose, and the trade-offs it took when choosing so.

* What influences Go has had on other programming languages, with a focus on gofmt and code formatting in general.


For those wanting to read a transcript...

Transcripts are delayed a few days but there will be a transcript. We have a human on staff (Alex) to ensure every podcast we produce a highly readable transcript that can also be contributed to via Github.


Transcript is now up, at the linked article.


I think I'm the only Go programmer who enjoys the idea behind GOPATH :)


\o

I still use GOPATH structure since it's such a nice way to organize my code.


I didn’t like it at first but didn’t have much choice. After a while I liked the structure. I don’t even write go anymore and I still use gopath structure for my work


This is a common pattern with many of Go’s features. Experienced folk sometimes tend to make unconventional design decisions. You don’t appreciate them until you’ve tried out all the alternatives, and arrived at the same conclusions yourself.


I was annoyed by the change as well, but I kinda like the module system. My biggest complaint is that you can only use different major versions of the same dependencies.


Mods, please add (podcast) warning to title.

There is no transcript.


Transcripts are delayed a few days but there will be a transcript. We have a human on staff (Alex) to ensure every podcast we produce a highly readable transcript that can also be contributed to via Github.


There is now.


I write primarily in Go, I have to admit that I can't stand the name of it. When doing a search I constantly have to write "go golang" in my searches to get relevant results. It's too generically named, like naming something "The"


Let's make a new language called Lang. We can also call it langlang. I'm sure there's nothing using that name~


One of my favorite bands from the 80s was named "The The".


Slightly off topic: Why was the language named "Go"?

I originally assumed that it was an abbreviation of Google (where it was developed) but I can't seem to find an information confirming that...


I recall reading that one of the reasons was the fact that "go" sounded good

1. when used as a keyword to start a "goroutine"

  go f()
2. when used from the command line for compilation etc.

  go build ...
  go get ...


At one point the Go FAQ said that Go got its name because “Ogle” would be a good name for a Go debugger [1]. This was removed from the FAQ as a "non-answer" in 2015 [2]. I suspect the real reason is that it was a slightly risque joke...

Of course the Go keyword go is a constant reminder of Go's strong support for concurrency. (Note too the goroutine/coroutine pun.) It would be interesting to know which came first, the keyword or the name.

1. https://news.ycombinator.com/item?id=5182658 2. https://github.com/golang/go/commit/e4bd8e04087ac9e7c8b754df...


are basic languages good though? the amount of go concurrency bugs I've dealt with has been outstanding and quite brutal over the last few years; I feel like many times the same sort of c "i dont make mistakes" programmers are attracted to go and they also don't make mistakes there as well...


The problem creating a language that “anyone can get started with quickly” has the problem that it invites a host of people who have limited idea how concurrency, among other things, works. It’s important to understand C++ for that very reason is historical significance and how a system actually works underneath.

I think there’s a general gap in people’s knowledge as a lot of people just clock in but don’t read about stuff beyond what’s required “to get the job done.”


> the amount of go concurrency bugs I've dealt with has been outstanding and quite brutal over the last few years

Concurrency is hard. Maybe something like Erlang does it better, but compared the concurrency options in most popular languages, and the bugs that go along with those options, I think I would far rather deal with them in Go.

Perhaps the only reason you find concurrency issues in Go so frequently is because Go is more often used where concurrency is necessary, due to it being more suitable to writing concurrent code compared to many other popular languages? I certainly find more DOM bugs in Javascript than other languages, but I'm not sure that is a reflection of the language, only where the language is most often used.


> Concurrency is hard. Maybe something like Erlang does it better, but compared the concurrency options in most popular languages, and the bugs that go along with those options, I think I would far rather deal with them in Go.

Concurrency isn't really that hard in Erlang, and Erlang isn't the only language that handles concurrency well. "Concurrency is hard" is usually paired with an implicit refusal to learn paradigms that make concurrency easier.

Why are we only comparing Go to popular languages? When I first came across Go, before it was a popular language, I immediately started criticizing it because of the weak type system and ineffective concurrency model: I wanted the attention being given to Go to be given to a better language. Now I'm seeing the same people saying, "Okay, but the type system and concurrency are better than other popular languages." At face value, it makes sense to compare a popular language to other popular languages, but that logic breaks down because the only reason Go is popular is that a lot of people made the bad decision of choosing it before it was popular.


Oh, come on, that's not fair.

After I did a million lines in C (way back when), I still made mistakes (but fewer! still: not none!), but I had built better tooling and processes to help me find them earlier.

I was (as you say) attracted to Go, but with less accumulated tooling, the bugs take longer to find (that, and playing around with CSP, I guess, which is my own damn fault).


first two minutes are ads and fluff, fast forward them


Please consume the ads. Content isn't free.


What an ironic comment on an article whose subject is a massive, free, open-source piece of "content."


You know it's "free as in freedom, not beer," right?


Go is both free as in freedom _and_ free as in beer. Binaries and source are available for use or modification to anybody, free of charge. No ads either.


Go is free as in freedom and paid for by someone else.


Specifically paid for by Google which, as far as I'm concerned, is the definition of ad supported.


Clever, but beside the point. "Content isn't free" is still not a reason to plead that others "consume the ads." Google doesn't offer Go on the _condition_ that you consume ads, nor does this podcast or interview offer itself to the Internet on the condition that you don't skip the first two minutes of it. If you're somebody who is opposed to the practice of advertising in general, by all means, skip it. Nobody should tell you not to.


I can send you Go binaries. Name your price.


Yum.


No progress bar. No fast forward button. No speed-up.

Man this UX is frustrating.


There's a clickable progress bar with fast-forward button.

https://i.imgur.com/TMe45IJ.png

Also a download link for mp3.


With at least Firefox, there's a (non-obvious, due to colouring) progress bar a bit further down. Also lets you drag the play point around, to go back/forward/etc.


Don't.


Step 1: be rob pike. Step 2: invent a pretty basic programming language using your old compiler from Plan 9 while at google. Step 3: be rob pike. ^_^


The basic-ness of golang is the best part about it.


Shows me the power of a good standard library. Such a light weight language, but so many tasks that require third-party libraries in other languages are built right in with equally light weight interfaces.


Yes. Together with Jetbrain's Goland IDE, Go's simplicity allows for most engineers to hit the ground running in Go projects despite not having familiarity with the language. At least that was my experience while working in a team with newcomers.

The lingering issue was package management but then came Go modules and slowly but surely the community is migrating to it from godep and other tools.


This is true. It is also the worst part about it.


It's possible that a huge marketing advantage kept people interested long enough to come to appreciate the benefits of the langauge's basic nature.


I was drawn to Go because it was the only language at the time (or the only one I came across) that allowed me to build and package software without learning a domain specific language and imperatively stitching together my own build system (looking at you, CMake and Gradle). Basically I want to focus on writing my program, not writing programs to build my program.

Go let me run “go build”, and everything Just Worked. It has since become a little more complicated with the introduction of modules, but still vastly better than C++, Java, or Python.


I came to Go when modules had been released and found it much easier to understand than GOPATH style workflows. I guess to each their own. I agree, go build, and go distribution is so awesome.


I’m not opposed to modules; there are just some odd edge cases that have given me trouble; probably the error messaging just needs to be improved.


The building and deploying of Go code is refreshingly easy.


I see very little marketing for Go. Compare, for example, to C# when in came out, or Java when it did.


The marketing advantage is largely from being associated with Google and Pike and Thompson. That's a good way to get the world to spread the word for free.


IMO that’s the only reason it gained traction. New languages are a dime a dozen.


Did C# have actual "advertising" outside of msdn publications? It came out in 2000 and I don't recall seeing C# ads. (Print publications were out then.)

I picked it up early on and still use it (and F#) today. I've written a lot of custom desktop applications in it.


Yes, The C/C++ Users Journal, DrDobbs, PC World, and Computer Shopper run articles on it.

It was actually released in 2001.

Unless you are speaking about the alphas that MSFT Certified Partners had access to.


They ran articles, of course, but were there "advertisements?" These were publications writing about a major company's major new effort.

There's no advertising today, either. What happens is (for example) Rust/Mozilla foundation's people set out to make every thread on every popular forum about Rust.


It is my impression (from 18 years later!) that there was a difference. The articles about C#, back in the day, were kind of frustrating to a programmer (or at least to me). There were a lot of words, a lot of description, but not many details (as a programmer would recognize them). The articles were more written for managers than for programmers. That's marketing. (Or so it seems to me. It could be, however, that 18 years ago, I lacked the depth to see the details that were there.)

In contrast, Go's "marketing" is much more aimed at programmers. It's got programmer-level details. It's not trying to sell your manager on the language.

> What happens is (for example) Rust/Mozilla foundation's people set out to make every thread on every popular forum about Rust.

I completely disagree with this characterization.


Any kind of press is an "advertisement".

That is why people that write about technology are called advocates.


I remember going to Barnes and Noble and buying a programming magazine because it came bundled with a beta version of the .NET framework circa 2001.


You forgot that the 3rd co-creator was Ken Thompson.


Yeah but he's become a bit less reachable since.


The op was talking about being Rob Pike. Just responding that it wasn't just being Rob because Ken was on it, too.

Also, Rob mostly doesn't work on Go anymore. Russ Cox now leads it and has for some time.


Pretty much this, the only reason anyone gave Go any attention was:

1. The pedigree of the creators 2. Google's developer marketing

And now we are stuck with it thanks to traction.


Go is by far my favourite language to develop with. After having done Java, C#, C/C++ and python.

I still love functional languages more but for using something in the 'industry', I wouldn't want to use something else anymore.


To be honest, I write a lot of Go... it's my main work language and I use it for some of my hobby work too.

I love some aspects of it, for example, I love that you can generally look at a piece of Go code and grok it quickly. I love the lack of exceptions, but I strongly dislike the lack of good error handling facilities.

The standard library is really solid..., it has tons of very high quality implementations for low level OS and systems work and the API's are consistent.

The lack of Generics annoys me a fair bit. I do not love the module system at all. The Go folks somehow still managed to fuck up logging despite plenty of history in Python and Java about how not to do it, and how to build a good logging system. Also the lack of a good immutability construct really upsets me.


I feel people gave Golang attention because it was a good language. It also has the best standard library I’ve ever seen.


Like a standard library that doesn't even have a max function for integers, or a set type?


how easy to fuck up a max function?

Now look at the standard library and appreciate the fact that it comes with every crypto algorithm that are useful, heck it even comes with a crypto random function and a TLS implementation! Wait, it actually comes with a http(s) library. And with a json serializer/deserializer as well. Who does that?


Again that's the ethos of Go. In the many years I spent writing C++ or Python or Haskell I never had to write a max function because it's already there. I don't even need to think about it. And I can compose it easily to form more sophisticated things.

> Who does that?

Have you taken a look at the Python standard library?


I’ve never heard of anyone using crypto from the python standard library


It is trivial to write both of these on your own, why do we need unnecessary abstraction for such a simple task.


Sorting, appending to a slice, or removing from the middle of a slice are all awkward and bad in Go.


That's the ethos of Go. The standard library can be poor and woefully incomplete because hey it's easy to reinvent the wheel. And then instead of composing functions (say, a reduce function applied to max to find the max of a sequence), users just end up rewriting everything because it's trivial.


> Google's developer marketing

Like Google did marketing for Dart and it picked up?


Dart lost the support from Chrome team, it was rescued by AdWords team and Flutter is trying to make it relevant, but given Android team answers, it is clear that a power struggle is going on across teams.

Giliad is also a personality from language research hardly known by UNIX fans.


Seems like time killed the adoption of Dart into Chrome.

The chrome team had "been wanting to fix Webkit for a very long time, and the Blink fork made that possible"

Moving Blink from ref counting to a traced GC was part of that fix, it also was required to be completed to allow the Dart VM to be added to chrome. What was supposed to take months took years and with no end in sight the Dart team announced that its VM would not ship with chrome.

Lars announces the oilpan project Google I/O 2013. https://www.youtube.com/watch?time_continue=2850&v=huawCRlo9...



Thanks, have been looking for an update on toitware, had only found a 15 minute video in English by Kasper.

With Dart going down the flutter path, work on the dart iot project, dartino stop. Thanks again, just starting to watch the video now.


> it is clear that a power struggle is going on across teams.

What this has got to do with Dart's popularity outside Google?

> Giliad is also a personality from language research hardly known by UNIX fans.

So unix fans did not let a superior language which was designed by real language researcher like Dart win?


Exactly, had Dart been accepted into other browsers, and TypeScript wouldn't probably matter nowadays.

Just like WebAssembly wouldn't be a thing had PNaCL been accepted by others.

For UNIX fans, whatever a former Bell Labs researcher states is gold, no criticism whatsoever allowed.


curious how googles developer marketing got us a solid golang standard library


Or maybe because it is a useful and productive language?


I have feeling the people who praise Go didn't use too many other languages.

In my workplace Go is the preferred language, but I don't enjoy it, its type system stands in the way on every step.


It's almost as good as Blub, that's for sure...


Productive is an overstatement.

PS:I use Golang everyday.


Where exactly Google marketed the language, please gave us any example.


They talk about it at Google IO, for example.


But then to be fair, they also talk about Kotlin and other languages..


Which they also market, so?


The parent seemed to think they gave Go an unfair advantage by marketing it at Google IO. My point being that I don't think it's an unfair advantage as they mention non-google langs as well.


Google I/O has 0 materials about Go.


Today, because Go has its own conventions.

It used to have in 2012, 2013, 2014, etc...

https://blog.golang.org/go-videos-from-google-io-2012


Go only has the use that it does because of Google marketing, which the only examples given are talks at Google IO? Google has the most efficient marketing team in the world, to have done that much with that little effort...


I have no dog in this fight. The guy asked for any example, which I provided because I've personally seen go talks at IO.


> Google's developer marketing

Pretty sure Go was a huge 'failure' for a long time (in terms of marketshare)


The bar for a new language has become sky high. It takes years and years to even start to become a contender.

I observe this without celebration. It simply is.

Even Google's other languages, some of which have been around just as long, aren't even doing as well as Go.


What qualifies a language as "pretty basic" and why is that a bad or a good thing?


Being basically a copy of Limbo with Oberon-2 method syntax, although we are a bit further than 1992, to start with.

And while at it, offering less features as Algol used to have.


Offering less features was literally their goal in which they succeeded


Yes, I always find it surprising that people evaluate languages on the sheer number of features. As though the hallmark of a good language is having lots of complexity.


Because, the complexity doesn't go away, gets dumped into developers that keep re-writing boilerplate libraries that kind of compensate for the lacking features.

It happens all the time.

Language gets introduced at the sound of simplicity trumpet, tons of boilerplate libraries eventually appear, then if the language manages to make it in the mainstream, half baked features get introduced 'cause backwards compatibility.


Well, boilerplate is a nuisance, but it is cheap. It’s not generally where your bugs are coming from (and certainly not your most insidious bugs)—they come from your complexity, especially your incidental complexity. In exchange, Go is a very easy language to learn, which is an important property for software development teams—you don’t need to restrict your hiring pool to candidates with experience in $language; you can train anyone to productivity in _days_. This is actual cost savings over a nebulous idea that boilerplate is evil. Anyway, Go needs generics and sum types and those two features get rid of 99% of boilerplate and still keep it below an order of magnitude of the complexity that you see in Java, C++, etc, so I don’t buy your argument that the extra features are a net positive value.


The usual Go answer, Java boilerplate bad, Go's boilerplate good.

Java was once like Go, and ironically DisVM also had support for Java, back in those days.


Usually your responses are well-reasoned and interesting; this one was disappointingly lazy. I didn’t say Java’s boilerplate was bad nor that Go’s was good. I criticized Go’s boilerplate and Java’s complexity.


Which Java only got by starting out just like Go, being a simple language against the establishment, catering for easy to hire resources, ignoring the likes of Delphi, Modula-3, Sather and Eiffel, while building up on C++'s familiarity.

And adding half baked features to keep relevant while avoiding a Python 3, which any language that wants to survive in the market has to do, as not everyone can afford to alienate their user base.

If anything, Java complexity is the Ghost of Christmas yet to come of Go's future.


I think the important distinction is that Go holds simplicity as a virtue, while Java’s position was “please give us time to add all of the features you are requesting!”. How long was it before Java shipped exceptions and inheritance? If that isn’t a commitment to incidental complexity, what is?

By the way, it’s fine that Java takes a different philosophy on simplicity; Go’s trade offs won’t suit every use case. But I think Go’s tradeoffs are better for more use cases by a pretty wide margin.


Java had exceptions and inheritance right from the start.

If Go's wants to stay relevant it will eventually grow such features, no matter what.

Even C now has such niceties like _Bool and _Complex, because adding them was not considered relevant, let alone the bags of money that have been spent trying to retrofit security solutions while keeping backwards compatibility with the "C Spirit".

Oh and even if it is quite limited, modern C also has _Generic.


That’s the crux of the issue. Go aims to be useful, not relevant. Obviously some relevance is necessary for utility (a language isn’t useful if there is no community around it), but when you optimize for relevance directly, you end up with solutions in search of problems. Like inheritance.


Doesn't change the fact that it can be called "basic" for that...


Fewer


I'd love to see algol come back with a fresh syntax.


It offers developers less opportunity to show off how smart they are vs shipping stuff that works.

Go is outstanding for the latter.


Except the Go scheduler is actually pretty complex and really good at what it does...


The language is simple, the implementation is anything but.


From everything I've read, by people versed in compilers, the implementation is pretty basic too (regarding optimizations, shortcuts, compiler design, etc).

In fact, the Go core team themselves have said time and again that they preferred simple implementations and implementation convenience over more powerful but complex ones...


The Go implementation has gotten more sophisticated over time. It now has an optimizing SSA backend, a rather intricate GC, etc. I still disagree with a fair number of the Go implementation design decisions, but I certainly wouldn't call the compiler a basic implementation anymore.


Having worked on the Go port for SPARC with another person (don't know if it was ever completed), I have to agree with the parent here. The implementation of Go itself (based on 1.5-1.8 when I worked on it) was actually very complex. Large swaths of the codebase were completely uncommented and much of the knowledge about how the system is intended to work resides in the heads of the core Go team.


If only y’all could have just used llvm


For what it's worth, LLVM would have made precise moving GC hard. (Though Go 6g/8g still doesn't have moving GC, which is unfortunate.) For that reason, I'm not certain that LLVM would have been the best decision in the long term, though it would have made Go code faster in the short term.

In my view, if Cranelift had been around when Go was announced, it would have been the clear best choice over LLVM, due to compile times and relative simplicity allowing for easy modifications to add things like precise moving GC and moving stacks.


> In my view, if Cranelift had been around when Go was announced

Too bad cranelift is written in a language which wasn't even invented when Go was announced ^^.


Yes, because we all enjoy waiting for a compiler to get its work done, while keeping the myth alive that either C or C++ are required to write compilers.


To be clear, I've never been a Go team member -- I was a community member working on a port with another person.


That wouldn't have fixed the complexity.


Today, perhaps. But wasn't it the case for up until 1.3 or 1.5 that a lot of corners were cut, and things were much simpler than most "commercial grade" compilers (and not just in the simple = cleaner way, but also in the lacking sense).


Avoid messy, gobbledygook, weak and no typed programming languages along with giant bloatware languages.


When Go fanboys say stuff like "avoid weak and no typed programming languages" in relation to Go, it just shows they don't know much about type systems.

"No typed programming languages" aren't a thing. Some type is inherent to any programming language that runs on a computer, because at some point you have to shove the data into a range of memory and it will either fit or it won't. Assembly has types. They are very weak types, but they are types.

On a continuum of weak vs. strong types, Go is very much a weakly-typed language. If you think it's strongly typed, it's probably because of two things: 1) you don't have any experience with a strongly typed language like Haskell or OCaml, and 2) you don't know the difference between strong/weak types and static/dynamic types. There's a widespread misconception among Go programmers that Go has a stronger type system than Python, which is pretty false: Go's type system is more static than Python's, but it's definitely weaker than Python's in a few ways. Go does have a stronger type system than C, but that's not saying much.


Thanks for the follow-up


There's a step 1.5 in there about making sawzall too


Go is a new Visual Basic. Probably good for business owners, because of the lowbrow nature of Go language, developers are easily interchangeable, like a commodity.


While I dislike golang its runtime and compiler are nice. Also lot of its simplicity aspects are nice.

if vlang can implement what it is trying to implement then probably it will be a nice contender to golang in all aspects. But that looks too good to be true.

The other language is rust, but the higher learning curve make it a bit harder for adoption in non systems where go/java like performance is enough.


I mean, Crystal would be my next go-to. If you have never written Ruby (like me) the appeal isn't the Ruby-like syntax, it's just a reasonable syntax with a very pragmatic type system and niceties (like classes, which are more open to hacking / composition than in other languages). It's like Go++ in my mind.


Crystal is dead, exactly how can you expect to have a language that compete with Go with only 2 full time devs?


Does it have to “beat” Go or die?


No, but it definitely needs a community big enough to keep it alive.


Looking at their homepage it seems far from dead.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: