golang?

[richrarobi]

If anyone has an interest in trying the go language, the following links should help.
http://dave.cheney.net/unofficial-arm-tarballs
http://golang.org/doc/install

I thought there might be some interest? Anyone out there?

Looking for a language that will 'do what I want' without too much angst..... go (language) is now at day 2 on my pi and looking good (scala lost me at AKKA It suddenly became a mountain to climb). (Currently running go on Linux mint (32 and 64 bit) and a pi2) - Not found a good simple enough ide yet, although Geany shows some promise. Hardest part so far was setting up the go workplace directory structure (my understanding vs their very slightly confusing instructions)

RichR

[ajstarks]

I've been doing Go on the Pi for a while. The idea is to simply treat it like any other Linux box. In general, things, including third-party libraries "just work". In terms of setup, I usually build from source, and follow the usual conventions -- be sure to set up your GOPATH, and you will be good to "go".

Also, there is the OpenVG library [1] and Deck [2, 3, 4] tools that run on the Pi.

[1] https://github.com/ajstarks/openvg
[2] https://github.com/ajstarks/deck
[2] https://github.com/ajstarks/deck/tree/master/cmd/vgdeck
[4] https://speakerdeck.com/ajstarks/deck-a ... sentations

[Heater]

I really like the idea of the Go language.

Problem was that when I compared it's performance against JavaScript running under node.js the JavaScript won!

Any bench mark is to be taken with a grain of salt. At the end of the day you have to test with your application. This case was a simple socket server pumping data from client to client.

The issue seemed to be in the memory management, the garbage collector, causing things to stutter and stall a lot.

[richrarobi]

I was getting on OK with GO until I hit interfaces. While GO was, up to that point, a simpler language (especially compared to ruby/jruby where there are multiple ways to do things) I found that interfaces were so weird to get to grips with, I eventually gave up (it failed at that point in my search for a pleasurable programming experience that would do the job I want. (As did SCALA at ACCA and actors!)

RichR
p.s. back to Jruby!! Threads work (in JVM) and are understandable, classes (and subclasses) are logical !! Jruby gives you the power of Java with more readable code (so far anyway.)

[ejolson]

Hardest part so far was setting up the go workplace directory structure (my understanding vs their very slightly confusing instructions)

I installed Google Go as root on Raspbian by typing

# apt-get install golang

Then as a regular user I can compile a program with

$ go build fft.go

This created an executable that I can run with

$ ./fft

So there is no need to setup any IDEs or complicated build directories unless you want to.

For my test program I found that the executables produced by the Google Go compiler ran about 3 times slower than equivalent C code compiled with GCC version 5.1.

[natdm]

I thought Go was supposed to be faster than C? Maybe I never really read that and just thought it was supposed to be.

[Heater]

I see no reason, in theory at least, why Go would be any faster or slower than C. Nor have I read any claims that it might be. You are just taking a bunch of similar looking statements and compiling them to similar native code after all.

Practically I would guess that the Go compiler being much younger than GCC and other C compilers may not have such finely tuned optimisers. But that is something that could improve with time.

Where performance may be an issue is with the garbage collector built into Go. But if you are using malloc/free in C or new/delete in C++ you may have similar hiccups.

I should revisit Go and see if performance has improved over my last experiments so years ago.

[TheGameSquid]

If you plan on using Go, you might want to have a look at Gobot! I haven't used it myself, but it's next on my list of things to try out. The Gobot framework runs on a BUNCH of platforms (AR Drones, Arduino, etc.), the RPi is only one of them. It looks pretty nice and consolidated, so no use for using a GPIO lib and a Firmata lib for example. It's all in the same framework here.

The guys that put this together also have two sister projects:

1. CylonJS - JS framework (for even more platforms)
2. Artoo - Ruby framework

All of them also integrate super-nicely with the Commander app.

I think any discussions concerning Go are pretty ridiculous IMO. It's true that Go has had some GC problems that have been pretty show-stopping for very specific types of software. For example, the GC is way too rough for developing games for example (at least so far as I know, I haven't actually picked up 1.5+ and the new GC improvements yet) because it's very "STOP AND SWEEP"-like.

