|
|
|
|
|
|
by tpaschalis
2228 days ago
|
|
|
Of course it's a matter of preference and being the right tool for the right job! Personally after using Go to build a simple ray-tracer and having to do numerical computations with it, I would really think twice before doing it again. Want to reverse an array? You can't just list.reverse() or list[::-1] like you'd do in Python.
Want a simple lookup if a value exists? You can't ['a', 'b', 'c'].include? 'a' like you'd do in Ruby.
Want to reach for low-level primitives? You'd have to delve into CGO territory, which is not always "elegant".
Want different concurrent paradigms (eg. an actor model), well, maybe you're better off without it. But it's up to you whether that kind of 'simplicity' is desirable or not. |
|
|
Testing for membership in an array is O(n) in almost any language - and there's a lot of new coders who will happily call it inside a loop. My second internship, I reworked an O(n^4) method to O(n^2) for some code written in R by a senior statistician. This raised the feasible N from 4 to about 13 (in terms of what results you could get in two or three days of compute).
Google doesn't want anyone making that mistake in production, where throwing more servers at the problem costs a whole lot of money. And they hire a lot of junior devs.
I'm sure as somebody who's writing their own raytracer, you know the performance cost of this lookup intimately, and you've made the performance trade-off when picking your data structures. (E.g: maybe the include function is called rarely, or it really is just 3 items, etc). But Go is made for teams of varying skill levels, and so it takes the position that doing uncommon things should take some extra work.