Live data from Hacker News

The Go Programming Language and Environment

cacm.acm.org

221–230 of 250 posts

Re: The Go Programming Language and Environment

#221

Earlier quoted context omitted.

Because it's selling point is Flutter? Where you're forced to use Dart?

Dart had quite a long history before Flutter even came into the picture. Flutter is the answer to the question of why is Dart somewhat relevant today, but not to the question of why Dart didn't take off in general during its first 5 or so years, despite the fanfare of coming from Google.

Microsoft, Apple and Mozzilla did't felt like integrating DartVM on their browsers, that is why.

Re: The Go Programming Language and Environment

#222
post #204

Earlier quoted context omitted.

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.

Which is neither here nor there.

It'a runtime that's run from the statically combined binary.

Re: The Go Programming Language and Environment

#223
post #191

Earlier quoted context omitted.

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…

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

Re: The Go Programming Language and Environment

#224
post #195

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…

> 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 … Keep in mind that many of those things are written in a subset of the C programming language, such as MISRA C.

Absolutely, just as there are many ways to achieve C speed in languages like Java for particular sections of code by applying non-idiomatic optimisations, there are also many ways to improve safety beyond just types. Even things like the borrow checker has decent alternatives (tsan, msan etc.) that can be used in existing language stacks.

MISRA as you point out is another useful tool in the toolbox.

Re: The Go Programming Language and Environment

#225
post #159

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…

> Android is C/C++

It really isn't, and frankly this sort of comment makes it quite clear how uninformed you need to be to make this sort of claim. I mean, even the Android NDK specifies quite clearly in its own description that it's only designed to offload parts of an Android app to C++.

https://developer.android.com/ndk

In the Android projects I worked, the Android NDK was only used to implement small performant components that sat on the hot path, such as image processing work. Even so, the experience was not exactly on the happy path.

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

This personal assertion has no bearing in the real world. Not only do we have high frequency trading apps developed in Java but you're also succumbing to absurd beliefs that you get architectural wins for free by switching the programming language.

Also, it's absurd to make clams about the needs of running "lots of small services" when the web is already served by "lots of small services" developed in Java with non-performant web app frameworks, which are subsequently ran by the likes of Kubernetes.

Re: The Go Programming Language and Environment

#226
post #204

Earlier quoted context omitted.

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

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.

Re: The Go Programming Language and Environment

#227

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…

This has bitten me many times. In particular: Slice index expressions accept any integer type. Integer subtypes can be defined, but there is no way to define a slice type that is legally indexed with only that defined type. An expression a.b in some unfamiliar code may denote either a struct field access, or a pointer dereference followed by struct field access. We must read surrounding code (or lean on an IDE) to kn…

About that slice indexing problem I wrote a bug-report for the language specification like two years ago. The language specification itself is not clear about what types can be used as indices. Accepting int32 and similiar could be regarded as a feature of the compiler.

The problem was recognized (like a year later), but then claimed to be fixed and simply ignored. Immediately, I wrote a follow-up issue providing a concrete example how the spec could be improved. No response to that, yet. Now another year has passed.

Re: The Go Programming Language and Environment

#228

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…

This has bitten me many times. In particular: Slice index expressions accept any integer type. Integer subtypes can be defined, but there is no way to define a slice type that is legally indexed with only that defined type. An expression a.b in some unfamiliar code may denote either a struct field access, or a pointer dereference followed by struct field access. We must read surrounding code (or lean on an IDE) to kn…

> Slice index expressions accept any integer type. Integer subtypes can be defined, but there is no way to define a slice type that is legally indexed with only that defined type.

What actually-used language did this in the 70s? What other major languages offer this today? I know it's useful, but dunking on Go for features only C++ (and Rust?) have is offensively far from GP's claim.

Re: The Go Programming Language and Environment

#229
post #227

Earlier quoted context omitted.

This has bitten me many times. In particular: Slice index expressions accept any integer type. Integer subtypes can be defined, but there is no way to define a slice type that is legally indexed with only that defined type. An expression a.b in some unfamiliar code may denote either a struct field access, or a pointer dereference followed by struct field access. We must read surrounding code (or lean on an IDE) to kn…

About that slice indexing problem I wrote a bug-report for the language specification like two years ago. The language specification itself is not clear about what types can be used as indices. Accepting int32 and similiar could be regarded as a feature of the compiler. The problem was recognized (like a year later), but then claimed to be fixed and simply ignored. Immediately, I wrote a follow-up issue providing a c…

What's wrong with "the index x must be an untyped constant or its core type must be an integer"? ("Integer" in turn being defined by enumeration in the "Numeric types" section.)

Re: The Go Programming Language and Environment

#230
post #212

Earlier quoted context omitted.

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

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

Considering your robust defence of Go, maybe you can demonstrate the simplicity of Go's string enums?

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

There is no magic - .toString() produces an equivalent string. The point is to keep simple things simple - most of the time, the enum value and its string representation is same and the snippet in my previous post automatically gets us there.

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

Thanks for acknowledging that it is atleast easy in Java for single words. Words with spaces or unicode (I think thats what you meant when you said non-Unicode) isn't terrible either:

    enum Season {
        SUMMER("S U M M E R "), AUTUMN("A U T M N "), WINTER("W I N T E R "), SPRING(
                "S P R I N G ");

        private String value;

        private Season(String value) {
            this.value = value;
        }

        public String toString() {
            return this.value;
        }
    }
I had to introduce a variable and couple of one-line methods which isn't super simple but still a win over a switch statement that requires listing out every representation. For shits and giggles, this is how I can enumerate over the enum values in Java:

    for (Season s : Season.values()) {
        System.out.println(s);
    }
Feel free to show how you would do it in Golang with iota magic...

PS: seems like the unicode strings that I pasted didn't carry over to HNs code snippet. The same is available on pastebin: https://pastebin.com/Yw0jyGDE

Post reply on HN