Hacker News new | past | comments | ask | show | jobs | submit | teivah's comments login

Generics are already there.


Indeed. And we only had to wait ten years for them, from Go 1.0 to 1.18.


His review contains comments annotated on a book of 300+ pages. I don't think it would have made this section any better by deep diving into his review.


Outdated I'd rather say :) I documented here https://100go.co/#not-being-careful-with-goroutines-and-loop... but you're right, it was fixed (alongside 2 other mistakes in the 100).


I still need to support Windows 7 in my industry. The last supported version is 1.20. Outdated is relative.


I wrote some code today and I relied on the new behaviour. I felt a little dirty.


I said I was a source of inspiration for the mistakes in my book. Said differently, I've done a lot of mistakes myself which ended up being a section in the book.


It's your opinion, nothing wrong with it. Let me try to see if I can make you change it at least a bit.

> The first paragraph is totally pointless - we are reading a book about 100 most common mistakes, obviously this mistake is very common, how did this increased the value?

There are different levels in terms of common mistakes, and this one was probably one that all the devs did at some point. So I think highlighting the fact it's a frequent one does make sense.

> Then we have another line that explaining what happens in the code, which is totally useless because the code is super trivial.

I have a rule: always explain the intention of the code. Even if it's 5 lines of code, it helps the reader to better understand what we will want to highlight.

> Then the code, with more explanations on the side as if the previous line was not clear.

The explanations on the side do not impact the size of the book so the argument doesn't hold. I did it in many code snippets to highlight where the reader needs to focus.

> I understand that book publishers feel they need to justify the price of a book by reaching the 300p mark in some or other way

This is more about guiding the readers, making sure the expectations are crystal clear and that they can follow me throughout an explanation. You judge it as a criteria to justify the price of the book, but it's not the real reason. At least not for my book and I'm sure it's the case for many others :)


> This is more about guiding the readers, making sure the expectations are crystal clear and that they can follow me throughout an explanation.

Sure, but this holds true for the blog version as well, right?

To be clear, I'm not advocating for The Little Schemer version, and am not arguing that the blog version is the best it can be, but surely we can agree that book padding phenomenon does exist.

By the way, I have read parts of your book over at O'Reilly Learning, and I do think it is a good book. So I'm not trying to take a dump on your work. My criticism is aimed at publishers.


No worries I didn't take it as a criticism. I understand your point. I mean when we sign a contract there's a minimum number of pages to write. But personally, I never felt the pressure of having to add more stuff.

Instead, my DE multiple times told me that it's better to favor just-in-time teaching over just-in-case teaching. Meaning multiple times, he made me drop certain section because they weren't really serving the chapter. They were "perhaps helpful" and he made me drop all of those.

I guess it also depends on who you're working with and which publisher. On this aspect, Manning was fair, imo.


#63 isn't about the lack of execution guarantees when you execute multiple goroutines without proper synchronization; it was related to loop variables and goroutines.


That's why Manning will consider a 100 Rust Mistakes edition.


More details here: https://100go.co/#not-being-careful-with-goroutines-and-loop.... My example was probably terrible as it's one of the three mistakes in the book that aren't relevant anymore, thanks to Go's recent updates.

Thank you very much for your comment, though. It means a lot.


So not only do you write a full book, but you keep the content online, up to date by making sure readers are informed of new developments that might make advice irrelevant? And you are able on the spot to say "one of three mistakes that are not relevant anymore"? You impress me, random book-writing Internet person.

You give me a feeling you really care about the craft and just making a good useful resource, which what I respect. I looked around the site and bookmarked it as a technical writing example I might go to read around now and then.

I sometimes teach coding or general computing things (but hands-on, less about writing) and I've come to appreciate that sometimes it is extraordinarily difficult to educate on or communicate complicated ideas.

Quoting you: To give you a sense of what I mean by improving the book “over and over“, keep in mind that between feedback from my DE, external reviewers, and others, there are parts of the book that I rewrote more than ten times.

I also do rewriting especially with content I intend to be a resource or education piece. Obsessively rewrite. Make it shorter. Clearer. Oops that reads like crap let's start over. IMO having an urge to do this and address all feedback or your own itches means you care about your work. Just have to remind myself that that perfect is the enemy of good enough (or something like that I forgot if the expression went exactly like that).


If you'd ever write a follow-up, would you just remove "mistakes" and end up with the book "86 Go mistakes and how to avoid them", or find more?


Agreed. That was also my point when I mentioned the book started the "100 ${LANGUAGE} Mistakes and How to Avoid Them" series at Manning.


Thank you!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: