I'm a little surprised deleting an element from a list is this hard but that seems to be a case. That seems like an API oversight. You shouldn't be writing your own code for what is a fundamental operation.
As for leaking Goroutines, yep that's a real thing. I had colleagues working on a Go project where exactly this was exhausting memory and causing the process to be killed. It can happen really easily.
I view this as a fairly fundamental problem with GC languages. GC solves some problems of course but in doing so it creates other problems.
For request-servicing type problems like servicing HTTP requests, I actually think the PHP/Hack model is pretty much ideal: stateless core (so low initialization costs unlike, say, Python), cooperative multitasking (ie no threads per se) and just throwing everything away after you're done. But I digress...
What Go does have going for it is syntax. It's minimal, opinionated without being too opinionated (IMHO) and familiar to anyone who has ever used a C-style language.
Deleting an element from a slice is a O(n) operation. It better be explicit in the program so the programmer knows just how expensive it is. Either you know what you are doing, and then writing it down is trivial, or you don't know what you are doing, and you are creating an efficiency problem for the future. Other data structures have a delete operation because it is efficient on those.
And fully agree on the GC part. GC doesn't remove the work of resource management. It simplifies it vastly. This can some times lull people into thinking they can ignore resources altogether.
> Deleting an element from a slice is a O(n) operation. It better be explicit in the program so the programmer knows just how expensive it is.
The chances of deleting an element in an array being a bottle-neck are really low. I'd rather save my brain cycles for thinking about disk/network access and wait for profiling to show me the problem.
Agreed. And the fact that disk access might end up being a bottleneck is not a good argument for making disk access APIs less ergonomic. I say give the programmer the nicest set of tools possible and let them make informed decisions about what’s appropriate to use when.
Yeah, I'm on board with the idea that expensive or not-recommended operations should be more verbose to discourage them.
But you'll find other expensive operations (eg prepending an element to a slice) are much less verbose. At a certain point (of verbosity), you're just adding the potential for bugs.
But why does the strings package exist if it’s better to write out the for loop each time? Do you think there won’t be a slices package after Go gets generics?
The argument that writing out the loop is better for readability is just status quo bias. The real reason we don’t have standard functions for such things is a technical limitation that will probably be removed soon.
Another thing that drove me up the wall recently (semi-related to leaking goroutines) are libraries that doesn't use the context package or a done/quit channel and can get stuck in long-running operations that hug absurd amounts of CPU/memory.
As far as I'm aware, you simply cannot kill a goroutine from another goroutine, i.e. there is no terminate()/stop() construct, meaning you cannot implement a timeout on top of an existing library without actually modifying said library.
As for leaking Goroutines, yep that's a real thing. I had colleagues working on a Go project where exactly this was exhausting memory and causing the process to be killed. It can happen really easily.
I view this as a fairly fundamental problem with GC languages. GC solves some problems of course but in doing so it creates other problems.
For request-servicing type problems like servicing HTTP requests, I actually think the PHP/Hack model is pretty much ideal: stateless core (so low initialization costs unlike, say, Python), cooperative multitasking (ie no threads per se) and just throwing everything away after you're done. But I digress...
What Go does have going for it is syntax. It's minimal, opinionated without being too opinionated (IMHO) and familiar to anyone who has ever used a C-style language.
I tend to view Go as a better Python.