With book on Go, Kernighan guides students at Princeton and beyond
princeton.edu
princeton.edu
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.
I'm not sure that should be considered a nugget, as much as a fundamental.
I would have thought that a modern language would automatically take care of such things.
For this reason Java has try-with-resources, C# using, Haskell bracket and Go defer.
Note that you can attach a finalizer to a Go struct: https://golang.org/pkg/runtime/#SetFinalizer
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
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.
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!
[1] There is/was some educational value in using Java as a teaching language, but there are far better choices now.
- 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.
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?
[0] https://play.golang.org/p/ZWLaVuJNgq you don't need to import append or cap or complex128 either
[1] and the same as in more or less every language out there
(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.)
The universal protocol in Plan9 is called 9p which the Go authors worked on before Go. A top level Go player is a 9p.
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.
Save your money and stay away from it.
"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."
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?
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).
I wouldn't bet on it, Go's designers consider the language more or less done:
https://docs.google.com/presentation/d/1JsCKdK_AvDdn8EkummMN...
(Make sure you continue until the anti-climax.)
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 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 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.
https://github.com/spf13/hugo/releases
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.
and neither would fall on its face it you need a gui
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.
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.
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).
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.
K&R really is a classic; even as a beginning programmer it rewarded so much on first and almost every subsequent reading.
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.
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.