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.
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...
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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, 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.
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.
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.
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.
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.
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).
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.
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.
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.
Rust may have a "higher learning curve" but it also takes a "learning curve" to learn to debug memory errors. I argue that it's actually quicker to learn Rust.
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.”
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).
> 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.
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.
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.
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.
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.
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.
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 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"
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.
134 comments
[ 2.9 ms ] story [ 115 ms ] threadAlso, 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...
https://blog.golang.org/go-videos-from-google-io-2012
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...
https://www.youtube.com/watch?v=mPna6D21Eqg
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.
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.
* 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.
I still use GOPATH structure since it's such a nice way to organize my code.
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"
2. when used from the command line for compilation etc.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...
There is no transcript.
Man this UX is frustrating.
https://i.imgur.com/TMe45IJ.png
Also a download link for mp3.
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.