3 ms·

Not going to edit the above but people clearly hate it (many downvotes without minutes of posting). At the moment I think most Go programmers who also program

Not going to edit the above but people clearly hate it (many downvotes without minutes of posting). At the moment I think most Go programmers who also program tiny microcontrollers with a few hundred KB or up to a couple of MB of RAM, do so in languages like C or Rust, not in Go. Why not? It's a fair question. For those of you reading this on a laptop or desktop, how many desktop applications are you all running at the moment or have as an installed application? How many are written in Go? Why so few or none? I mean desktop applications like Audacity for audio, or VLC, or Open Office, or your web browser, and so forth. The downvotes came pretty fast so you clearly have some ideas. I'd like to hear them.

Rexxar 8y ago
I don't downvote you but ... No one hate your post. It's just an huge wall of text unrelated to the current post. It seems not the good place or the good moment to discuss this. You can maybe try to do an "Ask HN" for open question like this.
- logicallee 8y ago
  I think it's a great place to ask this. The most fantastic people to answer the question are going to be reading a post like this, and what we're reading about (adding a Go language server to core) is a huge and language-specialized feature for core. I look forward to reading people's answers to my questions. I thought the downvotes were because of something I got very wrong. Anyway I hope to learn from responses even if I got something wrong.
justinclift 8y ago
Didn't downvote your post above, so that wasn't me. That aside, there are some resources around for this though I've not (yet) tried any of them: * http://embd.kidoman.io http://embd.kidoman.io - Go Embedded Programming Framework. Seems to support Raspberry Pi and BeagleBone Black. * https://gobot.io https://gobot.io - Robotics more than embedded, but there seems like some overlap. :) --- With the "Why no desktop apps in Go?" question, for me it's because I'd only do so using something like Qt (cross platform). While there have been several attempts to get usable Go bindings happening for Qt, none of them seem both really well done + long term stable. The best developed Qt bindings so far are https://github.com/therecipe/qt https://github.com/therecipe/qt. But that seems to have tapered off and the developer doesn't seem interested in making it into a team project (eg long term viability). That's my impression anyway, I could be wrong. :)
striking 8y ago
>people clearly hate it Maybe because it's overlong, almost completely unrelated to the article, and might just be flamebait? But I'll toss in a few cents anyway. >Why can't I compile a Go program targeting a microcontroller with 2-8 MB of RAM without issue? Microcontroller toolchains are pretty controller-specific. It takes work to make things compile for them. There are other languages that fare better. Additionally, one of the more useful features of Go (concurrent goroutines) would simply be unavailable (and even with concurrency disabled, you still get unpredictable latencies from deciding which task should run when, the GC, etc). Just use C. >why can't I develop desktop GUI's in Go You can. https://github.com/andlabs/ui https://github.com/andlabs/ui is an example of how you can (and I'm sure it's not the only one.) >Why don't people make GUI stuff in Go? It's common to write apps using whatever the OS provides or using well-known libraries, so that's something Go's offerings don't offer. It's so much work already to build a GUI app that most people doing so probably don't want to concurrently write a GUI library too. I don't think there's anything stopping you, though. Next time, avoid writing so much to ask two (three?) simple questions. You come off as having an attitude when you use phrases like "Not going to edit the above", "knights in shining armor", and so on. You also build up and tear down many bales worth of strawmen, which is pointless. It would have been a better use of your time to actually look into either of those fields and discover the answers for yourself.
- logicallee 8y ago
  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

Rexxar 8y ago

I don't downvote you but ... No one hate your post. It's just an huge wall of text unrelated to the current post. It seems not the good place or the good moment to discuss this. You can maybe try to do an "Ask HN" for open question like this.

logicallee 8y ago
I think it's a great place to ask this. The most fantastic people to answer the question are going to be reading a post like this, and what we're reading about (adding a Go language server to core) is a huge and language-specialized feature for core. I look forward to reading people's answers to my questions. I thought the downvotes were because of something I got very wrong. Anyway I hope to learn from responses even if I got something wrong.

justinclift 8y ago

Didn't downvote your post above, so that wasn't me. That aside, there are some resources around for this though I've not (yet) tried any of them: * http://embd.kidoman.io http://embd.kidoman.io - Go Embedded Programming Framework. Seems to support Raspberry Pi and BeagleBone Black. * https://gobot.io https://gobot.io - Robotics more than embedded, but there seems like some overlap. :) --- With the "Why no desktop apps in Go?" question, for me it's because I'd only do so using something like Qt (cross platform). While there have been several attempts to get usable Go bindings happening for Qt, none of them seem both really well done + long term stable. The best developed Qt bindings so far are https://github.com/therecipe/qt https://github.com/therecipe/qt. But that seems to have tapered off and the developer doesn't seem interested in making it into a team project (eg long term viability). That's my impression anyway, I could be wrong. :)

striking 8y ago

>people clearly hate it Maybe because it's overlong, almost completely unrelated to the article, and might just be flamebait? But I'll toss in a few cents anyway. >Why can't I compile a Go program targeting a microcontroller with 2-8 MB of RAM without issue? Microcontroller toolchains are pretty controller-specific. It takes work to make things compile for them. There are other languages that fare better. Additionally, one of the more useful features of Go (concurrent goroutines) would simply be unavailable (and even with concurrency disabled, you still get unpredictable latencies from deciding which task should run when, the GC, etc). Just use C. >why can't I develop desktop GUI's in Go You can. https://github.com/andlabs/ui https://github.com/andlabs/ui is an example of how you can (and I'm sure it's not the only one.) >Why don't people make GUI stuff in Go? It's common to write apps using whatever the OS provides or using well-known libraries, so that's something Go's offerings don't offer. It's so much work already to build a GUI app that most people doing so probably don't want to concurrently write a GUI library too. I don't think there's anything stopping you, though. Next time, avoid writing so much to ask two (three?) simple questions. You come off as having an attitude when you use phrases like "Not going to edit the above", "knights in shining armor", and so on. You also build up and tear down many bales worth of strawmen, which is pointless. It would have been a better use of your time to actually look into either of those fields and discover the answers for yourself.

logicallee 8y ago
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