It is a suprisingly hard thing to implement well. I have no idea how many times I have implemented slice-like things in C (back in the 1990-2000s when I mostly wrote C) and it was one of those things I never managed to be happy with.
An expressive type system also often means slower build times. I dislike working with Rust for this exact reason.
While most people highlight the difficulty of picking up the syntax, I find Rust to be an incredibly tedious language overall. Zig has a less expressive type system, but it compiles much faster (though not as fast as Go).
I like the balance Go strikes between developer productivity and power, though I dearly miss union types in Go.
An expressive type system absolutely, positively, unequivocally does not imply slower build times (especially with a Church-style type system). There are plenty of programming languages with advanced type systems which compile extremely quickly, even faster than Go, for example OCaml.
Don't make the fallacy of conflating Rust's slow compile time with its "advanced" (not really, it's 80's tech) type system. Rust compilation is slow for unrelated reasons.
As a start, Go could separate container and slice types, the way C# did it with T[]/List<T>/other and Span<T>/Memory<T>. No lengthy build process required.
Yeah, but the at the same time, I find C# code a sigil soup. Go makes a different tradeoff.
I've been involved in a few successful large scale projects and never felt like the type system of Go is holding me back too much. Sure the error handling could be better, union type would make interface munging easier, but the current state after generics isn't too bad.
The interface layout has changed since the article (although this specific article doesn't mention interfaces, a later article in the series does). Additionally Go now has generics.
It's true that little has changed, but very little is changing in the data representation of any language, really. Even ones that are evolving rapidly.
it’s a good read, but i think it should focus more on some of the common mistakes that people make when slicing a slice.
Slicing a slice is full of gotchas. I tend to forget all the rules and avoid it whenever I can.
It is a suprisingly hard thing to implement well. I have no idea how many times I have implemented slice-like things in C (back in the 1990-2000s when I mostly wrote C) and it was one of those things I never managed to be happy with.
It can be done but that requires a better, more expressive type system.
An expressive type system also often means slower build times. I dislike working with Rust for this exact reason.
While most people highlight the difficulty of picking up the syntax, I find Rust to be an incredibly tedious language overall. Zig has a less expressive type system, but it compiles much faster (though not as fast as Go).
I like the balance Go strikes between developer productivity and power, though I dearly miss union types in Go.
It's possible to build languages that compile faster than Go, with a much more expressive type system.
It's just that compile times and DevEx haven't been a priority for most projects.
An expressive type system absolutely, positively, unequivocally does not imply slower build times (especially with a Church-style type system). There are plenty of programming languages with advanced type systems which compile extremely quickly, even faster than Go, for example OCaml.
Don't make the fallacy of conflating Rust's slow compile time with its "advanced" (not really, it's 80's tech) type system. Rust compilation is slow for unrelated reasons.
As a start, Go could separate container and slice types, the way C# did it with T[]/List<T>/other and Span<T>/Memory<T>. No lengthy build process required.
Yeah, but the at the same time, I find C# code a sigil soup. Go makes a different tradeoff.
I've been involved in a few successful large scale projects and never felt like the type system of Go is holding me back too much. Sure the error handling could be better, union type would make interface munging easier, but the current state after generics isn't too bad.
> Sigil soup
Last time I checked, C# had clean and focused syntax for working with collection types. Could you provide an example?
Appending a slice is also full of gotchas. Sometimes it modifies the slice in place, sometimes it reallocates and copies.
(2009)
It's Go we're talking about. Other than 64-bit the dominant word size, nothing much has changed.
It's still not news.
[delayed]
The interface layout has changed since the article (although this specific article doesn't mention interfaces, a later article in the series does). Additionally Go now has generics.
It's true that little has changed, but very little is changing in the data representation of any language, really. Even ones that are evolving rapidly.