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.