Creating the Go Programming Language [audio]
changelog.com
changelog.com
* 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.
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.
I still use GOPATH structure since it's such a nice way to organize my code.
There is no transcript.
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...
1. when used as a keyword to start a "goroutine"
go f()
go build ...
go get ...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...
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.”
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).
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 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.
Man this UX is frustrating.
https://i.imgur.com/TMe45IJ.png
Also a download link for mp3.
Also, Rob mostly doesn't work on Go anymore. Russ Cox now leads it and has for some time.
1. The pedigree of the creators 2. Google's developer marketing
And now we are stuck with it thanks to traction.
It used to have in 2012, 2013, 2014, etc...
Pretty sure Go was a huge 'failure' for a long time (in terms of marketshare)
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.
PS:I use Golang everyday.
In my workplace Go is the preferred language, but I don't enjoy it, its type system stands in the way on every step.
Like Google did marketing for Dart and it picked up?
Giliad is also a personality from language research hardly known by UNIX fans.
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?
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.
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...
With Dart going down the flutter path, work on the dart iot project, dartino stop. Thanks again, just starting to watch the video now.
I still love functional languages more but for using something in the 'industry', I wouldn't want to use something else anymore.
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.
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?
> Who does that?
Have you taken a look at the Python standard library?
"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.
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 picked it up early on and still use it (and F#) today. I've written a lot of custom desktop applications in it.
It was actually released in 2001.
Unless you are speaking about the alphas that MSFT Certified Partners had access to.
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.
That is why people that write about technology are called advocates.
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.
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.
And while at it, offering less features as Algol used to have.
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.
Java was once like Go, and ironically DisVM also had support for Java, back in those days.
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.
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.
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.
Go is outstanding for the latter.
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...
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.
Too bad cranelift is written in a language which wasn't even invented when Go was announced ^^.
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.