The Go Programming Language and Environment • Hacker News Board

Re: The Go Programming Language and Environment

#201

Post by rob74 » Wed, Jun 01, 2022, 3:48 AM UTC

timbit42 wrote: post #91

CraigJPerry wrote: post #57

Earlier quoted context omitted.

>> Made by really famous veteran language designers Yeah that’s a positive >> Backed by Google But that’s a negative, https://killedbygoogle.com/ I definitely think you’re too fast to dismiss the language features contributing to popularity. As an example: Fast builds are a positive developers immediately warm to when they experience them (stand by for rustacean “i need time to make tea and my compile times are exact…

>> Made by really famous veteran language designers > Yeah that’s a positive No, that's also a negative. C is close to assembly and produces fast code but it's weakly typed and very unsafe. Pascal was the strongly typed and safe option but people went for C because speed was considered more important than safety back when processors were slow. In today's online world, we've realized safety is more important than spee…

The "Pascal-like" elements are the contribution of Robert Griesemer (https://en.wikipedia.org/wiki/Robert_Griesemer), who studied in Zurich and is also a co-creator of Go. The syntax has the curly braces and other C-family elements to appear more familiar (plus nobody really wants to write "begin ... end" all the time), but the declaration syntax is also Pascal-style ("x int" instead of "int x"). What reminded me most of Pascal when I first saw it was the ":=", but it has a different meaning in Go than in Pascal.

...and "really famous veteran language designers" wouldn't become famous veterans if they wouldn't learn something along the way.

Re: The Go Programming Language and Environment

#202

Post by morelisp » Wed, Jun 01, 2022, 5:45 AM UTC

jasode wrote: post #75

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.

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

If James Gosling was an unknown I wonder what your criteria for renown is.

Re: The Go Programming Language and Environment

#203

Post by pjmlp » Wed, Jun 01, 2022, 5:53 AM UTC

jasode wrote: post #99

hardware2win wrote: post #97

Earlier quoted context omitted.

>This is a compelling advantage over Java,C#,Python,Ruby that require runtimes or complicated virtual environments. You can deploy c# app without having to install anything.

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

NGEN, MDIL, .NET Native, Xamarin weren't obscure AOT experiments that nobody was using in production.

Re: The Go Programming Language and Environment

#204

Post by pjmlp » Wed, Jun 01, 2022, 5:54 AM UTC

coldtea wrote: post #182

eweise wrote: post #176

Earlier quoted context omitted.

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

Last time I checked, Go has a runtime as well.

Re: The Go Programming Language and Environment

#205

Post by pjmlp » Wed, Jun 01, 2022, 5:56 AM UTC

tsimionescu wrote: post #173

eweise wrote: 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

Except a Java container running a simple REST server is going to be a few hundred megs, while a similar Go container will be around 10 megs most likely. Which doesn't matter all that much until you're distributing an app made out of 10-20 such services...

Since Java 9 one can tier it down with jlink, previously the uberjar plugin could also be used for similar purposes.

Re: The Go Programming Language and Environment

#206

Post by pjmlp » Wed, Jun 01, 2022, 5:57 AM UTC

klodolph wrote: post #161

eweise wrote: 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.

While in Go it gets rewritten in Rust instead, because it lacks the tuning knobs.

Re: The Go Programming Language and Environment

#207

Post by lenkite » Wed, Jun 01, 2022, 6:25 AM UTC

DonaldPShimoda wrote: post #168

dgb23 wrote: 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…

More type theory heaviness === grand compile time. There is a natural correlation. Go chooses dev efficiency here over comprehensive type checking.

Re: The Go Programming Language and Environment

#208

Post by lenkite » Wed, Jun 01, 2022, 6:26 AM UTC

atraac wrote: post #71

davidkuennen wrote: post #56

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

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

> Compile times might be a tad bit faster

Compile times are extra-ordinarily faster. The difference between Heaven and Earth to use Xianxia terminology.

Re: The Go Programming Language and Environment

#209

Post by DonaldPShimoda » Wed, Jun 01, 2022, 6:38 AM UTC

lenkite wrote: post #207

DonaldPShimoda wrote: post #168

Earlier quoted context omitted.

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…

More type theory heaviness === grand compile time. There is a natural correlation. Go chooses dev efficiency here over comprehensive type checking.

I think minimizing compile time is a weird metric to prioritize. It's essentially asking "Would I rather guarantee my program is more correct or save a few seconds each time I compile?"

I would also point out that not forbidding bugs that would be caught by a type-checker will decrease efficiency. You just won't realize it when it happens.

Lastly, the impact on compile time doesn't have to be so great to be problematic. Plenty of languages with more expressive type systems have reasonable compile times. Some do not, I agree, but I'm not asking Go to leap to the forefront of type theory... I just think they could've done better.

Re: The Go Programming Language and Environment

#210

Post by morelisp » Wed, Jun 01, 2022, 6:52 AM UTC

timbit42 wrote: post #91

CraigJPerry wrote: post #57

Earlier quoted context omitted.

>> Made by really famous veteran language designers Yeah that’s a positive >> Backed by Google But that’s a negative, https://killedbygoogle.com/ I definitely think you’re too fast to dismiss the language features contributing to popularity. As an example: Fast builds are a positive developers immediately warm to when they experience them (stand by for rustacean “i need time to make tea and my compile times are exact…

>> Made by really famous veteran language designers > Yeah that’s a positive No, that's also a negative. C is close to assembly and produces fast code but it's weakly typed and very unsafe. Pascal was the strongly typed and safe option but people went for C because speed was considered more important than safety back when processors were slow. In today's online world, we've realized safety is more important than spee…

You've completely mixed up two different senses of "unsafe", the one where the language is prone to idioms that cause fatal errors (which is also true of all those slower interpreted languages), and the one where a mistake means the program can do literally anything (which is not true of Go).

"Unsafe" in most discussions today refers exclusively to the latter.