4 ms·
Personally I’m not a fan of Go’s default zero-initialisation. I’ve seen many bugs caused by adding a new field, forgetting to update constructors to intialise t
by javierhonduco 2y ago
Personally I’m not a fan of Go’s default zero-initialisation. I’ve seen many bugs caused by adding a new field, forgetting to update constructors to intialise these fields to “non-zero” values which caused bugs. I prefer Rust’s approach where one has to be explicit.
That being said it’s way less complex than C++’s rules and that’s welcomef.
- ErikBjare 2y agoHaven't written Go in a long time, but I do remember being bit by this.
- maccard 2y agoI spent a year and a half writing go code, and I found that it promised simplicity but there an endless number of these kinds of issues where it boils down to "well don't make that mistake".
- gizmo686 2y agoIt turns out that a lot of the complexity of modern programming languages come from the language designers trying to make misaked harder. If you want to simplyfing by synthesising decades of accumulated knowledge into a coherent language, or to remove depreciated ideas (instead of the evolved spaghetti you get by decades of updating a language) then fine. If your approach to simplicity is to just not include the complexity, you will soon disciplinary that the complexity was there for a reason.
- zarathustreal 2y agoYea this can be problematic if you don’t have sum types, it’s hard to enforce correct typing while also having correct default / uninitialized values.
- crowdyriver 2y agoYou can always use exhaustruct https://github.com/GaijinEntertainment/go-exhaustruct https://github.com/GaijinEntertainment/go-exhaustruct to enforce all fields initialized. If you care, the linter is there, so this is more of a skill issue.
- catlifeonmars 2y agoFWIW there is a linter that enforces explicit struct field initialization.
- dgfitz 2y agoWouldn’t it just be considered bad practice to add a field and not initialize it? That feels strongly like something a code review is intended to catch.
- javierhonduco 2y agoIt’s easy to miss this in large codebases. Having to check every single struct initalisation whenever a field is added is not practical. Some folks have mentioned that linters exist to catch implicit initialisation but I would argue this shouldn’t require a 3rd party project which is completely opt-in to install and run.
- dieortin 2y agoAll bugs are considered bad practice, yet they keep happening :P
- kccqzy 2y agoThe problem you are describing in Go is rarely a problem in C++. In my experience, a mature code base rarely has things with default constructors, so adding a new field will cause the compiler to complain there's no default constructor for what you added, therefore avoiding this bug. Primitive types like `int` usually have a wrapper around them to clarify what kind of integers, and same with standard library containers like vector. However I can't help but think that maybe I'm just so fortunate to be able to work in a nice code base optimized for developer productivity like this. C++ is really a nice language for experts.
- dieortin 2y agoWhy would you have a wrapper around every primitive/standard library type?
- kccqzy 2y agoType safety. Compare `int albumId, songId;` versus `AlbumId albumId; SongId songId;`. The former two variables can be assigned to each other causing potential bug and confusion. The latter two will not. Once you have a basic wrapper for integers, further wrappers are just a one-liner so why not. And also in practice making the type more meaningful leads you to shorter variable names because the information is already expressed in types.