31–40 of 76 posts
Earlier quoted context omitted.
> The lack of even a dynamic array Are go slices not dynamic arrays? They grow automatically when necessary.
I think the dynamic array in this context means an array with multiple / any types as value. Example: [1, "hello", true]
skip Golang, go straight for Rust EDIT: as my time for learning new programming languages is limited, I would invest it in learning Rust, rather than learning Golang or learning both of them. IMO the only reason to learn Golang is if your already have a legacy Golang codebase or if you want to contribute to various open source projects written in Go, like for example Kubernetes (my first experience with Golang was tr…
Earlier quoted context omitted.
They are, but also very difficult to work with. For example, removing an element is a copy, followed by a slice notation. Inserting is combination of appends and slice notation. You don't get simple methods like insert(index,item). Also if you are growing the slice in a function, you need to find a way to return the possibly new slice variable since append might need to realloc so you often have to resort to using po…
(edit: exactly what sagi said, only more long-winded) : Removing an item from a list (that is actually performant enough that you'd want to use it) in Java is also a copy though, unless you're removing the last element. Underneath the hood, there's a copy. Same deal with insert. Given the number of times I've seen insert or remove used where it really, really shouldn't, I'm not so sure the lack of insert/remove is a…
Heavy reliance on such, as if they were free, is a very scripting-language thing. They hide all the grossness of such operations at the cost of significant memory bloat and inefficiency with simple, known-size structures (in order to make the more dynamic style run semi-fast at all).
There's no magic, and none of it's free, it just feels like it when you're push() and pop() and insert()ing all over the place. Making string manipulation closer to its roots as an array is also nice, in Go. If it's not worth bringing in a whole heavy library to deal with the awkwardness, then it wasn't worth writing the code that way to begin with. Figure out your lengths, resize as little as possible. Abuse and/or ignorance of how this all works is a big part of why we Can't Have Nice Things (performance, battery life) in the Age of Javascript.
Earlier quoted context omitted.
Clearly there's more to it otherwise Go and other languages would be a thing of the past. This is really not a topic for language flamewars and it's even against HN guidelines. I don't understand why people need to scream rust in every other language post like if it was a religion.
Devil’s advocate here : i think it’s due to the promise rust makes that borrow checkers prevent you from writing unsafe code or race conditions, as well as high level abstractions with zero performance cost. That set of promises really would make any programmer go crazy i think, and become a zealot. Rust is definitely on my todo list, i’m just waiting for the language to mature a little bit more, because some edges s…
This[0] is the best way I've seen to learn Golang. It's exactly what I needed to make things stick and make sense. 0: https://quii.gitbook.io/learn-go-with-tests/
skip Golang, go straight for Rust EDIT: as my time for learning new programming languages is limited, I would invest it in learning Rust, rather than learning Golang or learning both of them. IMO the only reason to learn Golang is if your already have a legacy Golang codebase or if you want to contribute to various open source projects written in Go, like for example Kubernetes (my first experience with Golang was tr…
I agree.
That's why I invested time into looking at Go over Rust.
Go will be the better choice for most programs most developers will write. Go 2 even more so. Rust is too complex, and for the applications where a garbage collector is acceptable (>99% of them) it isn't worth it.
This is wrong. https://golang.org/doc/effective_go.html#channels
> Receivers always block until there is data to receive. If the channel is unbuffered, the sender blocks until the receiver has received the value. If the channel has a buffer, the sender blocks only until the value has been copied to the buffer; if the buffer is full, this means waiting until some receiver has retrieved a value.
Such a great language. If only it had a good GUI library...
Go's not existent standard library is almost a deal breaker for me. The lack of even a dynamic array (c++ vector, Java arraylist) means you write a lot of 2-3 lines of slice notation phrases that require stopping and thinking about indices you wouldn't need to in other languages (and creating a lot of zero length slices for boundary conditions that shouldn't be needed). Also no balanced tree is a big issue (googles s…