Apart from that, Go is now being used for heavy-duty lifting in datacenters around the world, thanks in large part to the work of the Docker team and the various awesome tools by Hashicorp / Mitchell Hashimoto. I'm pretty sure it's more than capable enough to handle your RPi application, unless you're doing some really outlandish stuff.

Also, I have no background in systems programming (C/C++, no thanks!), but I found most of the Golang concepts to be quite easy to grasp. In fact, Go was designed from the ground up to be simple. That doesn't mean it's an EASY language, but the syntax has been kept deliberately easy to read and very restricted. Likewise, concepts like interfaces were designed to be very simple. As such, it does NOT support inheritance for example. I think that's a very wise choice, but maybe that's what confused you? Remember, it's a language designed mostly to replace C/C++ as a systems programming language, and all the three of the main language designers have been outspoken about their dislike of the complexity of the C/C++ language itself. Making thing NOT COMPLEX is a design goal for Go.

Lastly, here's a tiny free book on Go that I really enjoyed reading recently: http://openmymind.net/The-Little-Go-Book/

[Heater]

TheGameSquid,

That's a pretty long post considering "I think any discussions concerning Go are pretty ridiculous IMO."

I like the idea that Go is kept simple, Certainly the complexity of C++ is absurd, I don't believe there is any one single person who understands all of C++'s features and how they interact with each other, including Bjarne Stroustrup judging by some C++ conversations I have seen on YouTube.

I'm totally with Go's processes and channels. A brilliant idea from CSP (Tony Hoare) as seen in the old OCCAM and now XC language used by XMOS.

The show stopper for me at the time was the garbage collection stutters and poor performance in the particular task I wanted to use it for. Also, reading around, it seemed the GC was buggy on 32 bit systems.

As I said, it's probably time I revisited Go and see what has improved.

[TheGameSquid]

That's a pretty long post considering "I think any discussions concerning Go are pretty ridiculous IMO."

Sorry about that, pretty typical for me. I don't know when to shut up .

The show stopper for me at the time was the garbage collection stutters and poor performance in the particular task I wanted to use it for.

And that case you really should check out 1.5+. They've made some of the biggest GC improvements yet there, especially with regards to "stuttering" behaviour. Here's Rick Hudson giving a talk about the GC improvements at Gophercon 2015. I thought it was a nice overview of what they're trying to achieve, and it doesn't try to hide the compromises they made, etc.

[Heater]

Excellent news, thanks. You may have kicked me into getting going again:)

[ejolson]

They've made some of the biggest GC improvements yet there, especially with regards to "stuttering" behaviour. Here's Rick Hudson giving a talk about the GC improvements at Gophercon 2015.

The improvements to the garbage collector described by Rick Hudson in the talk that was linked to above appear very significant.

I thought Go was supposed to be faster than C?

For my FFT it appears much of the slowdown was due to mandatory bounds checking on array slices. A syntactically complicated way to avoid the bounds checking using "unsafe pointers" was discussed on the golang forum

https://groups.google.com/forum/#!profi ... mqSyy4gFEJ

and improved performance by 30% which brought performance to within a factor 2 of the Cilk parallel C code. The remaining differences are likely due to greater overhead for dynamic memory allocations and poorer sequencing of floating point instructions.

[Normang]

This video presents a simple way to install the latest version of golang.
https://www.youtube.com/watch?v=gVhMYRaKGXU

I installed version 1.91 this way and it's working well. This talk explains the improvements.
https://youtu.be/uTMvKVma5ms

[jahboater]

Where performance may be an issue is with the garbage collector built into Go. But if you are using malloc/free in C or new/delete in C++ you may have similar hiccups.

