4 ms·
In regards to number crunching Go indeed made little effort to optimise this use case (especially since many good alternatives already existed at the time). Hav
by nasretdinov 1y ago
In regards to number crunching Go indeed made little effort to optimise this use case (especially since many good alternatives already existed at the time). Having said, I'm really hopeful that the SIMD proposals do eventually make it into the language, e.g. this one: https://github.com/golang/go/issues/73787#issuecomment-3208178910 https://github.com/golang/go/issues/73787#issuecomment-32081...
- lenkite 1y agoYes, this is the reason why there are no currently-maintained data-science/dataframe libraries in Go either
- OoooooooO 1y agoEvery DataFrame library with a significant user base uses function chaining because that's the best workflow for such stuff. Also notebook support / magic cell comments for iterative EDA. Python: polars-py, pandas, pySpark JVM: Spark R: R Go can't compete with this even with SIMD support.
- pjmlp 1y agoHopefully, as that is another area where other managed languages have finally started to taking seriously. Julia, .NET, Java (even if preview), Swift. While writing Assembly isn't that bad, having to deal with the Go Plan 9 Assembler syntax isn't something I am keen on putting up with.