There's a free chapter available from the book's website http://gopl.io which should give you an idea of what the rest of the book is like. The intro goes into a little bit too much detail but if you gloss over that the remaining chapters are pretty else detailed. There are some nuggets distributed through the book but you could easily gloss over them if you were skim reading it, such as learning that exported identifiers begin with an upper case letter and those that are private are lower case.
Yes, exactly - I would have expected this to be called out much more prominently than in the middle of page 28, especially when it defines 'exported' and then fails to have an index entry back to it.
Like others have mentioned, RAII-style stuff doesn't work so well with a GC language.
Go does provide a "defer" statement, which cause a function call to execute when the current function returns. This makes it easy to visually co-locate resource acquisition and release, as well as ensuring the release code runs regardless of how the function is exited.
It looks like this:
f := os.Open("someFile")
defer f.Close() // will run when current function exits
I'm not sure exactly where you see that so I'm not entirely sure of the context (I tried looking in the first chapter), but a general problem with garbage-collected languages is that while the runtime will eventually get around to cleaning up unused resources, you don't always have guarantees about when. So you still generally need to close files when you're done with them, or you may run out of filehandles. I've encountered this issue in multiple languages, it's not Go-specific.
Its on page 16 when they are showing how to download multiple urls concurrently - which is cool. In Firefox Ctrl-F "leak" works for me.
http://www.gopl.io/ch1.pdf
The only thing modern about Go is that it's just a few years old, but it's based on programming language concepts that were mainstream in the late 90s.
I should have figured out context based on the name Kernighan, but the word Go (especially as it relates to google) is awfully overloaded for the time being.
The language is officially called Go and often referenced as Golang.
Go should be rebranded Golang (while keeping the go command) in my opinion: the language is still fairly young and has been developed to be the C for the 21st century but "Go" is nearly as bad regarding SEO as "C".
There is still time to change the name before Go becomes the programming language taught to people who start programming (and are googling a lot to learn more about it). I would also love to see this transformation so that I can finally know if the new trendiest article on HN is about AI or Golang!
If some sort of official forum / web based community was built around Go it would be easier too (more organized than just Google Groups). I know some communities online that I append the name of at the end of some of my searches just to hunt down relevant data. Heck I do it with HN sometimes to find commentary on things I'm looking for, or just really old HN links. At least then new CS students could be linked to said community. There's also the IRC, but it's not always as approachable as typing in "www.goforums.net" into a browser.
Not explicitly, but since it's syntax is derived from a Wirth language (Oberon), and Niklaus Wirth had always had a focus on teaching in his languages, it's kinda implied in my opinion.
I (and a lot of other French students) have started programming during my bachelor's mainly in Java and C. I now develop in Golang and I know it would have been better for me to start with it:
- The logic of Golang is straightforward, e.g. you need to import the package fmt to do a fmt.Println("") in Golang but you do not need to explicitly import anything to do a System.out.println("") in Java. Some things could still be weird for a beginner, e.g. methods like len(), but the official documentation gives a clear explanation about a lot of things.
- gofmt, the best way for a beginner to understand what is pretty code. Golang forces you to write clear code (e.g. no unused variable) and that is an excellent way to learn as a beginner.
- The goroutines / gochannels are simple to understand, I wish I would have started concurrent programming by developing in Golang instead of C.
- Golang works on every computers and installing it is simple (simpler than installing Java and Eclipse).
This list is subjective, other languages like Python are also excellent for new developers from what I heard but Golang could also do the job.
> - The logic of Golang is straightforward, e.g. you need to import the package fmt to do a fmt.Println("") in Golang but you do not need to explicitly import anything to do a System.out.println("") in Java.
You don't need to import println in Go[0]. The logic is exactly the same[1]: there's a pre-imported "prelude" (java.lang in Java, builtin in Go) and you import the rest.
> - Golang works on every computers and installing it is simple (simpler than installing Java and Eclipse).
Why do you have to install go alone but java and eclipse?
What's interesting is that Go (and its predecessors, Limbo and Newsqueak) is strongly influenced by Niklaus Wirth's languages, especially Oberon, both syntactically and in its design and simplicity. Before C++ and Java, Pascal and its cousin, Modula/Modula-2, were widely used as teaching languages. So it wouldn't be too surprising if Go becomes popular as a teaching language. Wirth's languages are all eminently suitable for this purpose.
(Pascal was originally designed to be a language for teaching, and also became widely used to write pseudocode for algorithms, which you'll find in a lot of technical CS papers; the pseudocode tends to be a close approximation of Pascal.)
I would be surprised. Java is the standard language in most universities and colleges, because it's what the industry (outside our little bubble) asks[1]. If anything, universities tend to favor Python as the alternative to Java, because of its rich ecosystem of scientific libraries (numpy, SciPy, Theano, etc.), easier explorative programming (through the REPL and IPython), etc.
[1] There is/was some educational value in using Java as a teaching language, but there are far better choices now.
I have read the book this article is referring to. Contrary to the raving reviews on Amazon, I wasn't that impressed by it. I imagine that it is a great book for those coming from dynamically typed languages, but if you already know C, for example, the book is probably way too verbose for you.
I tried to power through it last month but couldn't do it despite my best intentions.
Book is a major snoozefest and nothing like its famous cousin 'The C programming language' . I credit the C programming language as one of the books that made my choose writing code as a career. This book on contrary can make no such claims.
I would have quite the contrary verdict: if you are an experienced programmer and want to read a book about Go, this is the book to get. If you are a programmer, any book which tries to cover a language thoroughly will have slow parts, because they might not be entirely new to you. Yet they need to be told to be thorough. But this book is way faster paced than many books about a programming languages and it is full of short programs, which pack a lot of functionality in a few lines of code - often a small eye-opener.
But if you're an experienced programmer, why get a book at all? Effective Go and the Go language specification (which unlike most specifications is very readable) tell you what you need to get started.
Oh, I got myself started with online resources and was using Go for some months when I got the book - I mostly got it because of the author, to match my "The C programming language". And because I was reasonably fluent with Go, certainly some parts were redundant for my knowledge, but I was very pleasantly surprised how much I still learned from this book and that is why I recommend it. Sometimes it was a little detail in the sample programs which made me say: oh, I had not thought of that.
"When we were choosing among typesetting systems, Brian never let on that he was one of the original authors of Troff, the system we ultimately went with," Donovan said. "I realized this only after researching many early papers on digital typesetting; Brian co-wrote all of them."
It's funny how times change. My first thought was "that's a conflict of interest and it would've been polite to mention it." He apparently doesn't believe that his collaborators might have their own ways of dealing with conflicts. But then: I think it's a generational thing. He is from a world where people have simple allegiances and hidden conflicts are rare. In the Internet age relationships are so fragmented conflicts of interest are part of the day to day collaboration process.
golang is a nice language but I just can't find a reason to use it over other languages for anything other than networking/server projects.
How many HN readers are using golang for things you would normally use Java or C++ or Python or ... for? What is it you are working on? And how have you found using golang?
Originally it was positioned as a 'systems' programming language (i.e. the C/C++/Rust/D domain) - the community quickly re-oriented itself to more of a Python replacement for the obvious benefits it offered.
Network/server projects is exactly what I see it being handy at. You get a fast compile-time language that can do things with your logs/analytic aggregate information in an ad-hoc fashion (really fast compile times and better-than-dynamic-languages-performance), which previously would have costed a lot of time in learning the whole Pig/Hadoop/etc ecosystem or a lot of money in any of the BusinessObjects-esque tooling.
Gofmt eliminated styling wars, go doc integration is handy, great 'batteries included' tools out of the box for, typing safety that's comfortable for people who are used to dynamically typed languages to move over without too much hassle[1]. Out of the box code-coverage tooling, good DVCS support, import support for Github is clever (though arguably not the best idea re: security, handy nonetheless since you avoid having YetAnotherPackageManagerWar (pip vs setuptools in Python). The lack of generics (interface{} is such a hack, just like void * in C) is problematic for some, unfortunately.
I don't use Go much because I'm a self-admitted typed language elitist but it is definitely a well-designed language[2].
[1] I don't think the average Pythoner really wants to think about co/contravariance unlike in Scala, or Haskell98's type system + the bevy of lang extensions that fall in and out of fashion.
[2] Though there's tons of room for improvement-- my hope is that Go moves at the Meijers-C# pace which seems to be a perfect trade-off between adding features not too slowly (i.e. the first 15 years of Java/JVM -- only recently has this changed) but not too quickly either (stability is certainly important, no one wants to see their old code break because a new keyword was added which you previously used as a variable; or far worse, subtle semantic changes in pre-existing constructs).
Though there's tons of room for improvement-- my hope is that Go moves at the Meijers-C# pace which seems to be a perfect trade-off between adding features not too slowly
I wouldn't bet on it, Go's designers consider the language more or less done:
Go was created to do what Google does - server side software run in huge data centers. C++ was too bug-prone, and Python was too slow. Go has the right feature set for that job. Google then provided good libraries for most of the things you'd want to do on a server. It lets mid-level programmers do competent work without much trouble.
It's not a great choice for operating system development, real time work, client side code, graphics, games, supercomputing, or "frameworks". That's OK. For the job it was designed to do, the features are there.
The main problem with Go is that it was originally pushed by its developers as the perfect language for these applications, and it's still actively pushed as a systems language in some circles.
The Go language FAQ still states that no "No major systems language has emerged in over a decade". Besides ignoring the system languages which did emerge, this sentence misleads the reader into thinking that Go is a systems language.
And I'm not talking about garbage collection here, which is often cited as why Go can't be a systems language. GC makes it hard to write some of the applications of a systems programming language, such as OS kernels and games, but it's not mutually exclusive, and OSes have been written in GC languages before (Lisp Machines, Singularity with Sing#). It's the entire approach: Go offers its own scheduler (which is really great, but if you need to use something else, you're in for some pain) and no support of writing dynamically linked modules. It makes go very inconvenient for most common system applications, unfortunately. Essentially, it's manages to be less high level than C++ (it has fewer robust typing and features), while not being low level enough to beat C++ in the same time (very inflexible binary target, GC-only, no inline assembly).
Go, the language, is better than Go, the PR. The early promotional materials claimed way too much. Some of those documents are still out there, especially "Effective Go". But the language, although overhyped, came out OK.
Go is really the successor to Java and COBOL. It's what you write your business logic in. We needed that. Java had accumulated too much excess baggage.
I find Go to be a great language for writing cross-platform applications. Cross-compilation and static linking for pure Go programs can simplify distribution of binaries greatly. Tools like the Hugo project (similar to Jekyll) just compile for all os/arch combos and upload to github from a single machine.
IMO static linking benefits software on a user's host machine more than it does a networked server, which is typically highly controlled, orchestrated and repeatable, or containerized these days.
Disclaimer: In the Go ecosystem's current state writing applications with GUI elements is not so simple. But, I typically only write command line utilities/apps. So I can't really say much to that end.
I used it to write a library for interfacing wave and wind model data. I also use it with a web app running on google app engine instead of Python which I used previously. It works pretty well so far and I like it.
Specifically i like how easy unit testing is with go, and how easy it is to create modular things. Its a simple language and I use it exclusively in my free time so I appreciate not having to learn crazy syntax for side project.
I don't understand why we "need" textbooks, specifically in the world of Computer Science. Most of the amazing work done to make computers are what they are today is available online.
Carefully crafted textbooks are comprehensive, balanced, and have a good learning curve (not too steep, not too shallow). Perhaps as importantly, they are edited and contain far fewer errors than a typical blog or Stack Overflow post. As such, they are invaluable as an introduction to new topics.
Just to give an example: reading Hopcroft, Motwani & Ullman is far more effective than trying to scrape together automata theory via blog posts or Stack Overflow. As a beginner, you can't even identify what is correct and what is wrong.
Maybe it's just the books for my course, but I have never seen a book with up to day information, a lack of spelling/subject matter errors, and an easily digestible format.
Every textbook I buy has turned into a huge paper weight.
Can you recommend some textbooks that aren't like that? I'm interested in EE, CE, and CS (Software engineering, DSP, and concurrency).
Maybe it's just the books for my course, but I have never seen a book with up to day information
Basic CS theory does not really get outdated. There's a couple of dozens book that I could recommend. Anything from Sedgewick & Wayne to Hopcroft, Motwani & Ullman.
I recently bought a software learning book for the first time in years. It was nice to read from something other than a screen for the first time in years.
Particularly for "small" languages like Go and C, there is a benefit to sitting down with a comprehensive reference and reading it cover-to-cover. A few hours/days spent in quiet study will pay dividends over just searching Google/Stackoverflow for how to fix whatever your current problem is.
I had a look at the PDF and the margins are normal for a magazine, but the font size is what I would consider normal for a book, which means there are too many words per line.
For designers: technical publications should have larger margins than a magazine, to leave room for notes, and smaller margins than a book, to save room for graphics.
The printed book has reasonable margins; there's over an inch of space on both sides of the book. The text is small but to my eyes looks like 12 or 13pt font (caps characters are around 2.5mm high). By way of comparison, the text is around the same as Leslie Lamport's LaTeX book and slightly larger than Donald Knuth's TeX book - though the latter has more dense text as the line spacing is reduced.
So yes, it's a dense book, but it's not particularly unusual for a technical book, and the 1" margin is sufficient for small annotations.
As was The C Programming Language 38+ years ago — at about the same time as troff was rewritten in C. Maybe it would have been appropriate to rewrite troff in Go for this one!
As someone who has much more experience with Python, the only time I reach for Python is the odd case where there isn't a comparable Go library (think pyqt). Writing Go programs is just easier than Python--the language is much simpler, static typing is a huge boon, documentation for all packages is available at godoc.org in a consistent format, great standard library, single-binary deployment, great concurrency, more performant, standard formatting, standard testing tools, better static analysis support (IDEs can autocomplete, for example), etc.
http://www.infoq.com/articles/the-go-programming-language-bo...
There's a free chapter available from the book's website http://gopl.io which should give you an idea of what the rest of the book is like. The intro goes into a little bit too much detail but if you gloss over that the remaining chapters are pretty else detailed. There are some nuggets distributed through the book but you could easily gloss over them if you were skim reading it, such as learning that exported identifiers begin with an upper case letter and those that are private are lower case.