I think the difference is that malloc/free are called when the programmer wants them to be called, and commonly for a single item only.

The reason (in the past anyway) why systems programming languages didn't employ automatic garbage collection was because it could happen at any indeterminate time, and (unlike malloc/free where the programmer knows exactly what needs to be free'd) the GC has to scan the entire heap arena looking for unreferenced blocks - a hideously expensive exercise, probably O(n^2) or worse. For each block it finds in the heap it must scan all of memory, or maintain reference counts and constantly keep track of all pointers to the memory blocks and so on.... I'll stick with C

[fkirill]

Well, let me express my opinions on a bunch of the above posts

* GoLang cannot in theory be faster than C/C++ due to the language/standard library features like automatic memory management, dynamic coroutine scheduling etc.
* Nowadays garbage collection performance shouldn't be a big problem anyway
* If your'e writing application for real-time processing, depending on how latency-sensitive you are, Go might not be the best choice
* Don't use unsafe, it defies the whole purpose, choose appropriate language (like C) that doesn't impose the limits you are trying to avoid
* Overall, when working with sensors and external world, this stuff is SLOWWWWW. Don't try to optimize execution time in places that are not the bottleneck anyway, the communication with external world (network, devices, sensors IS the bottleneck). You're trying to optimize like 0.1% of the fastest part of the program, it's a bit pointless.
* Don't try to use AKKA. While it's advertised as a holy graal of async computing, it is certainly not. Also it's not a good entry-level work by any standard, if you consider using AKKA on devices, make sure you are being paid to do specifically that. As a side note, only use AKKA if your application model ideally fits hierarchical actors model (which is a very niche area, not generic at all), any mismatch in application model.with hierarchy will lead to enormous pain without any clear benefits. Also debugging AKKA programs is just insane. if you use distribution aspect of it, it's not resilient to failure and fails completely if any node goes down, etc., etc., etc... Just don't use it.
* GoBot looks interesting however it is a MAJOR abstraction from the actual GoLang runtime library. The benefit is that it's compatible with multiple platforms, the downside is that it is inevitable has to have a common denominator aspect to it and not expose the features that you need. But if you fit into their model, it might be a very good portability help
* GoLang interfaces are good, but you need to understand them properly. Yes, true, they are fundamentally different from the interfaces in Java or C++, however, understood properly they are very powerful abstraction primitives.
* Comparing malloc/free and garbage collection side by side from performance perspective is a bit pointless. You need to take into consideration your allocation throughput, proportion of small vs large allocations, length of allocation, cost of maintaining the memory management code, memory leaks per 1000 lines of code, etc. On the other side you need to consider which malloc library do you use (there a lot of different implementations here too). IBM carried out a research 15 years ago or so, that the $$$ cost of one line of code in Java vs C++ is that Java is approx. 10x cheaper. This includes debugging, memory management issues etc. The idea is that *just* comparing garbage-collected vs. manually allocated resources is pointless.

[richrarobi]

After trying Rust, and finding it too "tight", I went back to golang. While I admit I am still learning, I find it fits my way of working. The authors have done a lot of work to make the programmer's life easier. Also I find it is "fast enough" and appears much faster than Python (not a challenge)

Someone might be interested in my code for using nanomsg (Mangos) to talk (req/ reply message) between various pi's and PC's using go https://github.com/richrarobi/mangolink - so far to access things like system type, cpu temperature, and to drive Pimoroni Blinkt's.

The Go periph library is worth a look for driving GPIO's

[Heater]

fkirill,

* GoLang cannot in theory be faster than C/C++ due to the language/standard library features like automatic memory management, dynamic coroutine scheduling etc.

I know what you mean. One can write C++ code that uses no threads or dynamic memory allocation. In fact I have compiled such C++ code and found it produces, instruction for instruction, the same binary as the C equivalent functionality. Even if it involves classes and templates etc.

However, a large, non-trivial application will use threads and dynamic memory allocation. At that point whatever overheads are built into Go the language to handle all that become equivalent to what people do in C++ anyway.

