The Go Programming Language and Environment • Hacker News Board

Re: The Go Programming Language and Environment

#121

Post by latchkey » Tue, May 31, 2022, 4:58 PM UTC

> 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.

Re: The Go Programming Language and Environment

#122

Post by anthk » Tue, May 31, 2022, 4:59 PM UTC

pjmlp wrote: post #78

arinlen wrote: post #60

Earlier quoted context omitted.

> The amount of Go projects in Cloud Native Foundation shows otherwise. That says nothing at all, actually. Beyond the transparent appeal to authority, why would anyone take decisions seriously when they are made without any technical merit in mind and just follow a mix of cargo curlting and pushing in-house tools, such as the case of the kubernetes migration to Go? > Most people pick languages based on platforms, no…

Docker took the decision to pick Go when it was at version 1.2, hardly that much proven into the battlefield. In 2014 unless we are talking about Ada, there were hardly any better alternatives to C++. If Go is so much better, why does Python eco-system keeps using C++ instead of Go for ML libraries?

>C++ instead of Go for ML libraries?

Because (Open)Blas, Atlas and such have decades of C/C++ implementations.

Re: The Go Programming Language and Environment

#123

Post by christophilus » Tue, May 31, 2022, 5:00 PM UTC

eb0la wrote: post #30

vintermann wrote: post #16

I 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.

In 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…

> In my case "backed by Google" was a deterrent, not a feature.

I'm the same. For me, it was some combination of:

- I can build useful stuff with few dependencies

- I don't have to wait seconds for compilation

- I can trivially build, scp the build artifact, and run it

Re: The Go Programming Language and Environment

#124

Post by anthk » Tue, May 31, 2022, 5:01 PM UTC

mountainriver wrote: post #102

arinlen wrote: post #41

Earlier quoted context omitted.

> - After Docker and Kubernetes explosion, all Cloud Native Foundation projects start using the same language, thus adoption This take sounds highly unrealistic. No one in their right mind would ever say "well Docker/Kubernetes were developed in Go, thus that means it's a good idea to develop a totally unrelated application that bares no resemblance or shares any use case in Go as well". Also, migrating away from an…

That is very much what happened. Go became the de facto language in the cloud native community, which to this day is its biggest crowd

Well, Plan9 was the cloud (networked) OS simplyfing C and making Unix even more ubiquitous, so it has sense.

Go is the legacy of Plan9 "ported" back to Unixlikes and C.

Re: The Go Programming Language and Environment

#125

Post by nwsm » Tue, May 31, 2022, 5:03 PM UTC

smcl wrote: post #29

tinco wrote: post #12

Earlier quoted context omitted.

Like 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 protoc…

Ah 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 :)

My .NET experience is about 1 year out of date, but at the time the ecosystem was in a really great spot. First class Linux and Docker support, your choice of editor/IDE with VS, Rider, and VSCode, and nice test and profiling utilities.

Historically though (pre-.NET Core), .NET was always in a Microsoft bubble which held it back as the industry consolidated on Linux and Docker. The person you're replying to may agree that C# tooling is currently pretty good.

Re: The Go Programming Language and Environment

#126

Post by nwsm » Tue, May 31, 2022, 5:05 PM UTC

pjmlp wrote: post #33

Easy, - 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

esbuild [0], a JavaScript bundler, has made waves in the frontend community over the past couple years for being orders of magnitude faster than alternatives and written in Go (as opposed to Node.js which is the usual choice for obvious reasons).

[0] https://esbuild.github.io/

Re: The Go Programming Language and Environment

#127

Post by ohCh6zos » Tue, May 31, 2022, 5:07 PM UTC

dividedbyzero wrote: post #32

mrwnmonm wrote: post #14

It doesn't stand in people's way.

Coming 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…

I’m in the same boat. Go lacks abstraction to the point source becomes hard to read due to lack of abstraction.

Re: The Go Programming Language and Environment

#128

Post by saghm » Tue, May 31, 2022, 5:14 PM UTC

0des wrote: post #84

dividedbyzero wrote: post #26

Earlier quoted context omitted.

I 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.

What's wrong with it?

I 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).

Re: The Go Programming Language and Environment

#129

Post by lifefeed » Tue, May 31, 2022, 5:15 PM UTC

vintermann wrote: post #16

I 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.

The "Backed by Google" is an under-appreciated social piece of the puzzle. It's not just that Go has institutional backing, it's that googlers produce a lot of startups, and they bring their favorite things with them, and quite often one of those things is Go.

Re: The Go Programming Language and Environment

#130

Post by kjksf » Tue, May 31, 2022, 5:15 PM UTC

usrusr wrote: post #79

traceroute66 wrote: post #68

Earlier quoted context omitted.

To me, in the old Go vs Rust debate, there are two things that are abundantly clear in making a compelling case for Go. First, I don't think even the most devoted rustacean can deny that Rust has a hell of a learning curve. But perhaps most importantly is that Go has a strong and extensive standard library that covers many 21st century applications (e.g. talking to REST APIs). The problem to me with the Rust "no stdl…

The most interesting thing about the go vs rust debate is that it happened. In hindsight it seems abundantly clear that they aim for entirely different fields with negligible overlap, almost as if you'd lump together tennis and golf because they are both ball games with a somewhat upperclass bias ("how different can they be? And I hear polo is the same but with horses!"). But back then? Yeah, I was kind of expecting…

Rust and Go are both general purpose languages.

They overlap way more than they don't i.e. there is way more software that you can write in both languages than software that you can write in only one of them.

The "best language for the job" is mostly a myth.

The choice of language is mostly dictated by what you cannot do, rather than what you can do.

Can I use Go or Java to program a micro-controller with 128 kB of RAM? Not really (at least no using the official, non-crippled implementation) because even "hello world" in those languages exceeds that 128 kB limit.

If I'm writing a cmd-line app that I want to ship as a single binary for Windows and Mac and Linux, I'm not using Python. Technically it's possible but very few are doing it while Go gives me out of the box multi-platform compilation.

The reality is that the majority of software written today falls into one of those categories: * web frontend, running in the browser, by necessity written in JavaScript or something that transpiles to JavaScript. Both Go and Rust are out of this game * web backend and similar server software: both Rust and Go compete for that * command line apps : both Rust and Go compete for that * games : AAA games are pretty much C++, Go and Rust are out (although Rust could, in principle, work)

So in most cases both Rust and Go are unsuitable for the task or they compete for the task.