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

211–220 of 250 posts

Re: The Go Programming Language and Environment

#211

Post by morelisp »

DonaldPShimoda wrote: post #209
lenkite wrote: post #207

Earlier quoted context omitted.

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

Re: The Go Programming Language and Environment

#212

Post by divan »

noisy_boy wrote: post #196
divan wrote: post #116

Earlier quoted context omitted.

Oh yes, great example. It's literally "1st month, 2nd day, 3rd hour, 4th minute, 5th second, 6th year, 7th timezone" Clever mnemonic tecnhique which is much easier to use and memorize. Most people can remember "January 2nd 2006" and "15:04:05" easily, and then crafting date/time format strings becomes a toy. While with more widespread and common "HH/MM/SS" approach, which has bunch of incompatible implementations in…

Or that they are used to simple things being kept simple in other languages. Case in point - String enums in Go: const ( Summer Season = iota Autumn Winter Spring ) func (s Season) String() string { switch s { case Summer: return "Summer" case Autumn: return "Autumn" case Winter: return "Winter" case Spring: return "Spring" } return "Unknown" } Same in Java (invalid values would raise an exception): enum Season { Sum…

Obviously Go code shown here doesn't show string enums. It's an integer enum with function that converts integer value to the string representation (by implementing Stringer interface). Which makes total sense (not every int enum needs String conversion).

I assume your Java example has some magic (aka conventions) in how to convert values into string. Without reading Java manuals, how do I know what's the magic's conversion function? With single words it's usually easy, but try two words "LeapYear" or text with non-Unicode chars - how the magic will work then? Go tries to minimize amount of hidden magic. Also, should not Java enums be capitalized?

I mean, sure, Go enums can be improved, and there are few proposals (none of them yet passed, and that's usually for a reason), but this comparison is just incorrect.

Re: The Go Programming Language and Environment

#213

Post by tsimionescu »

pjmlp wrote: post #205
tsimionescu wrote: post #173

Earlier quoted context omitted.

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.

That's only true if your project and all your dependencies are modularized, right? I moved on to Go around the time Java 9 had recently come out, so no idea how well the ecosystem has evolved in this direction in the meantime.

For the record, I miss many aspects of Java, especially the language and tooling, but Go was definitely the right choice for our project at the time.

From what I've seen major Java projects are still delivered in large containers with a full JVM (ElasticSearch, Keycloak at least).

Re: The Go Programming Language and Environment

#214

Post by pjmlp »

tsimionescu wrote: post #213
pjmlp wrote: post #205

Earlier quoted context omitted.

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

That's only true if your project and all your dependencies are modularized, right? I moved on to Go around the time Java 9 had recently come out, so no idea how well the ecosystem has evolved in this direction in the meantime. For the record, I miss many aspects of Java, especially the language and tooling, but Go was definitely the right choice for our project at the time. From what I've seen major Java projects are…

Not with the uberjar approach.

Many projects choose the easy way out when packing their deliveries, and to certain extent Java is having a Python 3 moment with anything past Java 8.

The cynic in me sees that as the main reason why Docker was adopted, HP-UX was already having containers in 1999 and no one was rushing to package Perl into them.

Re: The Go Programming Language and Environment

#215

Post by pjmlp »

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…

The wrong corner of the 70's, given that CLU and ML were born in the 70's.

Re: The Go Programming Language and Environment

#216

Post by pjmlp »

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.

Not really, have a go at it with Delphi, Nim or D, for example.

Re: The Go Programming Language and Environment

#217

Post by pjmlp »

nine_k wrote: post #103
jasode wrote: 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…

Oberon is sort of widely used, at least conceptually. Large parts of it are co-opted into Golang.

I wouldn't call the method syntax declaration taken from Oberon-2, and unsafe instead of SYSTEM as large parts.

They still don't have a means to load packages dynamically as easy as Oberon allows for.

Re: The Go Programming Language and Environment

#218

Post by pjmlp »

timbit42 wrote: post #150
anthk wrote: post #119

Earlier quoted context omitted.

Pascal in DOS was as fast as C if no more.

Turbo Pascal wasn't entirely compliant to the Pascal spec either.

Production class Pascal compilers weren't, thus the Kernigham meme about Pascal misses the point that outside UNIX and a few other systems, the Pascal dialect people were using was as capable.

Likewise outside UNIX, the C compilers that were starting to appear were just as fragemented, supporting only subsets of K&R C.

Re: The Go Programming Language and Environment

#219

Post by pjmlp »

anthk wrote: post #124
mountainriver wrote: post #102

Earlier quoted context omitted.

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.

Go is the legacy of Limbo (Inferno), not Plan 9.

Re: The Go Programming Language and Environment

#220

Post by pjmlp »

Thaxll wrote: post #159
arinlen wrote: post #152

Earlier quoted context omitted.

> Well it's pretty clear 10 years ago than Java would have been a disaster, imagine all the controle planes + pods + side cars etc ... running on the JVM, you would have needed 20x more memory. I'm not sure if you are aware, but the web runs on Java. Android is also Java, thus even the people in charge of developing one of the most popular resource-constrained devices in history disagree with you. Beyond desktop (spe…

Android is C/C++, or maybe you mean the app that you deploy on Android are built in Java right? I stand my point, the JVM is not the right tool to build components for Kubernetes because Kubernetes needs lots of small service running everywhere, running those in the JVM would have resulted in large memory consumption. You can try yourself, build a very simple hellow world web app with the most popular JVM ( Oracle on…

Try to develop Android apps with the NDK alone and see how far you get, unless you're doing a game without networking.

Outside the Linux kernel, Treble drivers (which also suports Java alongside C++), ART infrastructure, most of the Android code is written in Java.

Post reply on HN