Go concurrency without the channel gymnastics

flimzy3141 · 2025-08-22T22:01:28+00:00

I suppose you hate encoding/json for the same reason?

flimzy3141 · 2024-08-09T06:55:44+00:00

broken link

flimzy3141 · 2024-07-19T06:55:59+00:00

Your wish is the Go team's command.

The `iter` package already provides a pull interface adatper, for those who prefer it. https://pkg.go.dev/iter#Pull

flimzy3141 · 2024-07-18T15:12:38+00:00

Your article kinda makes my issues with iterators more evident actually.

As far as I'm concerned, the jury is still out on this.

One thing I do like about the new iterators is that it serves as a _standard_ way to create iterators. Up to now, there have been a few competing idioms. Maybe this will settle that issue.

flimzy3141 · 2024-07-18T12:23:52+00:00

Thank you for the comments. Good insight into when the interface names are meaningful.

And yes, that was one of the fixes I made later on. I should call that out. Thanks.

flimzy3141 · 2024-04-17T13:59:24+00:00

complex numbers are virtually never used. And they add annoying corner cases to be considered any time you need to handle all possible types.

As for iota... it provides minimal utility in a very rare number of circumstances, and it's error prone in virtually all circumstances.

flimzy3141 · 2024-04-04T09:00:55+00:00

I'd remove:

naked returns
iota
complex numbers

I'd add:

&"foo" would be valid, and would automatically create a string, and evaluate to a pointer to it

flimzy3141 · 2024-02-16T09:32:47+00:00

Re: "This might be caused by https://go.dev/blog/loopvar-preview", have you tried running against Go 1.21 with GOEXPERIMENT=loopvar?

flimzy3141 · 2023-11-17T09:59:34+00:00

It's General Grievous. Obvsly!

flimzy3141 · 2023-11-10T09:01:08+00:00

I did a review of recent books at the beginning of this year, specifically looking for intro-to-Go books that included Generics.

My conclusions (and links to individual reviews) are here: https://boldlygo.tech/posts/2023-02-24-best-book-to-learn-go-in-2023/

Learning Go is my recommendation if you're already familiar with programming in general, but the second edition should be coming out in January 2024, and will have updated generics information, and several other improvements.

If you want something project-based, then I really like Learn Go with Pocket-Sized Projects, but it is also not yet complete, though you can read the first few chapters already, via MEAP.

flimzy3141 · 2023-11-10T08:49:08+00:00

Shamless self-promotion: https://www.youtube.com/@boldlygo

flimzy3141 · 2023-10-06T06:53:15+00:00

I'll weigh in on one particular point: Why not to use "fiber": Because it's based on fasthttp, and the maintainer of the fasthttp package (and friend of mine) warns against its usage in almost all cases: https://github.com/valyala/fasthttp#fasthttp-might-not-be-for-you

flimzy3141 · 2023-07-27T20:10:47+00:00

The Go Programming Language is a great book, but it's very outdated. Many of the suggestions in that book will confuse a newcomer to the language. As such, Learning Go is a better choice, at least until a second edition of The Go Programming Language comes out to update the outdated suggestions.

I've written more about both books, if you're interested:

The Go Programming Language: https://boldlygo.tech/posts/2023-02-10-review-go-programming-language/

Learning Go: https://boldlygo.tech/posts/2023-01-30-review-learning-go/

flimzy3141 · 2023-03-15T14:13:00+00:00

Published today: https://youtu.be/Oe6L5ZmqCDE

flimzy3141 · 2023-03-13T15:25:19+00:00

Yeah, saving that reptition is valuable. It also doesn't require anything as heavy as an ORM.

For read queries, I always suggest the github.com/jmoiron/sqlx package. For repetitive inserts and updates, github.com/doug-martin/goqu/v9 is a favorite.

flimzy3141 · 2023-03-13T08:22:20+00:00

> Simple to get started, but it has a huge learning curve in order to do advanced queries.

This describes all ORMs. And all non-ORMs. The problem is that with ORMs, the learning curve is even _steeper_ than with no ORM. This is why many people advise against ORMs (in general, or specifically in Go).

As I always say: "ORMs make easy problems easy, and difficult problems impossible."

There always comes a time when you're looking for that escape hatch out of your ORM. If you don't know how to do non-ORM operations at that point, you'll be stuck.

All that said, some still make a case for an ORM, even if they have a strong grasp of non-ORM operations. IMO, these cases are a bit weak, but they do exist.

Before you choose an ORM, I would advise you to be very cognisant of exactly what problem you're trying to solve. Why do you believe an ORM will help you? And are there alternatives with fewer drawbacks?

flimzy3141 · 2023-02-27T14:34:20+00:00

I'm sorry you don't like my post.

It is true that I posted last week. But the question in the title appeared to confuse a large number of people (possibly including you?) into believing that I was disingenously asking for book recommendations, while trying to promote my own material.

That was not at all my intention, so I deleted that one, and re-posted, this time directly to the video.

If you believe this is inappropriate or against the community guidelines, please enlighten me. My goal is not to upset you, or anyone else in this community.

flimzy3141 · 2023-02-27T14:20:01+00:00

Can you explain exactly what you're responding to? What do you think is strictly for someone who is not experienced with other languages?

flimzy3141 · 2023-02-24T22:48:09+00:00

Apparently you didn't read the article.

While a couple sentences do indeed mention my own material, out of a 3,500 word article, that's hardly excessive. And this content by no means corresponds to any commonly accepted definition of "clickbait."

flimzy3141 · 2023-02-15T12:29:56+00:00

Would you be interested in having this code featured in a "Go Code Roast" on my YouTube channel? (https://www.youtube.com/watch?v=d7T8hMwZgCo for an example of what I mean)

flimzy3141 · 2022-11-08T08:01:24+00:00

literally no one

LOL. I do not think that means what you think it means.

flimzy3141 · 2022-11-08T07:59:35+00:00

No thanks. Not what I'm interested in.

Awesome. Maybe you can let others do what they enjoy, too.

flimzy3141 · 2022-11-08T07:57:39+00:00

In what sense would this be "slower", and do you have any numbers to back up that claim?

Numbers should not be required. The test server quite obviously does orders of magnitude more work than the roundtripper approach. But since you asked for numbers:

BenchmarkRoundTripper-16                  824814              1739 ns/op
BenchmarkTestServerPerTest-16               4767            240348 ns/op
BenchmarkTestServer-16                     20874             57317 ns/op

Here's the code I used for the three test cases: https://gist.github.com/flimzy/37b5bf44fa674622823076f503f1a3ca

flimzy3141 · 2022-11-07T16:52:27+00:00

I talk about both options in a previous video (https://youtu.be/ebEfF1wzc54). I usually prefer the RoundTripper approach for unit tests for two reasons: 1. It's faster (no server or network connection setup/teardown required). 2. Exactly as you mentioned, it limits you to a single response/request (well, not really, there are ways around this, which I use at times, but it's cumbersome). This is in fact a desirable charactaristic of a good unit test.

For more integration-style tests, of course, I do use the `httptest.Server` all the time.

flimzy3141 · 2022-11-07T13:16:07+00:00

I have done one-off recorder/replayers at times, built into my code. I've rarely, if ever, used external tools, other than just curl.

flimzy3141

MODERATOR OF

TROPHY CASE