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.louis.ander...@gmail.com> wrote: > > >> 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. -- 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/1948C8B4-3F01-478F-BE53-91609B5D72BA%40ix.netcom.com.
