Why Go has only slice and map

[Jack Li]

Hi group,

Why Go provides only 2 built-in data structures, slice and map. It has just more than C, but less than all other programming languages I've heard of, C++, Python, Swift, Rust. 

I think this simplicity attracts me very much. Sometimes I can use only one data structures for a task. Because there is no more similar data structures for choice. It's really "one way to do one thing". This also makes code like familiar and consistent.

I want to know more about the mind behind this design of built-in data structures.

Thanks

[Sam Hughes]

I'm certainly not privy to the nitty-gritty, but I'd encourage you to skim over the Go Dev team meeting notes. It's really cool to see what people have proposed over the years, how the team interacted with it, and ultimately why yes, why no. It's been really educational.

The short of it is Java. That's a joke, because Java isn't short. We don't need another Java. The result is that an idea has to be very, very, very good to be accepted and developed internally. In the meantime, you should check out this repo: https://github.com/Workiva/go-datastructures It hasn't changed much lately, but that's because, for its API, it's maybe mostly done. The issues are generally from bad expectations, and there isn't much to add. Generics means that some of them could be implemented differently, but that's more an indicator that better projects might exist nowadays.

[Axel Wagner]

My summary would be, that

1. The designers wanted *some* data structures to make day-to-day programming easier, and

2. Go didn't have generics, so they couldn't add a lot of them as libraries.

So putting things like maps, slices and channels into the language is a tradeoff - you don't need to buy all the complexity into the spec, while also allowing you to get your work done.

Note that all the other languages you mention don't really come with more datastructures in the *language* - it's always done as a library.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/tencent_7D168C1B263BF2B862B18796F28F82753009%40qq.com.

[Jesper Louis Andersen]

On Tue, Apr 12, 2022 at 8:19 AM 'Jack Li' via golang-nuts <golan...@googlegroups.com> wrote:

Hi group,

Why Go provides only 2 built-in data structures, slice and map. It has just more than C, but less than all other programming languages I've heard of, C++, Python, Swift, Rust. 

I think this simplicity attracts me very much. Sometimes I can use only one data structures for a task. Because there is no more similar data structures for choice. It's really "one way to do one thing". This also makes code like familiar and consistent.

Language design is often a trade-off. Note that a slice `[]T` allows T to vary. And a map `map[K]V` both K and V can vary. This immediately means that to support these, you need type variables in your language, in some way. The full support of this requires generics, modular abstraction, etc. Maybe you don't want to do that early on, since it severely extends the size of the language. In turn, you can't have slices and maps implemented in a library.

But even if you could implement it in a library, slices and maps are so ubiquitous they show up in almost any program. This argues we should add some notation to the language to ease their use. If they live in libraries, their use can become a bit more cumbersome. On the other hand, there is a limit to the amount of notation we want. Too much can limit future extensions, and also gives the language a larger surface to learn from scratch.

In a language with a garbage collector, you might need to tell it about primitives such as a map and/or a slice. A slice of non-pointer types doesn't need scanning for instance. So even in the case you end up implementing this in a library, the internals of the library might need to "speak to" the GC subsystem anyway. In the case of channels, the interface is a large part of the runtime.

Standard Libraries which are data-structure-rich often end up with subpar implementations, because they have to support every possible use case. If you are willing to forgo some aspects of the full generality, you can often write or select a faster variant for your particular case. This argues some structures are better pushed out into the ecosystem, where they don't provide extra work/pressure on the core development team.

Finally, if you look at typical programs in the real world, slices (arrays) and maps are probably the two most common types you'll find. And they are able to emulate many other data structures with little extra work.

[Robert Engels]

Nit but you can certainly create maps and slices in a library - you use methods not language syntax - as long as you have pointers and type casting. 

On Apr 12, 2022, at 1:30 PM, Jesper Louis Andersen <jesper.lou...@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVXX-DfKqVmZVobr0tEfxJhvVFORfj7odHKehvc1Yf%3DaA%40mail.gmail.com.

[Jesper Louis Andersen]

Very true!

--

J.

[Ian Lance Taylor]

The short answer is that in the early days of Go language features
were added if several programs required them. Many programs needed
slices and maps, so they were added to the language. Both types went
through many permutations in the early days before settling into the
versions we have today. Even very basic operations like "append" were
added after the first release of Go.

No other data structures came up nearly as often as slices and maps,
so no others were added to the language.

Now that generics are in the language, it will be easier for people to
write their own general purpose data structures. We'll see what
people come up with.

Ian

[Tyler Compton]

Interestingly, Go also kind of has a built-in set data type by using map keys! https://go.dev/play/p/3-ZEKPSPUEh

I know that's not really what you mean, but I think it's a cool pattern.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVcgKKoapCNuebfyk%2BkaXc3X2sn3h6K5eGGppi7TCdPPA%40mail.gmail.com.

[Zhaoxun Yan]

https://github.com/Workiva/go-datastructures

Are they available in the current version of go?