bitfield

Author here, thanks for posting! This recent Reddit discussion might give you a bit more information: https://www.reddit.com/r/golang/comments/1mmeg55/the_deeper_...

For more on the modern functional style in Go, including Map, Reduce, Filter, Sort, and so on: https://bitfieldconsulting.com/golang/functional

GPT-4 to be rebranded "Really The Last One".

Try https://bitfieldconsulting.com/golang/scripting instead?

"While we could usually write the specific code we needed for a particular program, before Go generics it wasn’t easy to write functions on arbitrary container types, such as slices.

For example, we couldn’t write a function that takes a slice of arbitrary type and determines whether the slice contains a given element. Instead, we had to write a function that takes some specific type, such as []int, or []string.

But this is dull, because the logic is exactly the same, whatever the type of the slice element. And now we can write that function just once, for all types. Let’s try."

What problem does 'defer' solve? When should we use it? How does it interact with named results? What's the use of deferring a closure? Is it okay to write naked returns?

Tests communicate a lot of information, to readers, other developers, and even our future selves. Well-written tests focus on a single unit of behaviour that can be described in a brief sentence, and we can use that sentence as the name of the test.

“If you get fired as a result of applying the advice in this book, then that’s probably for the best, all things considered. But if it happens, I’ll make it my personal mission to get you a job with a better company: one where people are rewarded, not punished, for producing software that actually works.”

"First, it's really important to say that both Go and Rust are absolutely excellent programming languages. They're modern, powerful, widely-adopted, and offer excellent performance. You may have read articles and blog posts aiming to convince you that Go is better than Rust, or vice versa. But that really makes no sense; every programming language represents a set of trade-offs. Each language is optimised for different things, so your choice of language should be determined by what suits you and the problems you want to solve with it.

In this article, I'll try to give a brief overview of where I think Go is the ideal choice, and where I think Rust is a better alternative. I'll also try to give a flavour of the essential nature of both languages (the Tao of Go and Rust, if you like)."

https://bitfieldconsulting.com/golang/rust-vs-go

No one wants to hear about this stuff unless you have a good acronym to go with it.

You might find this helpful, or at least interesting: https://bitfieldconsulting.com/golang/career

This piece is both good and original. However...

A slightly different approach: https://bitfieldconsulting.com/golang/cuelang-exciting

‘For the Love of Go’ is a book introducing the Go programming language, suitable for complete beginners, as well as those with experience programming in other languages.

This completely revised and updated edition includes the four mini-books previously released as ‘Fundamentals’, ‘Data’, ‘Behaviour’, and ‘Control’, plus for the first time complete solutions (with tests) to all the coding challenges in the book.

Throughout the book we'll be working together to develop a fun and useful project in Go: an online bookstore called Happy Fun Books!

Each chapter introduces a new feature or concept, and sets you some goals to achieve, with complete, step-by-step explanations of how to solve them, and full code listings with accompanying tests.

There are 24 chapters, and 215 pages (depending on the screen size of your ebook reader).

By reading this book and working through all the challenges and exercises, you'll learn:

How to write tests in Go and how to develop projects test-first

How to manage data in Go using built-in types, user-defined struct types, and collections such as maps and slices

How to use objects to model problems in Go, and how to add behaviour to objects using methods

How to use pointers to write methods for objects, and how to use types and validation to make your Go packages a delight to use

How to build powerful, flexible programs using control structures like loops and functions

Even more importantly, you’ll learn a simple, fun, and effective way to approach software engineering projects in Go. Even though the material is beginner-friendly, you’ll be mastering intermediate and advanced techniques such as test-driven development (TDD) and learning to design modules, packages, and APIs. These are essential skills in any modern software engineering role.

Interview by Bill Kennedy of Ardan Labs, for the Ardan podcast:

"John Arundel is a software consultant, mentor, and author of the book “For the Love of Go”. We talk about his early fascination with computers, the role his mother played in planting these seeds, and the steps he took in his younger years to follow his passion. We then explore John’s indirect job path, having to settle for work as a technical writer out of college and stumbling into IT and system administration. But the major lesson that comes out of this is that these 'detours' actually served John's later work, developing parts of his expertise that would aid him in his writing and mentoring."

A quick overview of CUE for those who are wondering what all the fuss is about: https://bitfieldconsulting.com/golang/cuelang-exciting

It's tempting to think that 'speed' (actually acceleration) causes time to flow at different rates for observers in different frames, but this isn't really the case. Time flows at the same rate for everybody: one second per second. However, if I meet you at an agreed rendezvous next week and one of us has accelerated in the meantime, we'll find our clocks no longer agree. We took different trajectories through spacetime to reach the same event, so our histories are of different lengths.

"Rust makes a number of design trade-offs to achieve the best possible execution speed. By contrast, Go is more concerned about simplicity, and it’s willing to sacrifice some (run-time) performance for it. But Go’s build speed is unbeatable, and that’s important for large codebases." —https://bitfieldconsulting.com/golang/rust-vs-go

For Go learning: https://bitfieldconsulting.com/books

You might enjoy this companion piece! https://bitfieldconsulting.com/golang/go-vs-python

> Go is more likely to get the job done, Rust is more likely to do the job well

That's surprisingly close to what one of my contributors wrote in the piece:

> My take: Go for the code that has to ship tomorrow, Rust for the code that has to keep running untouched for the next five years.

Not sure what you mean by 'folklore' in this context. There's a lot of discussion in the piece about memory safety, garbage collection, build performance, and so forth. Don't you think that's engineering, or at least engineering-adjacent?

Me too! You'll have noticed that that's exactly the structure of my article: which problems is Rust a better choice for, and which problems suit Go. It's intended to help people just like you, who want to pick a tool based on the problem they're trying to solve, rather than tribalism.

Could you provide a screenshot showing what you mean?

Well, no one is claiming that it's impossible to write Rust or Go programs that have security vulnerabilities—that would be a very silly thing to claim, wouldn't it?

A more useful way to think about it might be to ask whether such languages make vulnerabilities less likely, and for certain types of vulnerability (buffer overflows, for example), they absolutely do.

Well, the problem with that is that not everyone would agree on that way of classifying languages _either_! And people do want to know what the differences are between Go and Rust, as they're so often mentioned in the same breath. I think the comparison is valid (whether you agree with it is another question).

Well, the point is that which language you choose depends on what you want to do with it, and it's impossible to say objectively that one language is "better" than another. If you ask me which one I _like_ more, that's a totally different question, but no one cares what the answer is.

This depends on the context, though. In my open source projects, I have many contributors, so it's important to maintain a consistent style throughout (for example, naming conventions, so that the same data is always called the same thing).

A commercial software project will also have a 'house style' which all contributors are required to follow. It's okay to withhold approval on this basis.

What I think you're saying, and I agree with it, is "don't withhold approval just because this isn't your style".

You could try https://github.com/bitfield/ftl-fundamentals

I already know... what?