The Go Programming Language by Brian W. Kernighan, Alan Donovan • Hacker News Board

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#211

Post by codygman » Thu, Mar 05, 2015, 11:57 PM UTC

sctechie wrote: post #205

pcwalton wrote: post #185

Earlier quoted context omitted.

I don't think you can really learn C in a weekend. Not with all the ins and outs of undefined behavior. And if you don't know your way around the undefined behavior in C, you're going to make dangerous mistakes.

For various meanings of 'learn'. My point is that you can be writing useful programs in c in a weekend. Obviously said person would not be an expert, but I've watched competent programmers try to learn complex languages like Haskell and Scala; there is a far more complex mental model that one needs to build before they can use those languages specifically because of all the automagic that happens in the background.

> My point is that you can be writing useful programs in c in a weekend.

We'll need to define criteria for "useful program" but I believe most people could write useful programs in most languages in a weekend.

> I've watched competent programmers try to learn complex languages like Haskell and Scala

> far more complex mental model

I think its more that those languages are different, not that they require a more complex mental model.

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#212

Post by coldtea » Fri, Mar 06, 2015, 12:16 AM UTC

bdamm wrote: post #148

mavelikara wrote: post #138

Earlier quoted context omitted.

In an essay titled "Why Pascal is Not My Favorite Programming Language"[1] Brian W. Kernighan wrote: The size of an array is part of its type If one declares var arr10 : array [1..10] of integer; arr20 : array [1..20] of integer; then arr10 and arr20 are arrays of 10 and 20 integers respectively. Suppose we want to write a procedure 'sort' to sort an integer array. Because arr10 and arr20 have different types, it is…

The language has decent interfaces for things like sorting. Why is it a problem? Declare a method for your type and you're off to the races.

The same could save for assembly over any other language.

Write your own macro-assembler constructs and you're off to the races!

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#213

Post by coldtea » Fri, Mar 06, 2015, 12:20 AM UTC

sesteel wrote: post #99

theseoafs wrote: post #82

Earlier quoted context omitted.

I can't even believe this is the kind of comment that gets upvoted on HN nowadays. "Go was made by smart old people and is therefore good. If you don't understand it's good, you're stupid and I refuse to listen to you."

For the record, ignorant does not equal stupid, being a master does not mean you are old, and ignoring negativity (which I should have done here) does not mean I refuse to listen to you. I was simply trying to convey that the rocket has left the launch pad and people will be exposed to the language professionally whether they like it or not. I am finally free of feeling like I need to defend the language to others. I…

>For the record, ignorant does not equal stupid, being a master does not mean you are old, and ignoring negativity (which I should have done here) does not mean I refuse to listen to you.

Ignorant might not mean stupid literally, but it still means "you don't know about programming languages" in the context of the comment, which is also bad.

Being a master might not mean you are old, but the masters we're talking about here (Brian et al) are ALSO old.

And saying that you're "ignoring negativity" if you ignore complaints about Go means that you're labelling them as whining or coming from "negative types" instead of accepting the possibility that it can be actual valid criticism.

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#214

Post by slowmovintarget » Fri, Mar 06, 2015, 12:30 AM UTC

higherpurpose wrote: post #29

eric_bullington wrote: post #9

I've not been a huge fan of Go (more of a Rust person). However, seeing these authors, I'm now itching to get my hands on a copy of this book and give Go another shot. I wish I didn't have to wait until the summer for it! Edit: Also, I realize it's unfair to compare Rust to Go, since they really fill two different PL niches. I actually think there is plenty of room for both languages. By my statement above, I just me…

Hopefully they'll do one for Rust, too, next.

That's doubtful, as the likely reason that they've written this one is that they're the same group of people that created the C language, now having moved on to Go.

Ken Thompson, one of the creators of Go, worked with Dennis Ritchie (the "R" of "K&R") at Bell Labs, and created B, the precursor to C. Rob Pike, one of the other creators of Go, worked with Brian Kernighan (the "K") on two programming books. These guys are from the same crowd, in other words.

Rust comes from the gang at Mozilla. Different generation, slightly different lineage of thought.

  C --> Unix --> Go
  Netscape --> Firefox --> Rust

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#215

Post by wallyhs » Fri, Mar 06, 2015, 12:51 AM UTC

aikah wrote: post #195

I have mixed feelings about Go. For those who didn't try it yet here are the biggest advantages of Go: - it's totally easy to learn and can be mastered in a day - it's fast and typesafe - the concurrency model is great,no question - I personally like the error system, no exceptions but you can still "bubble up" errors with multiple return types - it has, in my opinion a comprehensive standard library,you can even do…

Don't forget about the tooling: unit testing, benchmarking, generated documentation, code formatting, and emacs+vim plugins are included in the official package. I think these are often overlooked when describing its benefits. You can jump in and start working right away.

In discussions about error handling in Go, I rarely see mention of panic used for private exception handling. If a module exposes a small surface area, the public entry points can recover from panics and return them as errors. Private functions can then use panic to report errors:

  func PublicEntryPoint(input string) (output []byte, err error) {
    defer func() {
      if e := recover(); e != nil {
        output = nil
        err = e
      }
    }()
    err = nil
    output = privateFunc(input) // no need to check for error here
    return
  }
  func privateFunc(input string) []byte {
    foo := otherPrivateFunc(...) // no need to check for error here
    // ...
  }
  func otherPrivateFunc() int {
    // ...
    panic(fmt.Errorf("Something is wrong"))
  }

I would panic-recover a specific type of error instead of the generic "error" type, but I'm simplifying for the example. Also, it is not recommended to panic across module boundaries.

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#216

Post by sesteel » Fri, Mar 06, 2015, 12:57 AM UTC

coldtea wrote: post #213

sesteel wrote: post #99

Earlier quoted context omitted.

For the record, ignorant does not equal stupid, being a master does not mean you are old, and ignoring negativity (which I should have done here) does not mean I refuse to listen to you. I was simply trying to convey that the rocket has left the launch pad and people will be exposed to the language professionally whether they like it or not. I am finally free of feeling like I need to defend the language to others. I…

> For the record, ignorant does not equal stupid, being a master does not mean you are old, and ignoring negativity (which I should have done here) does not mean I refuse to listen to you. Ignorant might not mean stupid literally, but it still means "you don't know about programming languages" in the context of the comment, which is also bad. Being a master might not mean you are old, but the masters we're talking ab…

Thank you for trying to educate me on what I meant by my own comment. Contrary to what you might think, ignorant, in the context of my comment does not mean "you don't know about programming languages" and I know this because it was my comment. I was simply referring to people not having the same professional experiences such that they would appreciate a language like Go.

The crux of the issue is that Go is a local min in a field of possibilities, you may value differently the attributes of various programming langauges which would lead you to some other alternative or local min. I am not passing judgement on others for doing so, but also please be brave enough to admit your ignorance as to why some of us settled where we did with Go. I willingly admit I am ignorant as to why people think other languages are a good idea for general use.

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#217

Post by unoti » Fri, Mar 06, 2015, 1:09 AM UTC

BuckRogers wrote: post #209

aikah wrote: post #195

I have mixed feelings about Go. For those who didn't try it yet here are the biggest advantages of Go: - it's totally easy to learn and can be mastered in a day - it's fast and typesafe - the concurrency model is great,no question - I personally like the error system, no exceptions but you can still "bubble up" errors with multiple return types - it has, in my opinion a comprehensive standard library,you can even do…

I'm in a similar boat. I've tried Go, and partially agree with your sentiment that the ease of use justifies usage of it in any team. Even with its flaws, it's a tempting feature. But I'm not sure if bringing -anything- into an existing stack should be done lightly though since someone has to maintain whatever is brought in. Even if the ramp up time is shorter than usual. For backend/webservices, I initially tended t…

> For backend/webservices, I initially tended to agree Go is a killer tool. But if you are a Python shop, why would I bring this into my stack instead of using PyPy (or soon, Pyston) for CPU-intensive tasks?

Two big things here, for my applications.

1. Memory. You mention CPU use, but memory use is even more critical for what I do. For game servers, for example, lower memory usage for an application can change the multipliers on how many users I can handle per server. This can make a dramatic (like 20x) difference in what you can offer users for free vs charging.

