On Tue, Apr 12, 2022 at 8:19 AM 'Jack Li' via golang-nuts < golang-nuts@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. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVXX-DfKqVmZVobr0tEfxJhvVFORfj7odHKehvc1Yf%3DaA%40mail.gmail.com.
