Live data from Hacker News

The Go Programming Language and Environment

cacm.acm.org

161–170 of 250 posts

Re: The Go Programming Language and Environment

#161
post #160
post #75

Earlier quoted context omitted.

>- Made by really famous veteran language designers - Backed by Google Looking at decades of how various programming languages gain popularity, those proposed reasons don't seem that convincing when we look at counterexamples . E.g. counterexamples of unknown (at the time) creators creating popular languages : Bjarne Stroustrup (C++), James Gosling (Java), Rasmus Lerdorf (PHP). E.g. counterexamples of famous computer…

"1) compiles to a single executable that's easy to deploy. This is a compelling advantage over Java,C#,Python,Ruby that require runtimes or complicated virtual environments." Docker makes deploying Java about the same as Go

Every Java app I've ever deployed, I needed to tune the JVM.

Well, not when I'm running something locally. Every app I've deployed professionally in corporate environments (which is most of my experience running Java), I needed to tune the JVM.

Re: The Go Programming Language and Environment

#162
post #41
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

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

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

I guess there are a lot of crazy people out there because I've heard this mentioned numerous times.

Re: The Go Programming Language and Environment

#163
post #30

Earlier quoted context omitted.

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…

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 API case for Go is absurd IMO because what libraries are there in Go that are simultaneously not widely available in other languages and also difficult to implement on your own?

People complain about Racket's ecosystem, but it has many libraries that would be PhD level effort to implement and are unique in its ecosystem such as Rosette and Redex. If some random REST API doesn't have bindings yet, implementing those myself isn't all that difficult.

Re: The Go Programming Language and Environment

#164

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.

For me, Go solved a lot of issues that I've had with both C and Python.

C is a nice language because there's no magic happening - functions are only executed if they are explicitly called. However, C had problems with strings, memory management, resource cleanup, undefined behavior, and probably a few other things I can't recall at the moment. It was also not designed with concurrency in mind, and glibc for some reason doesn't support static linking.

Python is a very nice language to work in, but there is a lot magic going around with all those Python protocols and magic methods. I also find myself making a lot of errors using exceptions - exceptions can happen at any point and there is no way to anticipate them, other than documentation, which leads to try/except boilerplate. And if I want to handle exceptions on a more granular level, I find myself writing try/except for every line I call, which is 2 lines of boilerplate - same as "if err != nil {" and "}". Also, CPython has a lot of dynamically linked dependencies, which makes containerization more difficult. There's PyInstaller, but PyInstalled doesn't seem to play well with non-pure-Python modules (uwsgi, for example). And concurrency in Python is terrible because of GIL, and asyncio is far from perfect, considering function coloring and inherent single-threadedness.

Go managed to become a language with a feel of Python but with certainty of C. It's like someone took C, fixed strings, added anonymous functions, automatic memory management, defer keyword for resource cleanup, sane concurrency model with channels and select. I think the name "select" comes from the Linux select syscall which allows you to wait for multiple file descriptors until one of them is ready - same thing happens with select and channels in Go. The select syscall (and its descendants) is the bedrock on which the whole asyncio world relies upon, so Go's concurrency design is already proven in practice.

When I write Go code, I'm rarely worrying about an exception popping out of somewhere. Panics do happen, but in most cases, they are caused by truly exceptional errors and warrant a crash.

And even though it's not a "systems language" in a kernel sense of the word, I've used Go to write video4linux applications, so it is certainly capable of making ioctls and manipulating C-like structures. Also it's statically linked, so it's possible to make really small containers with it, and easily cross-compiled, which is nice for portability.

Re: The Go Programming Language and Environment

#165
post #160
post #75

Earlier quoted context omitted.

>- Made by really famous veteran language designers - Backed by Google Looking at decades of how various programming languages gain popularity, those proposed reasons don't seem that convincing when we look at counterexamples . E.g. counterexamples of unknown (at the time) creators creating popular languages : Bjarne Stroustrup (C++), James Gosling (Java), Rasmus Lerdorf (PHP). E.g. counterexamples of famous computer…

"1) compiles to a single executable that's easy to deploy. This is a compelling advantage over Java,C#,Python,Ruby that require runtimes or complicated virtual environments." Docker makes deploying Java about the same as Go

A.k.a.: Why just have a single thing (a statically compiled binary), when you can have several moving pieces and different levels of infrastructure and configuration to worry about (the hypervisor, the container runtime, the container cli, the open ports and shared volumes configuration, the host OS image, the JVM inside the image, java memory and gc tuning, and so on)

Re: The Go Programming Language and Environment

#166
post #139
post #94

Earlier quoted context omitted.

We can sort of evaluate of much "backed by Google" means by looking at other languages backed by Google. The main one I have in mind is Dart. Here's a few links: - https://madnight.github.io/githut/#/pull_requests/2021/4 - https://www.tiobe.com/tiobe-index/ - https://redmonk.com/sogrady/2022/03/28/language-rankings-1-2... Dart seems to be doing relatively well. Considering Go has more things in its favor than Dart, i…

(Googler, opinions are my own) Similar to the peer comment to me, Dart languished for a long time. You have to remember Dart was created as a replacement for Javascript and that they wanted other browsers to embed the DartVM in their browsers. This got absolutely rejected by Mozilla, Apple, and Microsoft. They then attempted to use it as a transpiled language, but it always generated larger javascript files than most…

And even with all those troubles, it's still doing better than many many programming language, which was my point. The Google boost seems to be real and big.

Re: The Go Programming Language and Environment

#167
post #41
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

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

Yeah, I do agree that it's not a smart thing to say. But nearly all the times I saw somebody picking a platform to standardize on, they have a similar rationale.

I guess there are just no good reasons for choosing one platform over another to standardize a team. Or people that insist on standardizing tend not to act on good reasons.

Re: The Go Programming Language and Environment

#168
post #72

Go 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. - Portabil…

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

Re: The Go Programming Language and Environment

#169
post #88

Earlier quoted context omitted.

The 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 a…

Strongly 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),…

> fixing the data races. Go handles both of this for you from the start.

In what sense does Go handle (prevent) data races for the programmer?

In my experience (which is not _extensive_ but certainly non-trivial), Go programmers deal with all the same problems of shared mutable state that programmers of concurrent code in other languages deal with. Sure, mantras like "Don't communicate by sharing memory; share memory by communicating" are wise, but it's just a mantra, not anything the language provides for you. A skilled concurrent programmer will write code in this manner regardless of the language, and Go doesn't provide a ton as far as enforcing this.

Sure, you _could_ write your go program without any shared mutable state, but that gets convoluted fast.

Re: The Go Programming Language and Environment

#170
post #99

Earlier quoted context omitted.

>You can deploy c# app without having to install anything. The C# option of self-contained executables is very recent with VS2019 & VS2022 and was not available when Go came out in 2009 . Before that, you had extra steps of ClickOnce installer deployment or obscure AOT experiments that nobody was using in production. (Also as trivia, the new C#/NET6 self-contained executables don't work on Windows 7 and Server 2012.…

Let's not also forget that the .NET self-contained executables are huge in size compared to Go's. An ASP.NET app could be more than 100 MB

Many go apps are fairly large as well. Most of mine start at 10 MB and quickly reach 70-80 MB for fairly simple functionality for similar reasons (hosting runtime).
Post reply on HN