26 ms·
The Go Programming Language and Environment
- Normille 4y agoWeird article. It's basically an 'edited highlights' summary of another article, which it references. Here's the original: https://cacm.acm.org/magazines/2022/5/260357-the-go-programming-language-and-environment/fulltext#R16= https://cacm.acm.org/magazines/2022/5/260357-the-go-programm... I guess this is what passes for journalism, these days.
- Hendrikto 4y agoAnd the original article is better. For example, it mentions a huge contributor many commenters have pointed out: > Google's name was undoubtedly a draw.
- dang 4y agoOk, we've changed to that from https://thenewstack.io/what-made-golang-so-popular-the-languages-creators-look-back/ https://thenewstack.io/what-made-golang-so-popular-the-langu.... Thanks! Related: The Go Programming Language and Environment - https://news.ycombinator.com/item?id=31173395 https://news.ycombinator.com/item?id=31173395 - April 2022 (40 comments)
- DrBazza 4y ago* "easy" concurrency * rich standard library, particular for internet facing apps * "simple" language * single binaries * massive corporate support * rich or full toolset The first and second point fortunately "coincided" with: the move to multi-core chips, and the "second" dot.com boom of the 2010s. Which you could probably attribute to the rise of (Google) Chrome, and the decline (finally!!) of IE6, which held back a lot of "innovation".
- heleninboodler 4y agoI'd add "well designed" to the standard library point. When I first started using Go, one of the things that struck me was that not only was there tons of standard library functionality to do things I'd normally have to install 3rd party modules for in other languages, but those standard library modules (mostly) had well-designed, easy-to-use, and consistent interfaces. Mostly. I'll still never forgive them for making crypto.PublicKey an empty interface.
- dividedbyzero 4y agoI don't think Go's stdlib is particularly well-designed. It's not bad, not at all, but it doesn't seem to stick out in that respect.
- 0des 4y agoWhat's wrong with it?
- saghm 4y agoI haven't used Go in a while, but I remember there was some pain when `Context` began being used for a lot of new APIs but couldn't be introduced to older APIs for compatibility reasons. I also had some frustrations with what seemed like overfitting with standard libraries interfaces, e.g. the interface for closing something returning an error, so then every `close` method would return an error even if it was always nil (which stuck out more to me given that interfaces in Go are implicit, so it wouldn't really be that big a deal to just have a separate interface for closing things without returning an error and no code would have to be changed in all the places that would use it).
- ahoka 4y agoThis reads exactly like the joke where successful people describe their daily routine and one of the items besides things like running and meditating once a day is "my parents are millionaires".
- avgcorrection 4y agoMore like - Stable middle-class upbringing. Ah, I remember how nice it was to decompress at our summer house in Tuscany.
- arinlen 4y ago> (...) and one of the items besides things like running and meditating once a day is "my parents are millionaires". Also known as the Elon Musk school of bootstrapping. Step 1: have an emerald mine.
- mort96 4y agoThe concurrency is "easy" in that the syntax for spawning a thread is simple... but that's kind of it. Like other languages, it has a concurrent queue abstraction, and it has some syntax sugar to make using the concurrent queue nicer than some other languages. But like other languages, you end up in concurrency hell with mutexes and condition variables and semaphores and deadlocks. It has a concurrency story that's about as good as the likes of C++, and inferior to Rust (which errors at compile-time if you do something dangerous) or JavaScript (where the core event loop makes concurrency less necessary and concurrency is achieved with multiprocessing). In my experience, debugging concurrent Go is way harder than debugging concurrent C++, since the cheapness of spawning a new thread makes people much less careful about their threading model.
- fsociety 4y agoStrongly disagree. Yes, it is not a free lunch but they have made several deliberate decisions. If you code your Go like you would C++, you are not using the language in its intended fashion. They have nice features like a data race detector and deadlock detector. Channels are not just a concurrent queue, they have nice deliberate things built into them. They are based off of Communicating Sequential Processes (CSP), which has influenced other languages like Rust and Erlang as well. Green threads are very cheap, and therefore remove yet another thing to think about when using threading. They have made good decisions around the memory model for them as well. When I worked in C, the first thing we’d do in a new program is introduce a green thread-like scheduler so we could achieve concurrency. Then achieving parallelism is as simple, heh, as bumping up the number of worker threads and fixing the data races. Go handles both of this for you from the start. So sure, when you are aware of sound multi threading design, know what TSAN is, and have a lot of experience with C++ you can look at Go and scoff and say Rust is better. But for 90% of the programmers I meet in my career, especially those who grew up in the age of the internet, they do not have experience with this and greatly benefit from Go. I am in probably one of HN’s “most coveted” engineering companies, and barely anyone has worked in largely multithreaded programs. It is such a problem that we are now splitting services into processes to avoid handling multithreading. But over in our Go-world this is just not a concern. Seriously, Go is designed really well for backend services. I used to hate on it a lot, but after working at larger tech companies I have bought into it more for those use-cases.
- poulpy123 4y agoGoogle
- aurora72 4y agoI was about to say the same thing. Go is popular because it's initiated and backed up by Google.
- SenHeng 4y agoIf that were enough Angular would be more popular than it is.
- buster 4y agoAngular is indeed quite popular. Same as go is not the most used programming language in the world, angular may not be the most used frontend framework, but it's in the top tier.
- devnull3 4y agoAngular is not a language but a framework. A more reasonable comparison would be Dart. Besides, being backed by a $CORP is necessary condition but not a sufficient condition for a language to become mainstream.
- SenHeng 4y agoThat illustrates my point even better, what's Dart used for besides Flutter?
- arinlen 4y ago> If that were enough Angular would be more popular than it is. What are you talking about? Angular is already one of the two major frontend frameworks, the other one being Facebook-backed React. A couple of years ago Angular was the undisputed popularity king, to boot.
- 4y ago
- vsnf 4y agoThe CTO dictated our move to Go two years ago on what felt like a combination of whimsy and anti-Microsoft sentiment. I'll admit that there are parts of the language that are nice, such as the relatively snappy compile times and single statically linked binary output, but not a single day goes by where I don't miss C#, and more specifically .NET Core (now just .NET I guess?), which can do everything Go is doing.
- jamil7 4y agoYeah, the language itself has never really “clicked” for me, and I've tried a few times. It still feels cumbersome to write. The tooling, standard library and fast compile times are really great though. Maybe I'll revisit it.
- tinco 4y agoLike Go, C# has also always been a decade behind on the tooling side. For a recent project I wanted very fast HTML templating and I/O. Went with C# instead of Go and it's looking pretty good so far. The tooling is close to the level Ruby was ten years ago, and that was really acceptable. I was very happy with my previous project that I did in Go as well, you just can't go wrong with Go for implementing network protocols. If you need more than a microservice, then you need more than Go in my opinion, and C# is an excellent choice. I think most of these startups going mono-lingual on Go are going to regret it, just like the startups that went mono-lingual on Node.js a decade ago. If you're building anything that requires some serious architectural structure, and that might be easiest to implement as a monolithic app, then you need a language that supports that instead of getting in the way. Now with Typescript Node.JS might finally be suitable. But I'd definitely consider Ruby and C# or maybe Java or even Haskell first. Maybe Elixir, I heard that's still going strong as well.
- smcl 4y agoAh interesting, so I'm relatively happy working with C# and .NET. I'm interested in what you think might be lacking, is there an example of another language with some tooling not available in .NET? Note: not trying to pick a fight, I'm legit interested what I might be missing since I feel like my needs are pretty much covered :)
- deleted 4y ago[deleted]
- artful10 4y agoApart from the concurrency benefits, Golang provides actual value like C or C++. Therefore it got popular without incessant propaganda and a large consultancy ecosystem (unlike Python, which relies on brutal marketing: There are basically two uninteresting syntax posts on the front page every day, just to keep the brand recognition going).
- matthewmacleod 4y agoNo need to overthink it, I think – it fills a niche where there were poor choices before. It's a safe(ish) language offering a reasonably fast runtime, with good tooling, a standard library that covers most common requirements, some clever and clean API design, and which generates native binaries. It's pretty pragmatic in that sense. I still find it a bit of a frustrating wasted opportunity – the type system in particular just needs a few more steps to make me feel comfortable. But others may feel differently.
- mrwnmonm 4y agoIt doesn't stand in people's way.
- dividedbyzero 4y agoComing from years of Scala development, it does stand in my way all the time. It's so verbose and it's capabilities for abstraction are very limited, it's hard to do anything complex quickly without tons of code generation. I realize having a language with a gentle learning curve that ends at a very low level has its benefits if you want to commoditize software development, and lots of people want just that, but for me it does kill much of the fun. It doesn't seem very suitable for large-ish projects either, at least I haven't seen one that wasn't a mess yet.
- vintermann 4y agoI think it misses * Made by really famous veteran language designers * Backed by Google Not saying it doesn't deserve its popularity, but most of the things listed are not necessary for explaining its popularity, and none of them (even taken together) are sufficient.
- eb0la 4y agoIn my case "backed by Google" was a deterrent, not a feature. I gave the language a chance after trying Rust (backed by Mozilla - which was a feature to me ;-) and I found it easy to start. Go is very well documented: That was the killer feature for me. No more search tutorials / videos etc. - just get the go book, read it, and start coding. Of course there are tutorials and videos everywhere for fun stuff. But good documentation is more important than we think - even in the 21st century!
- intothemild 4y agoI agree here. Using the two examples go and rust, Go's documentation is on another level compared to rust, it's more common to see examples in Godoc's than in Rust documentation... That's not a failure of Rust or the maintainers, it's just a different culture I guess. If I want to do something in Go with a new lib, i can easily put together what I need to do using the documentation. Where as with Rust, it's often confusing to the point where if they don't have an examples folder on the library, I'm shit out of luck understanding how to do something.
- gameswithgo 4y agoI don't think Go's documentation is better than Rust, Go is just a lot simpler than Rust. Especially if you are a programmer with a background in any of the C-ish syntax languages (C,C++, javascript, Java, C#, etc), its just really easy to pick up. Rust is a mind bending ordeal by comparison with both the borrow checker and other foreign ideas that take a while to come to terms with.
- 4y ago
- shaftoe444 4y agoThree things: tooling, tooling, tooling.
- drawingthesun 4y agoI’m pretty sure the Google name association can explain the languages popularity. I remember reading novices wanting to learn Golang due to the Google name attachment. That propelled the language into many minds, especially new programmers.
- tomcam 4y agoThen why is Dart much less successful?
- rapsey 4y agoBecause Dart is not used to write backends at Google.
- JavaOnlyGuy 4y agoBecause it's selling point is Flutter? Where you're forced to use Dart?
- 0des 4y agoIts
- frou_dh 4y agoDart had quite a long history before Flutter even came into the picture. Flutter is the answer to the question of why is Dart somewhat relevant today, but not to the question of why Dart didn't take off in general during its first 5 or so years, despite the fanfare of coming from Google.
- pjmlp 4y agoMicrosoft, Apple and Mozzilla did't felt like integrating DartVM on their browsers, that is why.
- pjmlp 4y agoInternal politics.
- andyonthewings 4y agoWhat I'm more interested in is the comparison between the cases of Go and Dart, which both are languages developed by Google. Why Go is so much more successful (in the system programming domain) than Dart (in the web/mobile/desktop domains)? Many of the listed good choices (e.g. being developer-focused) can be (had been?) applied to Dart as well.
- mattlondon 4y agoI think the issue was, what was dart useful for that JavaScript or typescript didn't already solve? You had a new language that needed a separate VM to execute that offered basically nothing that typescript/JavaScript didn't already offer. There was no compelling reason for it to exist apart from "just because" - I think that had typescript taken off a few years earlier then they'd probably not have bothered with dart. Go brought something new that answered an issue developers were facing: easy concurrency in a high performance garbage-collected language that compiled to a single binary with no dependencies. C/c++ did not offer that, nor did java, nor did python. Go filled the gap in the market.
- sltkr 4y agoNot to turn this into a language debate, but I think it's worth pointing out that Dart is a completely new language that has a more succinct syntax and more sensible semantics than JavaScript. TypeScript is different in that it intentionally is just JavaScript with type annotations. That makes TypeScript easy to adopt but it also means it inherits a lot of JavaScript's flaws. For example, in TypeScript you still have nonsense like "this.method = this.method.bind(this)" while in Dart, method tear-offs just work. In Dart it's trivial to implement classes with value semantics that can be used as keys in a Map or Set, which is basically impossible in JavaScript. And so on. I think most people would agree that Dart is just a much better language than JavaScript or even TypeScript. So the succcess of TypeScript is best understood as building on JavaScript's existing popularity. > I think that had typescript taken off a few years earlier then they'd probably not have bothered with dart. I always suspected that Google's investment in Dart was related to the Oracle lawsuit over the use of the Java API in Android. Remember that Dart is also the language behind Google's cross-platform app framework Flutter, which was developed while the Oracle case was still in court. I suspect that Google wanted to ensure that for Flutter they used a language and API that Google unambiguously owned the rights to, to avoid another debacle. (Then a better question might be: why didn't they just use Go for Flutter? The technical answer could be that Go is more of a systems language like C/C++ and less suitable for UI code. In truth it might just be a common case of Google starting multiple indepent projects that accomplish vaguely the same goals.)
- orian 4y agoOriginal article [source]: https://cacm.acm.org/magazines/2022/5/260357-the-go-programming-language-and-environment/fulltext https://cacm.acm.org/magazines/2022/5/260357-the-go-programm...
- pjmlp 4y agoEasy, - Backed by Google - Plan 9 and UNIX people as designers - Docker migrated from Python to Go - Kubernetes migrated from Java to Go - After Docker and Kubernetes explosion, all Cloud Native Foundation projects start using the same language, thus adoption
- giancarlostoro 4y agoI had no idea Docker and Kubernetes migrated. I assumed they were both Go from the onset.
- pjmlp 4y agoYes, When Docker migrated away from LXC the new code was in Go, https://www.infoq.com/news/2014/03/docker_0_9/ https://www.infoq.com/news/2014/03/docker_0_9/ Kubernetes moved when some Go advocates joined the team and pushed for a rewrite, https://archive.fosdem.org/2019/schedule/event/kubernetesclusterfuck/ https://archive.fosdem.org/2019/schedule/event/kubernetesclu...
- arinlen 4y ago> Kubernetes moved when some Go advocates joined the team and pushed for a rewrite Frankly, that hardly says anything about the technical merits of that switch. In fact, it reads like a poorly-though tautology.
- pjmlp 4y agoJust paraphrasing the FOSDEM talk in one sentence, so....
- 0des 4y ago
- Zababa 4y agoBut nobody is talking about the technical merits of that switch or of Go, we're talking about the popularity of Go. If tomorrow I create a language called "Gorilla" that is a worse language than Go, that Kubernetes switches to Gorilla and that Gorilla gets popular, there's a good chance that the switch will help the popularity of Gorilla. If instead I create a language called "Whale" that is a better language than Go, and the same thing happens, again the switch will have helped the popularity of Whale. The exact same thing will happen with a language exactly the equal of Go. All of that to say, technical merit has nothing to do with it, it was never the subject.
- KingOfCoders 4y agoStarted a project in Golang this week. Looked into web frameworks and was underwhelmed. Settled with Echo as it seems to have the only decent documentation. Still no good templating library, will settle with html/template and try to add something else for template inheritance. (I chose Golang for the best async scheduler and the very fast compile times).
- theshrike79 4y agoGo has the same problem as Python when it comes to web frameworks. It's just so easy to whip op your own middleware on top of the standard library, so there is no One True Option for middleware/framework.
- suprfnk 4y agoWhat do you mean? I don't do Python, but I know of at least three Python web frameworks: Django, Flask, and FastApi.
- metaltyphoon 4y agoThis is where the problem lies. Everyone and their mom thinks it's trivial to do authentication and authorization (as an example), so they keep rewriting things and in many cases full of security bugs, instead of using something created by people with expertise.
- divan 4y agoTake a look at GoBuffalo
- KingOfCoders 4y agoThanks!
- icedchai 4y agoCoincidentally, I was also evaluating various go web frameworks, and also decided on Echo.
- pif 4y ago1 - Golang was created for sub-average programmers, thus half of us soon discovered a way to ship more bugs around, more quickly. 2 - Many unlucky ones in the other half found themselves stuck in environments where the former half was over-represented.
- 0des 4y agoThis is bait
- mountainriver 4y agoThis is true but the reality is that most teams have lots of average programmers and Go does a lot to keep them productive and prevent foot guns
- davidkuennen 4y agoFor me it's development speed through compile time and easiness. Extending my service is so fast. Just write the the code, compile it in seconds and it mostly works 90% first try. Love it so much.
- atraac 4y ago> Extending my service is so fast. Just write the the code, compile it in seconds and it mostly works 90% first try. This basically describes... every popular programming language. How would this be different in f.e. C#? Compile times might be a tad bit faster but that's about it?
- metaltyphoon 4y agoNo even anymore, for most changes done in C# using web apis (what go does best), you don't even have to recompile the entire code. It's actually faster doing it in C# by just `dotnet watch` and let hot-reload do its thing.
- lenkite 4y ago> Compile times might be a tad bit faster Compile times are extra-ordinarily faster. The difference between Heaven and Earth to use Xianxia terminology.
- divan 4y agoFor me it were four things: 1) no bloat 2) great tooling 3) speed, speed, speed 4) developed by legends in Computer Science To expand a little bit more: 1) Go is still the only language is not developed by analogy (i.e. let's do X because all other languages have it). It's designed from the first principles, and that's why so many newcomers are buffed about weirdly different take on things they consider "basic" or "common sense". "Less is more" sounds funny for people coming from the feature-bloated languages. For me, minimalistic feature space was a breath of fresh air. I liked how Go authors see it as a vector space, with features being basis vectors (that's where "orthogonality of features" comes from in the articles about Go). Thus Go is optimized to simplify the search for the optimal path in that vector space which is a proxy for cognitive load while writing code. I'm not sure why it's noy obvious for other languages designers, but seems like "the more features - the better" narrative is rarely questioned. Go holds its stand firmly here. 2) Go tooling got it fair share of praises, and inspired other languages and frameworks to follow the same approach. Rustfmt or single binary `flutter` tool for everything are good examples. But back then in 2013 it was, again, an unusual approach that reflected some amount of thought and design put in it. (As opposed to the zoo of different commands, approaches and tools in many other languages). 3) Go was quite close to hardware – you could play with structures bit packing if you need to. Witnessing how whole companies burn cash to scale servers while using memory and CPU hungry languages (and not raising an eyebrows over that), Go seemed like a perfect choice for anything server and backend related. 4) Appeal to authority is not a logical fallacy when the authority is an actual authority. Designing a programming language requires more than CS course on compilers. Go authors had extremely deep understanding of hardware and software internals (obviously), but also had *decades* of practice in different teams, companies and even epochs. That made me trust their decisions over my initial responses. I still remember how I was mad at gofmt ("Who the hell they think they are to tell me how I want to format my code!"). Needless to say I was struck by how incredibly useful that turned to be at scale. What was never on my list of Go selling points is that it was originated in Google. Never understood this argument. I have more respect to Apple than to Google, yet I'm not writing Swift just because it's backed by company I respect more.
- metaltyphoon 4y ago> newcomers are buffed about weirdly different take on things they consider "basic" or "common sense" Yep makes sense: "2006-01-02 15:04:05"
- ivoras 4y agoI'd add one more thing: it doesn't change. Compared to most languages, Go hasn't changed at all over its 12+ year history. It took that long to get generics, ffs. It can be a good thing. It certainly reduces the cognitive load needed to learn the latest and greatest addition to C++ or JS.
- deleted 4y ago[deleted]
- AnimalMuppet 4y agoFor that to work, though, the language had to be pretty close to "right" (i.e., usable) from the beginning.
- Andys 4y agoI find the reason it works is because it has a smaller surface area and the culture is to even enforce formatting (with go fmt). Your brain has an easier time coming back to things and parsing them, even if the language isn't exactly "right".
- dgb23 4y agoGo is successful for similar reasons as Java. - Backed by a well known Company with a good image (at the time). - Made by well known experts at the top of their field. - Most of the risky, complex and powerful stuff is in the runtime. - The language surface is small, familiar, conservative and consists of mostly orthogonal features. - Very straightforward to integrate libraries and a good standard library. - Portability and deployment are primary concerns. - Came out at just the right time. - Evolves without breakage. There are significant differences between those languages, for example the JVM is a much more dynamic runtime. But I think the conservative surface paired with powerful internals is what makes it so attractive for wide adoption. It is the "blue collar" language strategy. Languages that have more unique value propositions, lean stronger on niche paradigms and give more power to the programmers are scarier from a mainstream business perspective. I think these kind of languages have a firm stand in their respective niches and will continue to grow steadily, but will stay specialized and at the edge, while mainstream languages slowly adopt features that have been proven to work in other ecosystems. Go is a language that belongs to the mainstream category, like Java, C#, JavaScript, Python etc. They are "Worse is better" languages that trick you into adopting some good stuff unknowingly and they all have a laser focus on pragmatism and growth.
- DonaldPShimoda 4y agoOne area in which Go lacks is its static type system. Until recently, it was practically straight out of the '70s. Static type systems are a mechanism for outlawing the compilation of programs that are known to be problematic at the expense of outlawing comparatively few good programs — a worthwhile trade-off for a language meant to be used in industry, especially when writing complicated code. It's a shame because they absolutely could have built a better type system on the backs of all the advancements of the past half-century, but deliberately chose not to due to what I can only see as being the perspective of people who had only previously used obnoxious static type system (e.g., Java's) and decided "well we don't want that, and 'that' means types, so let's provide as inexpressive a type system as possible."
- Jabbles 4y agoAre you responding to the parent's post and suggesting that this is something to do with Go's success, or are you simply complaining?
- goodpoint 4y agoHype and marketing. Go has been pushed pretty hard by Google to make developers easier/cheaper to hire and replaceable. The quotes are very telling: http://nomad.uk.net/articles/why-gos-design-is-a-disservice-to-intelligent-programmers.html http://nomad.uk.net/articles/why-gos-design-is-a-disservice-...
- joshyi 4y ago100% + Google $$$
- korginator 4y agoGoLang works for my team because it's boring, small, compact, not fancy, easy to pick up and start writing real production code in less than a week. It hits the sweet spot with regards to language constructs, performance, features, superb documentation, and a de-facto set of practices and design principles that make it easy to pick up a completely new codebase and understand it very quickly. It works very well with VSCode and even better with IntelliJ IDEA, debugging is painless, and it even runs on our Raspberry PIs and other IoT devices. We use GoLang on a whole bunch of MIPS and ARM devices, it's a great option seeing as how quickly we can get production code up and running on small edge devices, routers, etc. Sure, we can write embedded code in C, but GoLang allows us to roll out new features three to five times quicker.
- latchkey 4y ago> On the production side, Google was running very large systems. For example, in March 2005, one 1,500-CPU cluster of the Sawzall log analysis system processed 2.8 PB of data.26 In August 2006, Google's 388 Big-table serving clusters comprised 24,500 individual tablet servers, with one group of 8,069 servers. Neat. I have a custom golang binary (~20k loc) running on a cluster of close to 20k baremetal servers. As a language, it isn't perfect and I have some complaints, but it was definitely the best tool for this job.
- xedrac 4y agoI've only written about 20k lines of Go code, but Rust has somewhat ruined Go for me. It's really hard to pick Go when I know Rust can do the job better and with fewer resources and bugs. I do think Go brought some good things to the industry though.