So the language gives you the ability to dynamically resize / grow the slice, but you're NOT supposed to use it because of too many reallocs? Why tf would they confuse people like this? Are the developers of Golang secret assholes or is this just bad language design? Why not just require users to preallocate their fucking memory to begin with???
This video isn't wrong stating how reallocations happen but it's misleading in terms of performance. Dynamic Arrays are obviously designed in a way where reallocations are minimised. To append is O(1) amortized, that guy didn't explain the meaning of "amortized" which means that on average it will always take O(1) because reallocations "O(n)" get rare and rare, bigger the n gets. Because each relocation allocates twice as much memory than before, 1, 2, 4, 8, 16, 32 it's only reallocating on O(log(n)) of the times. Also you can use the make() function to preallocate a huge chuck if you know it needs more memory in the future. It's not a problem at all, all modern programming languages do it this way, "Dynamic Arrays, ArrayList, Vector (Rust, C++)" it's the same
This video was just to tell you that you should use static arrays when possible, but it isn't a big problem. Always benchmark it yourself, the performance gains are negligible in most cases
Exactly like @DuskyDaily described it. Both datastructures have their own use cases. Especially for high-performance algorithms, like high-dimensional indexing algorithms like HNSW, it's important which datastructure to choose.
I recommend to use the *make* function
This makes a slice of size 0 and capacity 50
*s := make([]int, 0, 50)*
Absolutely! Using `make` is particularly useful when you have an idea of how many elements you'll need.
Cool video. What font are you using in your editor?
I am sure it’s the JetBrains Mono font.
I am currently using the Monaspace front from GitHub.
So, it is similar to ArrayList in java, because that also works on the same way
Yes! They are similar in some ways, but they do have different implementations and functionality under the hood.
Good 👏.
Also we can use make function for slice if we know the approximate size. Later the capacity will be reallocate based on operations.
100%! If you definitely know the approximate size, you can go with the make function and pre-allocate memory for these elements.
great video
Thank you! :)
Ich dachte immer der Compiler entscheidet selbst wann er was auf dem Heap allokiert und dass ich das gar nicht forcieren kann?
was meinst du genau damit? Er redet über Kapazität von Array, und für den Compiler ist immer besser wenn du genau weisst wie viele Elemente du hast
So the language gives you the ability to dynamically resize / grow the slice, but you're NOT supposed to use it because of too many reallocs? Why tf would they confuse people like this? Are the developers of Golang secret assholes or is this just bad language design? Why not just require users to preallocate their fucking memory to begin with???
This video isn't wrong stating how reallocations happen but it's misleading in terms of performance. Dynamic Arrays are obviously designed in a way where reallocations are minimised. To append is O(1) amortized, that guy didn't explain the meaning of "amortized" which means that on average it will always take O(1) because reallocations "O(n)" get rare and rare, bigger the n gets.
Because each relocation allocates twice as much memory than before, 1, 2, 4, 8, 16, 32 it's only reallocating on O(log(n)) of the times. Also you can use the make() function to preallocate a huge chuck if you know it needs more memory in the future. It's not a problem at all, all modern programming languages do it this way, "Dynamic Arrays, ArrayList, Vector (Rust, C++)" it's the same
This video was just to tell you that you should use static arrays when possible, but it isn't a big problem. Always benchmark it yourself, the performance gains are negligible in most cases
Slices have their own use cases, you don't always know how many elements you will hold in the future
Exactly like @DuskyDaily described it. Both datastructures have their own use cases. Especially for high-performance algorithms, like high-dimensional indexing algorithms like HNSW, it's important which datastructure to choose.