[hwc]

I'm so glad I use Go more than C++ these days. In Go, all values are always zero-initialized if you don't explicitly assign a value. If you need a constructor, you write a regular function that returns an explicitly assigned object.

I like keeping the rules of the language simple enough that there is never any confusion.

[javierhonduco]

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.

[maccard]

I 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]

It 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.

[kccqzy]

The 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]

Why would you have a wrapper around every primitive/standard library type?

[kccqzy]

Type 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.

[catlifeonmars]

FWIW there is a linter that enforces explicit struct field initialization.

[ErikBjare]

Haven't written Go in a long time, but I do remember being bit by this.

[zarathustreal]

Yea 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.

[dgfitz]

Wouldn’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]

It’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]

All bugs are considered bad practice, yet they keep happening :P

[crowdyriver]

You can always use 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.

[thowruasdf]

The downside is now all types must dogmatically have a nullary constructor.

The Default typeclass (or trait) as seen in Haskell and Rust, is a far better design, as this makes the feature opt-in for data types that truly support them.

[kccqzy]

Don't even need to go that far. In C++ it is common to delete the default constructor anyways. So that achieves the opt-in.

[dieortin]

Having to delete the default constructor means it’s opt-out, not opt-in

[kccqzy]

I don't think you really know what a real-life C++ code base looks like. Deleting the default constructor often happens implicitly with no syntax needed. This often happens when you define a custom constructor or when its member doesn't have a default constructor.

[jeffbee]

Go makes a completely reasonable tradeoff, giving away performance to gain ease of use. C++ also makes a tradeoff that seems reasonable or necessary to its users, that it makes it possible to not be forced to write to the same class member twice, in exchange for a more complex language. Any language that attempts to offer this property unavoidably adopts the complexity as well. See, for example, Java.