Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Go Programming Language and Environment

cacm.acm.org

Post reply on HN
Print view View original

241–250 of 250 posts

Re: The Go Programming Language and Environment

#241

Post by eweise »

coldtea wrote: post #223
eweise wrote: post #191

Earlier quoted context omitted.

"I fail to see how this information about "most places you work for" is relevant." I can spell it out. Where is I work is a web based business and those businesses are typically using hosted environments. Go binaries aren't an advantage in these environments.

One can, and many do, just deploy a single Go binary into those "hosted environments". There have been a couple of posts on HN of teams doing that. In fact one can even do it your way, and use kubernetes and co in those hosted environments and Go binaries would still be an advantage -- because the container for the go-based service can just have a static binary inside, and be relatively easier to manage than a Java o…

Java deploys as a single file so would be the same as a Go binary. Container just needs the JVM included, which is trivial.

Re: The Go Programming Language and Environment

#242

Post by coldtea »

pjmlp wrote: post #226
coldtea wrote: post #222

Earlier quoted context omitted.

Which is neither here nor there. It'a runtime that's run from the statically combined binary.

Great, Java is doing the same since the first commercial JDKs started supporting AOT compilation around 2000. Or if you prefer free beer recipes, gcj which got dropped when most developers eventually moved into hacking into OpenJDK around 2009.

>Great, Java is doing the same since the first commercial JDKs started supporting AOT compilation around 2000.

Yes, with hardly any support, several issues, and one which only a handful of people actually ever used...

Re: The Go Programming Language and Environment

#243

Post by coldtea »

pjmlp wrote: post #235
morelisp wrote: post #231

Earlier quoted context omitted.

What other people actually use matters a lot though. Hell, a greater proportion of Java devs ca. 2002 probably knew how to AOT-compile their programs than do today. Using minority tooling in a popular language is often just as painful as using a minority language.

That is orthogonal to what language implementations can do, failure to education doesn't change what tools are available.

It's actually the opposite:

The availability of a half-arsed, hardly supported, restricted compared to regular JVM based runs feature, dumped at some point by SUN so that they could say they also have it, doesn't mean people should use it, or that a platform is as good in that aspect as another who has that feature as a fully supported, first class, default mode.

Don't be excited by mere presence of a feature. Implementation, maturity (which is different than "age of introduction"), completeness, support, and usage, matter...

Re: The Go Programming Language and Environment

#244

Post by Andys »

AnimalMuppet wrote: post #187
ivoras wrote: 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.

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

Re: The Go Programming Language and Environment

#245

Post by xedrac »

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

Re: The Go Programming Language and Environment

#246

Post by pjmlp »

morelisp wrote: post #239
pjmlp wrote: post #235

Earlier quoted context omitted.

That is orthogonal to what language implementations can do, failure to education doesn't change what tools are available.

Only in a vapid purely existential sense of "available".

It is available, if people don't want to pay for them, and prefer free beer stuff, it is another matter.

Re: The Go Programming Language and Environment

#247

Post by pjmlp »

coldtea wrote: post #243
pjmlp wrote: post #235

Earlier quoted context omitted.

That is orthogonal to what language implementations can do, failure to education doesn't change what tools are available.

It's actually the opposite: The availability of a half-arsed, hardly supported, restricted compared to regular JVM based runs feature, dumped at some point by SUN so that they could say they also have it, doesn't mean people should use it, or that a platform is as good in that aspect as another who has that feature as a fully supported, first class, default mode. Don't be excited by mere presence of a feature. Implem…

Ah the proof of not have the slightest idea of what you are talking about, given that those commercial AOT features were never sold by Sun in first place, with exception of Embedded Java deployments.

If we go down the implementation, maturity route, than even there are several half-arsed, hardly supported capabilities in Go compared with the JVM ecosystem, even after 10 years of existence.

Re: The Go Programming Language and Environment

#248

Post by pjmlp »

leetrout wrote: post #199
pjmlp wrote: post #81

Earlier quoted context omitted.

C++ was born at AT&T, shared the UNIX throne with C, adoption grew from there. Java was created by Sun, was remarkable in having the JDK available as free beer in the age of comercial compilers, Sun bankrupt themselves pushing Java everywhere. PHP provide a saner way to use a Perl like language on ISPs, whithout the mess of mod_perl, while most ISPs would charge extra for something else. Smalltalk was gaining adoptio…

My email is in my profile. You wanna record a podcast or something? Your breadth of knowledge on the history of a lot of this stuff is really great. Have you written things down anywhere other than HN comments?

Thanks for the invitation, it would be a quite boring podcast, I am not that interesting really.

Sure, I was posting on Usenet, Slashdot, Reddit,...online since 1994.

Re: The Go Programming Language and Environment

#249

Post by coldtea »

pjmlp wrote: post #247
coldtea wrote: post #243

Earlier quoted context omitted.

It's actually the opposite: The availability of a half-arsed, hardly supported, restricted compared to regular JVM based runs feature, dumped at some point by SUN so that they could say they also have it, doesn't mean people should use it, or that a platform is as good in that aspect as another who has that feature as a fully supported, first class, default mode. Don't be excited by mere presence of a feature. Implem…

Ah the proof of not have the slightest idea of what you are talking about, given that those commercial AOT features were never sold by Sun in first place, with exception of Embedded Java deployments. If we go down the implementation, maturity route, than even there are several half-arsed, hardly supported capabilities in Go compared with the JVM ecosystem, even after 10 years of existence.

>Ah the proof of not have the slightest idea of what you are talking about, given that those commercial AOT features were never sold by Sun in first place, with exception of Embedded Java deployments.

Didn't wrote sold, said "dumped at some point by SUN so that they could say they also have it".

But thanks for the ad hominem.

>If we go down the implementation, maturity route, than even there are several half-arsed, hardly supported capabilities in Go compared with the JVM ecosystem, even after 10 years of existence.

Sure. Just not related to the ability of building a static binary.

Re: The Go Programming Language and Environment

#250

Post by DonaldPShimoda »

morelisp wrote: post #211
DonaldPShimoda wrote: post #209

Earlier quoted context omitted.

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

> Would I rather guarantee my program is more correct or save a few seconds each time I compile? Iterating faster is also a way to improve the odds your program is correct.

There is no inherent link between "number of successful compilations" and "program correctness". There is an inherent link between "the program type-checks" and "program correctness", because a successful type-check specifically means that a certain subset of syntactically valid programs have been thrown out due to being potentially problematic.
Post reply on HN