Live data from Hacker News

The Go Programming Language and Environment

cacm.acm.org

181–190 of 250 posts

Re: The Go Programming Language and Environment

#181
post #160

Earlier quoted context omitted.

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

I'm surprised. Latest JVM versions are tuned really well out of the box. Tuning is a good thing by the way. Its the reason Java can handle areas that Go can't.

Re: The Go Programming Language and Environment

#182
post #176

Earlier quoted context omitted.

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)

Maybe you are building a standalone utility in Go that can be downloaded as a single binary. Great. Most places I work at, deploy to Kubernetes as docker containers

Given that the context on this subthread is how a benefit from Go is that it "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."

I fail to see how this information about "most places you work for" is relevant.

Even if that's the case, you can always also deploy Go with kubernetes and whatever.

But you can't deploy most of the others as a single static binary.

(Getting one out of Java, for one, requires some half-arsed non-really-supported solutions, whereas getting one out of Go is the default).

Re: The Go Programming Language and Environment

#183
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 t…

Wow, I’ve never heard this bullshit before.

Re: The Go Programming Language and Environment

#184

Earlier quoted context omitted.

Are you responding to the parent's post and suggesting that this is something to do with Go's success, or are you simply complaining?

Ah, you're absolutely right. I rewrote some parts of my comment a few times and accidentally removed the bit that actually connected it haha. My point was that Go seems to have managed to be successful (for some reasonable definitions of "successful") despite at least one large deficiency. In fact, it is the same deficiency for which Java's success can be said to be surprising, though Java had ~20 years fewer history…

> they squandered at least one significant aspect of the language design due to (in my opinion) a lack of knowledge in the relevant area.

Why do you believe the reason was lack of knowledge?

Re: The Go Programming Language and Environment

#185

Earlier quoted context omitted.

Are you responding to the parent's post and suggesting that this is something to do with Go's success, or are you simply complaining?

Ah, you're absolutely right. I rewrote some parts of my comment a few times and accidentally removed the bit that actually connected it haha. My point was that Go seems to have managed to be successful (for some reasonable definitions of "successful") despite at least one large deficiency. In fact, it is the same deficiency for which Java's success can be said to be surprising, though Java had ~20 years fewer history…

One of HN's guidelines is "charitable assumption". It specifically is required toward other posters. But you might extend that charity to Go's creators.

They actually were experts at the top of their field. Assuming a lack of knowledge is both uncharitable and, frankly, arrogant. It would be better to assume that they made choices other than the ones you would have made, and did so with eyes wide open and full knowledge.

Re: The Go Programming Language and Environment

#186

Earlier quoted context omitted.

Are you responding to the parent's post and suggesting that this is something to do with Go's success, or are you simply complaining?

Ah, you're absolutely right. I rewrote some parts of my comment a few times and accidentally removed the bit that actually connected it haha. My point was that Go seems to have managed to be successful (for some reasonable definitions of "successful") despite at least one large deficiency. In fact, it is the same deficiency for which Java's success can be said to be surprising, though Java had ~20 years fewer history…

You can safely assume that there was no such thing as lack of knowledge about type systems and language design.

Re: The Go Programming Language and Environment

#187
post #65

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

For that to work, though, the language had to be pretty close to "right" (i.e., usable) from the beginning.

Re: The Go Programming Language and Environment

#188
post #120

Earlier quoted context omitted.

>> but it's weakly typed and very unsafe Oh here we go :-) and yet the world spins on C kernels and lands jumbo jets in C autopilots and regulates heartbeats with C pacemakers and, and, and … It seems there’s more nuance to this than just “strong types good”. >> people went for C because speed was considered more important than safety But for the past 10-27 years people have the choice to use a fast and safe language…

> fast and safe language (java, C#...) No, no even close. Java and C# crawled on a Pentium III-IV even with SSE2 compared to C and C++. If you said Ocaml...

I started using java at 1.4, i remember Sun shouting to anyone who would listen that HotSpot could beat the gcc of the time on some 32bit integer benchmarks. IIRC it wasn't a million miles off the pace for floating point operations either.

Re: The Go Programming Language and Environment

#189
post #58

For 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 "c…

> Go is still the only language is not developed by analogy [...]. It's designed from the first principles,

It's really not even close to that though if it is such an principles-first language at all (maybe it is, certainly not the only one in existence) it's unusual among such language in not being a pure implementation of an easily articulable paradigm.

Re: The Go Programming Language and Environment

#190
post #181

Earlier quoted context omitted.

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.

I'm surprised. Latest JVM versions are tuned really well out of the box. Tuning is a good thing by the way. Its the reason Java can handle areas that Go can't.

Yeah, although it seems to be taking a while for everyone to update to the latest and greatest JVM versions.
Post reply on HN