So then the question is, which language is the easiest to use to create such programs?

C++ is a disaster in that respect.

But still, I'm a C/C++ guy. If only because it has proper standardization and is the most cross-platform language we have so far.

[richrarobi]

So then the question is, which language is the easiest to use to create such programs?

I just added an example Python in my mangolink post on github. It shows Python calling the reply server (mangorep.go) and receiving a response.

Now (call me Barmy?), I can run my reply code on any system Linux Mint or RasPi, and call it from any system using golang OR Python, or anything else that is supported by nanomsg and json.
(These may not be the most efficient communication tools, they are just what I have used here)

Someone could write a super efficient reply server using (um) Erlang, or whatever?

So my proposal (?) is that with this we can use any language that is most efficient or easier , wherever it applies, and run code where it works best.

[truthadjustr]

One of Golang's designer is Ken Thompson. He is one of the creator of Unix and have worked very closely with Dennis Ritchie during his time. The Linux kernel is written in C and therefore a testament to what C does best. Docker is written in Go, and also is a testament to Go. .. Perhaps, the killer-app for C++ is still coming ?

[hedbonker]

Ken hated C++. He wrote Unix in assy then developed C with Ritchie and then re-wrote Unix in C.

[Heater]

truthadjustr,

Perhaps, the killer-app for C++ is still coming ?

What?!

You mean none of the thousands of games out today are "killer apps" for C++?

Microsoft Word, Excel and perhaps most of their products are not killer apps for C++?

The Chrome browser, and hence the V8 Javascript engine and hence node.js and Electron and MS Visual Studio Code are not killer apps for C++?

What about the Mars rover software? Joint Strike Fighter software?

So much that we use everyday is written in C++.

I think one of the biggest killer apps for C++ is LLVM. That is not only the bases for the Clang C++ compiler but serves as the basis for many other language compilers: Including: ActionScript, Ada, C#, Common Lisp, Crystal, CUDA, D, Delphi, Fortran, Graphical G Programming Language, Halide, Haskell, Java bytecode, Julia, Kotlin, Lua, Objective-C, OpenGL Shading Language, Pony, Python, R, Ruby, Rust, Scala, Swift, and Xojo.

Imagine that, whatever your favorite language it might be built with LLVM, hence dependent on C++!

For me the killer app for Go is CockroachDB, a distributed, scalable, fault tolerant, ACID compliant SQL data base. Wonderful.
https://www.cockroachlabs.com

[ejolson]

truthadjustr,

Perhaps, the killer-app for C++ is still coming ?

Joint Strike Fighter software?

So much that we use everyday is written in C++.

That does sound like a killer app. Do you use it everyday?

The main problem with Go, in my opinion, is that it is still difficult to write using EBCDIC encoded punch cards due to all the braces.

I heard that D will soon be among the languages supported by the GNU compiler collection. From what I can tell D and Go have similarities: Both were designed for solving similar problems by very small teams of developers with significant experience in compilers. I wonder which works best on the Pi.

[Heater]

ejolson,

That does sound like a killer app. Do you use it everyday?

Nah, I cancelled my order, damn thing was getting too expensive and never worked properly anyway.

Some years ago I experimented with recreating one of our little server side processes in Go. It only had to read some real-time streams of XML, do some filtering on them and route the steams to appropriate places. Turned out to be very latency inducing, stuttering and stammering all the time. Not nice for our live data visualizations. Surprisingly it turned out that my Javascript/node.js version of the same experiment was almost as fast, a lot smother and a lot easier to write. Since then we used a lot of node.js.

Investigation turned up the suggestion that the garbage collection in Go was not so hot and it really needed 64 bit machines, we only had 32 bit servers at the time. Perhaps the situation is better now a days. My favorite database is, CockroachDB, is written in Go and seems to be pretty speedy. But Cockroach won't even build on 32 bit machines...