2. Static compilation. This makes a massive difference over Python in terms of catching and correcting problems at compile time vs run time.

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#218

Post by CatDevURandom » Fri, Mar 06, 2015, 1:15 AM UTC

rubiquity wrote: post #206

CatDevURandom wrote: post #201

Earlier quoted context omitted.

> which means a lot of copy and paste Again, I don't think Go is perfect but on my list of wants, generics are not in the top 5. Can you qualify "a lot" in a real project you've worked on? Because after writing a good chunk (over 50k lines) of Go code, I haven't felt the sting as much as I hear it complained about. > the lack of idiomatic way to deal with dependencies(no defacto package manager Again, is this really…

> Again, I don't think Go is perfect but on my list of wants, generics are not in the top 5. Would you mind sharing your top 5 wants? I'm interested.

Sure! In order:

A Debugger.

Better IDE options.

Binary sizes small enough to use for embedded programming.

Pauseless Garbage Collector.

Less awkward variable declaration.

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#219

Post by ascotan » Fri, Mar 06, 2015, 1:19 AM UTC

aikah wrote: post #195

I have mixed feelings about Go. For those who didn't try it yet here are the biggest advantages of Go: - it's totally easy to learn and can be mastered in a day - it's fast and typesafe - the concurrency model is great,no question - I personally like the error system, no exceptions but you can still "bubble up" errors with multiple return types - it has, in my opinion a comprehensive standard library,you can even do…

I sort of agree with the go authors that there is not idiomatic way to deal with dependency management at all. (see: https://golang.org/doc/faq#get_version) They all have their ups/downs and mostly it has to do with the language they are supporting.

Nodejs:

+ transparent code on download

- virtually impossible to mirror

- executes arbitrary 'script' blocks that install stuff on your system

- subpar transitive dependency management scheme

Java:

+ great transitive dependency management

+ private repos/mirrors are easy with well supported tools

- black box byte code with no licenses

- overly complicated software (ivy/maven)

Python (pip):

+ simple and easy

- virtual environment hell

There are things that i like and don't like with go get:

+ dirt simple and used from the command line

+ code comes into src/. This means that you can see the code and the licenses that you are pulling in. This makes it easy to inspect code in your project. I don't have a hidden code repo in my home directory or some crap.

+ I can clearly see the licenses that i'm pulling in. If you have a GPL in your project it's pretty trivial to audit this (unlike other tools were you have to track down the homepages of 20 random people).

- code is pulled from HEAD. Frankly this sucks. Hopefully people get their act together and release their software and got get will be able to pull a release. I can see the advantage of pulling from head if you're constantly iterating and monitoring for fixes. However, pulling from HEAD introduces the risk that there is a major untested defect in what you just pulled.

Overall as long as there is not a huge chain of dependencies in the code that you're pulling, and as long as you're relatively confident that HEAD isn't going to bust you release, it's a great system. Honestly I think that it makes the developer more wary about pulling in random half-baked code from the internet into their project. Maybe that's a healthy thing.

Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan

#220

Post by shanemhansen » Fri, Mar 06, 2015, 1:20 AM UTC

semi-extrinsic wrote: post #200

aikah wrote: post #195

I have mixed feelings about Go. For those who didn't try it yet here are the biggest advantages of Go: - it's totally easy to learn and can be mastered in a day - it's fast and typesafe - the concurrency model is great,no question - I personally like the error system, no exceptions but you can still "bubble up" errors with multiple return types - it has, in my opinion a comprehensive standard library,you can even do…

The lack of a package manager is a good thing, since this is the job of the operating system. That Windows and OSX have crappy/nonexisting package managers does not mean every language should roll its own. If the police in your city are not doing their job, you shouldn't resort to vigilantism, you should stage a protest. Ideally.

Package management is the job of the operating system, but this statement doesn't make much sense for go because go binaries are statically linked to go packages. So using an OS-provided version of crypto/tls or net/http isn't really an option.

Go dependencies are basically a build-time thing.

(cgo is an exception)