[mirekrusin]

This suggestion fails for values that can be null, need to be mutable or need references from multiple places etc – it's not "just performance penalty".

Go has a problem, "just remember to always do X, never Y" patterns can't be guaranteed across all libraries you use, can't be enforced, can be violated for good reasons, other patterns and as a mistake etc etc.

Shame because otherwise it's a great language, but some mistakes are just no-go.

So close indeed.

They need Go 2 with *T and ?*T - that would be nice language to use.

[pjmlp]

The best approach is to use other programming languages with more open minded approach to modern type systems, and leave Go to the use cases where there is no alternative due to existing adoption.

Go 2 will never happen, they will keep incrementing 1.x until end of current computing model.

[Zambyte]

> They need Go 2 with T and ?T - that would be nice language to use.

Zig has basically been this to me. As a developer, writing Zig feels a lot like writing Go, except with basically all of the pain points addressed.

- Zig has different pointer types for different things. The default pointer type points to exactly one value. It also has an optional pointer type as described. Arrays and slices are also pointers of sorts, and a graph in this post[0] does a good job describing the relationships between N element pointer types.

- Zig has a built-in error type that is able to carry stack trace information.

- Zig has a syntactic shorthand for the common `if err != nil { return err}` pattern: the `try` keyword.

- Zig doesn't impose a garbage collected runtime.

- defer can handle arbitrary expressions in Zig. They do not need to be wrapped in a closure or a function call.

- The frankly weird interface system in Go is replaced with one of the more sane metaprogramming systems (I would argue that comptime is the most sane metaprogramming system in any C-like language).

Other than that, Zig and Go are very similar. They both use repos for modules. They have roughly the same concurrency semantics. They have the same allocate+defer deallocate pattern (though more flexible in Zig, also due to scope bound vs function bound). They both treat errors as values. They both disallow things like operator overloading. They both have built in testing systems.

Zig makes breaking changes in ways that Go doesn't anymore, but the breaking changes are always very thoughtful, and are clearly converging on something that is more flexible than Go (both in expressiveness, and in portability) but with a very similar mental model for developers.

[0] https://ziggit.dev/t/array-and-slice-address-relationship/14...

[carmly56]

I really like Zig, but the lack of easy to use interfaces is kind of a dealbreaker for me. One issue but I can't look past it when building anything of substantial size.

[Zambyte]

I've written a couple of fairly large projects in Zig, and never really felt like I needed anything more than what comptime provides. What kind of pattern do you think Zig would benefit from supporting?

[ktpsns]

Honest question, what is the zig version of goroutines these days? They removed async from the spec.

Honestly the only reason why I stick to golang for some projects are goroutines.

[Zambyte]

Zig 0.16.0 was the big, recent async update. Go channels are handled as std.Io.Queue, the select keyword is handled with std.Io.Select, and goroutines are handled with std.Io.async and std.Io.concurrent. The difference between async and concurrent calls are essentially: async calls may be called concurrently, or they may not (the execution of the async function is not dependent on the caller continuing to execute - like reading a set of files), and concurrent must execute concurrently (the execution of the concurrent function depends on the caller continuing to execute - like a client+server interaction, and will crash if the environment cannot spawn concurrent processes).

The fully userspace implementation is a bit more syntactically clunky than the concurrency primitives in Go, but it is very similar semantically.

[ktpsns]

Thank you for this valuable comment!

I remember having read somewhere that zig now requires to pass the Io argument around, which one can interpret again as "colored functions". IMHO it is a missed opportunity not to implement a more polished syntax and make a message passing paradigm a "first class citizen" in zig. Anyway, I like the fact that zig is iteratively "improved" and not a virtually "dead" language compared to golang :-)