5 ms·

Thanks for your responses, which I read carefully. I hope we can get a bit more out of this conversation. "Just use C" is odd to me given that Go was original

Thanks for your responses, which I read carefully. I hope we can get a bit more out of this conversation. "Just use C" is odd to me given that Go was originally developed to be an alternative to C (a "systems language") - this was an explicit design goal, and mentioned in the first main sentence of its specification[1]: "Go is a general-purpose language designed with systems programming in mind." So when you then glance at the adoption for those uses, you would come to the (wrong) conclusion that it must have failed to meet its original design goal of being better for those general use cases. (Or people would be using it). According to its designers, C and C++ programmers don't transition to Go (as its designers had thought they would), but Python programmers do. So I'd like to understand what it lacks that is holding that back. I see it as clearly superior. Looking at the design, it looks like it met its design goal. So I see it as successful in its bid to be design that is a viable replacement for C as a "systems language", and then despite this successful design now nobody uses it as a systems language. It would be as though someone set out to make a better bicycle wheel, succeeded, and then nobody uses it as a bicycle wheel (despite its being a better bicycle wheel), while meanwhile the design is being used to haul thousands of tons of freight per year (server microservices). I'm asking, "so why don't we use it as bicycle wheels" and am told "just use a wheel". But I want to understand why, because it seems to me it met its design goal of being a better bicycle wheel. For the second statement, your statement about "common to write apps using whatever the OS provides or using well-known libraries," makes sense and explains why these libraries didn't exist when Go was made. I don't understand why they are still not a big part of the ecosystem nearly a decade later. The "knights in shining armor" is a serious statement: the biggest benefit of the Go language is its gatekeepers keeping things out of it, and its extremely orthogonal, tiny syntax, which can be kept in mind along with state. The results of code can be reasoned about without a lot of gotchas. I am therefore wondering what, if anything, these gatekeepers are keeping out which prevents the two parts of the ecosystem which I mentioned, from flourishing. I don't think Go programmers who are also C and C++ programmers who are used to writing for embedded microcontrollers or for Windows in C and C++ respectively, require deep (or any) changes to the language before as a language it would be suitable to those two cases. You haven't mentioned any. So I still welcome more viewpoints. I don't see why Go can't replace C and C++ applications across all of the use cases I mentioned, with minimal first-party support by the language developers and maintainers. Doesn't Go also have alternative Go compilers based on the specification? I did a Google search for alternative Go compilers and the top result is from 2014: https://groups.google.com/forum/#!topic/golang-nuts/EwDS15Ewfs0 https://groups.google.com/forum/#!topic/golang-nuts/EwDS15Ew... As a followup, why is this the case? I mean, the Specification is quite clear, and it's a tiny language, so in the past 9 years I don't see why there aren't at least a few dozen independent implementations. Is it just not enough time, and we should wait a few decades? Is the issue that Google doesn't need Go for its desktop or mobile development stuff, and doens't need it for microcontrollers, and Go is not really an "independent" entity that is quite independent of Google as a company? Basically I am wondering why Go in 2018 isn't where C and C++ were by 1998, for example. Despite your detailed answers I don't see the missing pieces. Go as a syntax is better than C or C++ as a syntax. Its syntax and small and stable language features set are Go's primary advantages, which allows it run on the metal using clearly written standard Go libraries to serve web apps. To me, a microcontroller program running with next to no memory just has to not leak memory or crash, unlike Go running microservices, which have to withstand highly targeted and sophisticated attacks. Basically, given how I see Go (which is the reason for my very lengthy introduction, so that people could correct me if I'm wrong) I don't see why the language is not very far along where C and C++ blossomed as languages for embedded microcontrollers, and for Desktop applications. In a way you could say I don't really get what's preventing this. I can't think of any showstoppers. [1] Go language specification: https://golang.org/ref/spec https://golang.org/ref/spec

