That and other things too. It's definitely the new C IMO. I like how the author contrasts it with Java, "There were many things that did not copy across due to the comparative richness of the Java libraries...". Of course, I like Java about the same as I like Go (both great languages). But if you are used to the wealth of pre-made data structures in Java you'll find arrays, slices and maps in Go to be somewhat limiting at first. You'll soon get it though and start doing really cool things with Go.
I've got a strong impression that Go is taking a similar spot in programming culture over time as Java has in the past of being an enterprise-friendly language with strong standards built-in.
This is the comparison I was going to make. Not because Rust looks or works anything like Ada, but because it has seemingly taken up the same spot in the industry's perception as the "Bondage and Discipline language" alternative to the "looser" languages like C.
In terms of how they will most likely be used, it seems Go will primarily serve as an alternative to Python, and perhaps non-mission-critical C to the extent that exists. Rust will serve as an alternative to most C.
If anybody wants a go library for hacking around with network programming I wrote a golang only wrapper around the linux zero-copy socket syscall. It also has some network utilities along with it:
How viable is this, since author said he wrote it in 2012? To me it looks okay, but I am willing to take opinion from someone more experienced with Go.
It serves as a great reference, the code in there runs with small changes, I know this because I ran the code myself when I was contemplating adding content from this book to my own FOSS ebook (https://github.com/thewhitetulip/web-dev-golang-anti-textboo...), I emailed the Professor and he gave his permission, but I skipped on adding chapters because this book itself was available via the author's home page and there was no point in me adding it to my tutorial, I am glad this is now available via gitbooks!
Since Go is backward compatible, it is in the contract somewhere, you can refer this book even though it was written a long long time ago!
I had the same question, but so far the answers here are from a "technical correctness" perspective (which isn't a concern since Go is good at compatibility).
My question is whether newer libraries and best practices have evolved since 2012, or if the ecosystem has remained static in this area since 2012. I'd certainly hope there's been some learning since then, unless Go really had already achieved perfection the first time around; color me skeptical.
I was immediately concerned seeing a "Security" section that includes a "Public key encryption" chapter. And indeed, I was (not) disappointed.
The symmetric encryption section mentions only Blowfish (!? - not even in the stdlib) and DES (!! - not even 3DES), not AES. There is of course no mention of authentication, or AEADs. But it gets worse. The API presented is Cipher.Encrypt which is CATASTROPHIC. Cipher.Encrypt is a low-low-level API that only encrypts the first block worth of data, AND LEAVES THE REST UNENCRYPTED. It's meant to be used by CBC/CTR/GCM block mode implementations, of which there is no mention at all.
This is all it says about, you know, encrypting real data:
> The algorithms are block algorithms. That is they work on blocks of data. If your data is not aligned to the block size, then you will have to pad it with extra blanks at the end.
This is the kind of advice which guarantees me a job forever. It's way worse than ECB.
The "Data integrity" section mentions MD4 (for which I can and did create a collision on my laptop in a few hundred lines of code) and recommends the broken MD5, converting the result into 4 uint32 for... some reason? It then calls HMAC a "variation" of a hash, while it's a completely different (and more useful) tool.
The public key chapter only mentions RSA, which is completely useless/dangerous on its own, and probably not what you should use in 2017, and offers a code snippet to generate a 512 bit key. 512. The stuff that academics break for fun.
The X.509 chapter makes a CA cert instead of a leaf.
The TLS section needlessly sets config.Rand and sets config.Time TO A FIXED VALUE, which off the top of my head might only break connections after a few minutes and not their security. Maybe. (And uses a funny "[0:]" with a needless 0, which I guess is a C-ism.)
> Security is a huge area in itself, and in this chapter we have barely touched on it. However, the major concepts have been covered.
I'm not saying anything about the quality of the rest of the book, but if you write a book on X where X != cryptography, please don't try to teach the user how to use cryptography. Or how to secure a gun.
Well, I got the impression that the book is an introduction, targeting newbies. Some things look out of place there, like cryptography and distributed systems. Maybe he needed to fill the pages, I don't know. But don't take it seriously, nobody is really going to look at those things and understand what they are about or make any use of them. People are going to have to learn a lot more to even get to a reliable networking service in Go, this book is not going to cut it.
I can't stress enough how wrong this is. The majority of mediocre programmers will take anything written in a book as gospel. When their boss tells them to encrypt the customer data, there is a non negligible chance they will go straight to a cryptography section in a book they read and copy it.
That's true, but no book can cover everything about every topic. Even if they put the disclaimer that examples are not to be just copy&pasted, superficial people will still do exactly that. Because that's what superficial people do. And IMHO it's not up to book authors to fix the flows in human nature...
The illusion of knowledge about crypto is very dangerous. People get this stuff wrong all the time and introducing more examples with really bad mistakes will only make the situation work.
I don't know. People are constantly learning new things and making mistakes is part of the learning process. If everyone told Linus a kernel is too complicated for newbies there would be no Linux.
This constant scare tactics and putting crypto on a needless pedestal is counterproductive as it may well turn potential learners off. It may be complicated but people learn complicated things all the time. No one is born an expert.
Making a kernel as a hobby doesn't put anyone in danger. And using a kernel someone else wrote as a hobby doesn't tend to put anyone in danger, either, because it's very clear when a kernel was written as a hobby (mostly because you can [almost] never run common commercial software on such kernels — a hobbyist kernel with Illumos-like "branded zones" supporting Windows or Linux software would be a very dangerous beast, if someone wrapped it up into a black box.)
To contrast, writing crypto as a hobbyist isn't dangerous, but using someone else's bad crypto can be dangerous indeed—because it's almost never clear that the crypto within the software you're using was written by a hobbyist.
People can learn crypto all they like. In private, sharing their learning with peers and/or mentors. But their "homework projects" should never be posted on the public Internet where they could be found by people looking for professional solutions, any more than a chemistry student's homework project of devising a work-up for making non-volatile explosives with volatile intermediaries should be posted on the public Internet where it might be treated as a safe, well-known procedure for doing so.
You don't need your crypto to be wrong for your software to be compromisable and dangerous to users. People use random packages and libraries all the time, and it's thought a best practice to not write things, to reuse random stranger's code instead. Yet when we talk about crypto, people jump to their guns. When we talk about package consumption and management, people are way more chill about it. In that sense crypto _is_ put on a pedestal: it's just one among many parts that can make a system unsecure. I guess it's worst in the sense that it gives an illusion of security. Yet for all practical purpose, it's just as likely to be wrong as any other part of the system.
Learn, but don't go around teaching others if you haven't a clue, like the author of this book is doing. That harms potential learners - not to mention everyone who is put at risk when insecure crypto inevitably ends up in production systems.
Yeah, but you don't learn crypto from a chapter in a book. You take classes, learn the mathematics, and then you use a library made by someone much more experienced than you
