connect
connect copied to clipboard
redpanda-data
FEEDBACK WANTED: Considering using Go 1.18 for the next release
Hey everyone it's been a while since we last updated the minimum Go version for Benthos and I'm considering updating to 1.18. The obvious immediate benefit would be to use generics in our own packages but it would also mean being able to use libraries that themselves use generics without having annoying build toggles.
Like before I'm pinning this issue, if setting the minimum version to 1.18 would be an issue for you or your team then let me know. None of this is blocking us from implementing anything critical so I'd rather delay than cause problems downstream.
👍 There are also performance improvements in 1.17/1.18 that Benthos could benefit from alongside generics.
generics/workspaces/fuzzing, I think identifying parts where generics could eliminate can be good. Also if there are parts where reflection is used to keep the code dry, can be refactored into generics. If there are not too many eliminations that can be gained through generics, I suggest keeping 1.18 at the bay, rather than quickly switching. Many tooling like text editors/IDEs are not ready(workspaces for examples completely obliterate my IDEs, it compiles but IDEs goes full clown mode), it just breaks for the time being, same comment also can be made for the linters.
could be good to see the experimental branch and observe how 1.18 can enhance the API
@MrWormHole we won't be using anything like workspaces for a while but I was definitely going to dabble with generic packages. I'll make an example branch with a few generics in there and we can see what breaks, I'm using vscode with the standard go plugin and it seems fine but ideally I want some feedback from all major IDEs.
@Jeffail for generics, there are no issues with GoLand or VSCode, however, for golangci-lint, there are many linters that don't work on 1.18. I am expecting all golangci-linter's linters to catch up with newest changes in 1.19 (in september)
I have a branch set to compile with 1.18: https://github.com/benthosdev/benthos/tree/segmentio-parquet, I had to disable a few of the linters but other than that everything else seems okay from my dev environment. Would be good if others could maybe pull that branch and see if your dev environment barfs or not.
In this particular example the library I'm bringing in is https://github.com/segmentio/parquet-go, which uses generics. I wasn't expecting to have an actual dependency using 1.18 this soon but I'd really like to bring this one in ASAP as it's a much better experience than the current library we're using for parquet.
I'd vote for moving to 1.18 as I think a lot of libraries will be moving to it as a minimum sooner rather than later. I see a chunk of the Azure SDK has a minimum at 1.18 now.
One thing to consider when dropping support for older versions is the official release cycle and support. Go supports the last two major versions, so if you want to be on the safe side, I'd wait until 1.19 is released.
From what I can tell, the upgrade from 1.17 to 1.18 wasn't as smooth as before (with impacts that are still with us today) which could also be an argument against making that version requirement bump this "soon".
On the other hand, people were hungry for generics, so probably more people upgraded to 1.18 than before.
We have a least one upgrade that's currently blocked until we drop support for 1.17: https://github.com/benthosdev/benthos/pull/1339, we've compromised on an earlier release for now but noting here so that we can grab that juicy v1 as soon as this is done.
I agree that it's reasonable to try and wait until 1.19 is released before we drop 1.17 so will keep it around for a bit longer.
1.19 is OUTTTTT (https://go.dev/doc/go1.19), I've got one release coming this week or next and then the one after we'll move to 1.18.
Some linters had to be disabled for Go 1.18. We should look into re-enabling them before closing this one.
This is ready to go but blocked for a couple of weeks due to a new baby jeffail, the baby is on a way older version of Go so has a higher priority.
I am curious, why not to switch right to 1.19 since it is out already? Soft memory limit feature (GOMEMLIMIT flag) seems very promising.
Hey @isae, we'll use 1.19 for release builds immediately, but I generally prefer to keep the enforced minimum package version to the lowest actively supported Go version. The reason for that is we still benefit from performance benefits of the latest version just not the language features, and it gives teams using Benthos as a library more time to upgrade in cases where it's non-trivial for them to increase their Go versions.
As of Benthos 4.6.0, a transitive dependency, github.com/rivo/uniseg, is included that requires go1.18 as a minimum. This is because it is using generics.
❯ go mod why github.com/rivo/uniseg
# github.com/rivo/uniseg
github.com/ourcompany/ourproject
github.com/benthosdev/benthos/v4/public/components/all
github.com/benthosdev/benthos/v4/public/components/pure/extended
github.com/benthosdev/benthos/v4/internal/impl/parquet
github.com/segmentio/parquet-go
github.com/olekukonko/tablewriter
github.com/mattn/go-runewidth
github.com/rivo/uniseg
For users building their own Benthos binaries on older Go releases, this means they are now required to bump their build environments as well or not upgrade to Benthos 4.6.0.
DONE https://github.com/benthosdev/benthos/commit/879791de8aceb05c3e5f3ae29f15d0469ed0cd31, consequences be upon us.