5 ms·

Happy birthday to a wonderfully refreshing language. > Go has also found adoption well beyond its original cloud target, with uses ranging from controlling tin

by K0SM0S 7y ago

Happy birthday to a wonderfully refreshing language. > 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.

low_common 7y ago
Agree with you on all of your points. I picked up Go in my senior year of college because it seemed interesting. None of my peers had heard of it. This led to my first job out of college where the company's backend was written in Go. Haven't looked back.
dodobirdlord 7y ago
> 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. 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.
- K0SM0S 7y ago
  OK, I understand better. I was indeed thinking of whatever piece of code hits the metal last before kernel (including kernel actually), I see now that was badly worded in GP. 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!

by K0SM0S 7y ago

low_common 7y ago

Agree with you on all of your points. I picked up Go in my senior year of college because it seemed interesting. None of my peers had heard of it. This led to my first job out of college where the company's backend was written in Go. Haven't looked back.

dodobirdlord 7y ago

> 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. 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.

K0SM0S 7y ago
OK, I understand better. I was indeed thinking of whatever piece of code hits the metal last before kernel (including kernel actually), I see now that was badly worded in GP. 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!