striking 8y ago
I tried to find a succinct question to respond to for your first section, and couldn't. My answer is the same as before: no one has bothered to write a Go runtime that can run on microcontrollers. This is because Go does not do anything fundamentally different from C at that level, except things that are less suitable for low-memory and low-CPU environments; and because it takes a lot of work to write a compiler and runtime for these devices. Note that there are very few compilers for each individual microcontroller. They generally only have one or two. >I see it as clearly superior. You are not looking hard enough. Go has flaws, as does any language or tool. It is almost a rule of thumb that not understanding the flaws of a tool is a sign of inexperience with it or alternatives to it. I think if you actually tried to learn and use C and C++, you might better understand the difference. >I don't see why Go can't replace C and C++ applications My answer is the same as before: it can, except that C/C++ apps already have that territory, and Go doesn't provide a fundamentally different experience except in lacking libraries for most GUI applications. There are still places it shines, though. For example, it is doing a fine job of replacing C/C++ for cloud orchestration tools; static linking is important to those users, and Go provides it easily. >Basically I am wondering why Go in 2018 isn't where C and C++ were by 1998, for example. This is a mathematical error. The C programming language was developed in 1972, and C++ piggy-backed off of C's ecosystem very effectively. >Go as a syntax is better than C or C++ as a syntax I don't think I can come up with a better example of a "skin-deep" comparison, nor do I think anyone has actually argued for C/C++'s syntax being actually good. >stable language features Didn't Go 1.11 break all of the community's tools? Isn't that why the story we're posting on the comments on exists? >To me, a microcontroller program running with next to no memory just has to not leak memory or crash, Some microcontroller programs need to have very low latencies, or the physical things they are connected to will break (the GC defeats this). Some microcontroller programs are only allowed a couple of KB of RAM (Go can't handle that). Most microcontroller programs are compiled without a standard library (and Go would have to provide its own impls of basic Go stuff in order to function). Some microcontroller programs never allocate memory, cannot allocate memory, or must allocate all memory up front. And so on. You can solve these things by having more expensive and fault-tolerant gear, or buying more RAM, or paying people to write more Go compilers/runtimes, etc., but these things get expensive fast; that is often incompatible with the design goals of what microcontrollers are used for. You're welcome to write Go and slap it on a Raspberry Pi, though. >In a way you could say I don't really get what's preventing this. Try writing a microcontroller program and GUI app, both in C or C++ and in Go. I very strongly doubt you will succeed faster in Go than in C/C++, in either kind of project, because of multiple factors: ecosystem, communities, example code, language features, existing toolchains and compilers... But if you don't believe me, try it out for yourself.

striking 8y ago

I tried to find a succinct question to respond to for your first section, and couldn't. My answer is the same as before: no one has bothered to write a Go runtime that can run on microcontrollers. This is because Go does not do anything fundamentally different from C at that level, except things that are less suitable for low-memory and low-CPU environments; and because it takes a lot of work to write a compiler and runtime for these devices. Note that there are very few compilers for each individual microcontroller. They generally only have one or two. >I see it as clearly superior. You are not looking hard enough. Go has flaws, as does any language or tool. It is almost a rule of thumb that not understanding the flaws of a tool is a sign of inexperience with it or alternatives to it. I think if you actually tried to learn and use C and C++, you might better understand the difference. >I don't see why Go can't replace C and C++ applications My answer is the same as before: it can, except that C/C++ apps already have that territory, and Go doesn't provide a fundamentally different experience except in lacking libraries for most GUI applications. There are still places it shines, though. For example, it is doing a fine job of replacing C/C++ for cloud orchestration tools; static linking is important to those users, and Go provides it easily. >Basically I am wondering why Go in 2018 isn't where C and C++ were by 1998, for example. This is a mathematical error. The C programming language was developed in 1972, and C++ piggy-backed off of C's ecosystem very effectively. >Go as a syntax is better than C or C++ as a syntax I don't think I can come up with a better example of a "skin-deep" comparison, nor do I think anyone has actually argued for C/C++'s syntax being actually good. >stable language features Didn't Go 1.11 break all of the community's tools? Isn't that why the story we're posting on the comments on exists? >To me, a microcontroller program running with next to no memory just has to not leak memory or crash, Some microcontroller programs need to have very low latencies, or the physical things they are connected to will break (the GC defeats this). Some microcontroller programs are only allowed a couple of KB of RAM (Go can't handle that). Most microcontroller programs are compiled without a standard library (and Go would have to provide its own impls of basic Go stuff in order to function). Some microcontroller programs never allocate memory, cannot allocate memory, or must allocate all memory up front. And so on. You can solve these things by having more expensive and fault-tolerant gear, or buying more RAM, or paying people to write more Go compilers/runtimes, etc., but these things get expensive fast; that is often incompatible with the design goals of what microcontrollers are used for. You're welcome to write Go and slap it on a Raspberry Pi, though. >In a way you could say I don't really get what's preventing this. Try writing a microcontroller program and GUI app, both in C or C++ and in Go. I very strongly doubt you will succeed faster in Go than in C/C++, in either kind of project, because of multiple factors: ecosystem, communities, example code, language features, existing toolchains and compilers... But if you don't believe me, try it out for yourself.