> Go has also found adoption well beyond its original cloud target, with uses ranging from controlling tiny embedded systems with GoBot and TinyGo to detecting cancer with massive big data analysis and machine learning at GRAIL, and everything in between.
I've often thought of this, but I'm not qualified enough to answer my own questions.
While a very expressive and extendable language like Python seems well suited to researching the desired abstractions when designing neural nets and ML paradigms, it seems to me that a production phase would benefit from translating it to a 'sleek' language like Go — which forces you to think closer to the machine, and opens boulevards to safe performance.
I wonder what people fluent in Go and other languages, experienced with ML, think of this. (it's a minor concern overall, but the future of Go in ML is of interest to me)
> especially the community working together.
I have to say this is one of the nicest things for a Go programmer, a 'Gopher' as they say. I've been online since the late 1990's (teenager back then), in all sorts of communities, and being quite civil and empathic myself I tend to have strong opinions about the 'mindset' or 'culture' on a very down-to-earth human level.
The Go community is among the very best. Period. One telling sign is how welcoming, respectful and elevating they are with newcomers, to Go or programming in general. It's a trainee's paradise, even if material is still relatively scarce compared to longer-established big names.
> In fact, people often tell us that learning Go helped them get their first jobs in the tech industry.
This should not go unnoticed. Few languages are able to move that needle — remember that for now, we increasingly need more developers than we can produce at a worldwide scale. It's both a matter of a language and its paradigm being in demand by employers, by clients projets; it's also a matter of said paradigm and implementation/spec to be conducive to the making of programmers.
We know the names. C. Java. PHP. Python. COBOL before that (and I hear, today still). It's the big ones that consistently do it forever regardless of 'project / tech buzz flavor of the year or even decade'. I have every belief that Go is destined to join this select club of industry norms. Lots of reasons why but among the most fundamental are ticking all the right boxes at a low level — ease of programming, stellar readability and portability of others' code, really cross-platform target, self-documenting, etc. etc.
Anyhow. Here's to a masterpiece.
This is a common perspective from outside of the ML field that arises usually from missing knowledge about the ML technology stack. Underneath the layer of expressive and exploratory Python lies a bedrock of optimized and domain-aware numerical libraries written in a combination of Fortran, C, C++, handwritten assembly and some HDLs. HPC resources are not cheap, so there is no software stack that provides a meaningful performance advantage over the one currently in use.
This does strikes me as an interesting perspective though:
> a bedrock of optimized and domain-aware numerical libraries written in a combination of Fortran, C, C++, handwritten assembly and some HDLs
So, we're talking lower level, from the kernel and above but below TensorFlow and Keras etc. I take it?
If yes, we're into systems by that point; it just so happens that this is Go's domain. Think of shrinking a 1000-brains 10-year cycle to a 100-brains 5-year or less (you may actually DevOps/CI-CD and sprint that stuff with Go like you would with most high-level's like Python or Js; a general "no-can-do" with low-level concurrent C++).
I may be wrong or totally out of my depth here, but I'm speaking of the library layer where e.g. in compute you'd see a CUDA-based industry versus whatever else (OpenCL...) take about a decade to unfold (and as much to move back); same in graphics, you'd see DirectX / OpenGL/Vulkan market penetration play over the entire lifetime of a GPU architecture (not 'gen', the core design like e.g. GCN).
I'm lacking the experience with ML workflows for sure; however the general hardware cycles and industrial market profiling seem to hold there as well (from GPU / TPU / FPGA / whatever fabrication, and the economics thereof; up to high-level software libraries and 'engineering muscle' that proponents of tech XYZ can push beyond marketing).
Where Go fits in that landscape is not so much versus a data scientist's Python but rather against infrastructure / Ops people's C++. Like Go is currently a strong candidate to refactor (parts of) the COBOL space, because it's basically 10x faster than in C++ or Java.
I'm thinking out loud. Don't quote me on any of this!
Tensorflow/Keras are frameworks built on:
> a bedrock of optimized and domain-aware numerical libraries written in a combination of...
You are not making any calculations in Python (if you do you are using native numerical libraries via FFI mostly), you only setup your workflow, prepare data etc. Heavy lifting is done in low level libraries used by ML frameworks.
That's why Go will not make it drastically more performant/better. Additionally most people doing ML knows Python, almost none know Go. 99% of tutorials, ML libraries etc are in Python. Not enough benefits to leave such an rich ecosystem in favor of Go. I write a lot of Go but even I would prefer Python over Go for any ML work.
I can give you one reason: Most of the ML tutorials online work on toy problems. Full stop. When it comes time to deploy the models, good luck, you need to move heaven and earth with devops stuff. Dockerize all your programs, add more heft.
Not so when using Go directly. There's a reason why data engineers are more in demand now than data scientists. With Scikit learn, keras etc it's easy to build models. It's not easy to deploy models to production. Half the tutorials don't teach the important bits: that your model needs to live in production.
Now, if you write your programs using Gonum or Gorgonia, you need to think a lot deeper about what your model is doing, about memory about things that software engineers think about. It's not easier, but it's the only sustainable way forwards.
And most libraries and implementations are also in Python because they work on toy problems?
> There's a reason why data engineers are more in demand now than data scientists. With Scikit learn, keras etc it's easy to build models. It's not easy to deploy models to production. Half the tutorials don't teach the important bits: that your model needs to live in production.
There is also a reason why you employ full stack web developer instead of frontend developer. I can tell you what is the reason - it's cheaper than employing frontend developer and backend developer. And for toy problems you can hire fullstack developer.
> Now, if you write your programs using Gonum or Gorgonia, you need to think a lot deeper about what your model is doing, about memory about things that software engineers think about. It's not easier, but it's the only sustainable way forwards.
So you are implying that whole industry, researchers and ML practitioners got that wrong and they should use Go now?
I know a lot of people working on ML related problems and none of them use Go for their ML work. Some of them have Go in their stacks, sure, but it's not used for ML directly. And they solve practical business problems.
I've also worked before with two ML researchers respected in the industry and I can assure you, they are not working on toy problems and they do not know Go. And this is coming from Go user and enthusiast. Programming languages are just tools, not a religion.
Programming languages are tools indeed. Some tools make life easy in one way, some tools make life easy in other ways.
Exactly, you always choose between different set of trade-offs.
Machine learning code isn't going to run just anywhere.
And coming soon, gorgonia on TPUs. Originally planned for this year, it seems to be next year now owing to some TPU peoples' timetable change.
> The primary goal is to make calling the CUDA API as comfortable as calling Go functions or methods. Additional convenience functions and methods are also created in this package in the pursuit of that goal.
Great angle. Very idiomatic to Go, and ballpark what most developers wish. Polishing the convenience aspect (until some 'promise of stability' by 1.0) is truly what makes some projects popular imho. UX (well DX, for Developer eXperience) is a clear determining factor especially in the age of open-source and generalized `git` remote pushes to 'the cloud'.
Might make things a bit more clear on the reasons why certain things are done in a certain way. It's by no means THE only way, but I hope I have listed my reasons clearly.
Python is great anyway, a language's intrinsic quality has nothing to do with whatever else the programming scene does. In my view it takes many languages to make a better software world, and while we don't want 250 (...), a couple dozen on a normal distribution seems quite adequate.
I gave this talk: https://speakerdeck.com/chewxy/data-science-in-go, I wrote this cheatsheet: https://www.cheatography.com/chewxy/cheat-sheets/data-scienc...
I wrote Gorgonia (https://gorgonia.org). I wrote a variant of AlphaGo in Go (https://www.youtube.com/watch?v=nk87zsxpF1A).
So, to answer your question, yes you are ABSOLUTELY correct in that intuition. I speak several languages - in the data world: R, Python, Julia; In the logic world: Haskell and Prolog (Datalog); In the software engineering world: C, Go, Rust. Go sits right in the middle of all this. From my point of view, it's the right balance and is Thanos' preferred language too.
On that note, Gorgonia has seemingly recently took off thanks to the heroic efforts of the community - this year there were talks not by me on deep learning in Go using Gorgonia and that kinda made me quite happy.
The names you mention, from Haskell to Rust passing by Julia... if Go indeed "is the right balance"... well it really makes sense based on what Pike, Ken, Russ and others said/say, and my related parts in my 20+ years of general computer nerding.
(currently listening to your YouTube talk and loving it)
I usually have massive nerves when I give talks. I once remarked how average Go is: https://blog.chewxy.com/2019/02/20/go-is-average/
Without generics (which Go will sorta get) and perhaps operator overloading (which will probably wont), slim chances...
But even more so, Python is not the performance bottleneck, as the libs are all optimized C, Fortran, etc. Not to mention Go has historically been even slower than Python's (C libs) in things like strings, regex, JSON etc.
Few languages are able to move that needle