Live data from Hacker News

The Go Programming Language and Environment

cacm.acm.org

191–200 of 250 posts

Re: The Go Programming Language and Environment

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

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

Re: The Go Programming Language and Environment

#192
post #12

Earlier quoted context omitted.

Like Go, C# has also always been a decade behind on the tooling side. For a recent project I wanted very fast HTML templating and I/O. Went with C# instead of Go and it's looking pretty good so far. The tooling is close to the level Ruby was ten years ago, and that was really acceptable. I was very happy with my previous project that I did in Go as well, you just can't go wrong with Go for implementing network protoc…

Why people always mention tooling but never explicitly mention which tooling they miss? I use Java for 4 years and I constantly find stuff that's missing here where other languages have it baked in from day one

Not the other person, but I miss Gradle every time I use something else. It feels like the correct tradeoff of complexity and power. The Bazel family always felt unapproachable, and things in the Python or Rust universe basically require a makefile or other orchestrator to make sure tasks are ordered correctly.

What do you find missing from the Java tooling world? In my experience it’s been the best built out, and maybe overly so.

Re: The Go Programming Language and Environment

#193
post #130
post #79

Earlier quoted context omitted.

The most interesting thing about the go vs rust debate is that it happened. In hindsight it seems abundantly clear that they aim for entirely different fields with negligible overlap, almost as if you'd lump together tennis and golf because they are both ball games with a somewhat upperclass bias ("how different can they be? And I hear polo is the same but with horses!"). But back then? Yeah, I was kind of expecting…

Rust and Go are both general purpose languages. They overlap way more than they don't i.e. there is way more software that you can write in both languages than software that you can write in only one of them. The "best language for the job" is mostly a myth. The choice of language is mostly dictated by what you cannot do, rather than what you can do. Can I use Go or Java to program a micro-controller with 128 kB of R…

> Can I use Go or Java to program a micro-controller with 128 kB of RAM? Not really (at least no using the official, non-crippled implementation) because even "hello world" in those languages exceeds that 128 kB limit.

You'd be surprised actually. Java Card is actually designed for memory constrained environments. It's not as featured as Java itself but it uses the same language syntax and class file format.

Re: The Go Programming Language and Environment

#194

Earlier quoted context omitted.

To me, in the old Go vs Rust debate, there are two things that are abundantly clear in making a compelling case for Go. First, I don't think even the most devoted rustacean can deny that Rust has a hell of a learning curve. But perhaps most importantly is that Go has a strong and extensive standard library that covers many 21st century applications (e.g. talking to REST APIs). The problem to me with the Rust "no stdl…

The API case for Go is absurd IMO because what libraries are there in Go that are simultaneously not widely available in other languages and also difficult to implement on your own? People complain about Racket's ecosystem, but it has many libraries that would be PhD level effort to implement and are unique in its ecosystem such as Rosette and Redex. If some random REST API doesn't have bindings yet, implementing tho…

Both of those libraries look cool, but I'm guessing that most of the users of Go would not need them. I definitely agree that I'd rather have to write API glue code than a constraint based solver for a project that has time constraints though.

Re: The Go Programming Language and Environment

#195

Earlier quoted context omitted.

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

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

Re: The Go Programming Language and Environment

#196
post #116

Earlier quoted context omitted.

> newcomers are buffed about weirdly different take on things they consider "basic" or "common sense" Yep makes sense: "2006-01-02 15:04:05"

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 {
        Summer,
        Autumn,
        Winter,
        Spring
    }
Newcomer friendly indeed.

Re: The Go Programming Language and Environment

#197

Started a project in Golang this week. Looked into web frameworks and was underwhelmed. Settled with Echo as it seems to have the only decent documentation. Still no good templating library, will settle with html/template and try to add something else for template inheritance. (I chose Golang for the best async scheduler and the very fast compile times).

Coincidentally, I was also evaluating various go web frameworks, and also decided on Echo.

Re: The Go Programming Language and Environment

#198

It doesn't stand in people's way.

Coming from years of Scala development, it does stand in my way all the time. It's so verbose and it's capabilities for abstraction are very limited, it's hard to do anything complex quickly without tons of code generation. I realize having a language with a gentle learning curve that ends at a very low level has its benefits if you want to commoditize software development, and lots of people want just that, but for…

Scala has the opposite problem: too much complexity. I was on a Scala project in early 2011. I'm sure it's improved now.

Re: The Go Programming Language and Environment

#199
post #81
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…

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?

Re: The Go Programming Language and Environment

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

I think it has a very different timing than java. When java came out c++ was the standard and java was clearly easier (although slower). Go is not that much easier than java or c# and it is not much faster. I don't think the standard library is much better, or even better at all and when it was new it had a lot less 3rd party libraries. Go will probably continue to grow in usage a while but I'm not certain it will pa…

>and it is not much faster

You wish.

Post reply on HN