Increasing interest in the Go language

Later this month I'm joining a company that is fairly Go-intensive. They originally prototyped in Perl, but over time needed more performance but not to the level that would require assembler or even C. What else have folks observed? --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain

On Fri, Feb 02, 2018 at 09:14:24AM -0500, David Collier-Brown via talk wrote:
Later this month I'm joining a company that is fairly Go-intensive. They originally prototyped in Perl, but over time needed more performance but not to the level that would require assembler or even C.
What else have folks observed?
I think all the docker tools are written in go. Certainly seems to be getting some popularity in places. -- Len Sorensen

Go is becoming more and more common in the SysAdmin/SRE tools world. Kubernetes, GH-OST, and as mentioned by Lennart, many of the other docker tools are all in Go. It looks like a language that's going to be around for a while. On Fri, Feb 2, 2018 at 11:06 AM, Lennart Sorensen via talk <talk@gtalug.org> wrote:
On Fri, Feb 02, 2018 at 09:14:24AM -0500, David Collier-Brown via talk wrote:
Later this month I'm joining a company that is fairly Go-intensive. They originally prototyped in Perl, but over time needed more performance but not to the level that would require assembler or even C.
What else have folks observed?
I think all the docker tools are written in go.
Certainly seems to be getting some popularity in places.
-- Len Sorensen --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk

On Fri, Feb 2, 2018 at 9:14 AM, David Collier-Brown via talk < talk@gtalug.org> wrote:
Later this month I'm joining a company that is fairly Go-intensive. They originally prototyped in Perl, but over time needed more performance but not to the level that would require assembler or even C.
What else have folks observed?
I am using Hugo (https://gohugo.io/) - a static site generator written in Go - to create my blog, though I have no exposure to the language itself (yet). -- (o< .: Per curiositas ad astra .: http://www.circuidipity.com (/)_

| From: David Collier-Brown via talk <talk@gtalug.org> | | Later this month I'm joining a company that is fairly Go-intensive. They | originally prototyped in Perl, but over time needed more performance but not | to the level that would require assembler or even C. | | What else have folks observed? I'm sitting far on the sidelines. I've never used Go or Swift. From a distance, they look similar. Swift seems to have a lot of take-up in the iOS world. Anything else would be going against the grain. Swift has been released to the world, but I don't hear of it being used much outside of iOS (I might be deaf). I'm not sure why. I know that I don't trust Apple to leave anything open. Maybe the library is second-class outside of iOS. Go isn't supported as much as I'd expect by Google. For example, TensorFlow no longer supports Go -- Python all the way. I don't even know if Android SDK supports Go. The game of Go is all about capturing territory. I think programming language adoption has similarities. Google's AlphaGo is the best Go player in the world.

You should be comparing Swift (iOS) with Ketlin (Android). I'm leaning towards Ketlin, just I can't afford Apple. We'll see what Google will do with Go. -- William Park <opengeometry@yahoo.ca> On Fri, Feb 02, 2018 at 12:14:04PM -0500, D. Hugh Redelmeier via talk wrote:
| From: David Collier-Brown via talk <talk@gtalug.org> | | Later this month I'm joining a company that is fairly Go-intensive.� They | originally prototyped in Perl, but over time needed more performance but not | to the level that would require assembler or even C. | | What else have folks observed?
I'm sitting far on the sidelines. I've never used Go or Swift. From a distance, they look similar.
Swift seems to have a lot of take-up in the iOS world. Anything else would be going against the grain.
Swift has been released to the world, but I don't hear of it being used much outside of iOS (I might be deaf). I'm not sure why. I know that I don't trust Apple to leave anything open. Maybe the library is second-class outside of iOS.
Go isn't supported as much as I'd expect by Google. For example, TensorFlow no longer supports Go -- Python all the way. I don't even know if Android SDK supports Go.
The game of Go is all about capturing territory. I think programming language adoption has similarities. Google's AlphaGo is the best Go player in the world.
--- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk

On 2 February 2018 at 16:35, William Park via talk <talk@gtalug.org> wrote:
You should be comparing Swift (iOS) with Ketlin (Android). I'm leaning towards Ketlin, just I can't afford Apple. We'll see what Google will do with Go.
Seems to me that these represent somewhat different courses... Swift and Ketlin are primarily targeted at deploying frameworks for deploying mobile applications on iOS and Android devices. That's a meaningful set of purposes, but that's enormously different from the deployment of server applications. Go has gotten particularly popular for server application deployment in the form of the Docker infrastructure where the typical user of Docker has little reason to actually care what language Docker was written in, just that it works decently well. Myles' example upthread is a pretty good example of what Go is good at; in a page or two of code, he produced an application (that I observe does NOT have zillions of framework dependencies) that is reasonably terse, reasonably easy to understand even if you don't know Go, and which does a useful task without needing a huge amount of boilerplate code. The examples DCB has presented recently fit into the same category; it sounds to me like Go made it reasonably easy to build terse apps that didn't involve thousands of lines of references to framework dependencies and such. We've got some small projects getting deployed in Go at my work; I should probably consider redoing some things I wrote in C in Go, in the hopes that it's easier to deploy. (That said, the latest thing in C has actually served its purpose, and likely doesn't get run again :-( ) The other language that I'd find it interesting to compare, to this end, would be Rust. It has some "easy library inclusion" helpers, and a decent set of decently maintained libraries. I imagine that "cryptocoinmarketcap.rs" (Myles' app, in Rust) would be pretty near in size to the ~50 lines in Go and Python. I'll observe that Graydon Hoare, creator of Rust, is now working at Apple, on Swift. <https://github.com/graydon> So there's plenty of "full circle" to be found :-) -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"

I'd also comment on Rust being an interesting competitor to Go. Rust has better performance, complete statically determined safety (enforced by the type system), no garbage collection, minimal runtime, and an active group targeting WebAssembly (i.e. very high performance browser programs). It's what you should be programming in if you think you need C. Go has a simpler type system and good-enough performance for many applications. It might be what you should be programming in if you need a higher-performance Python (but with a lot fewer libraries). They both interop with C and C++; I think Rust has a richer set of libraries (crates they call them). I considered both for my comparative programming languages course. I went with Rust in the end because the other languages I talk about all have garbage collection, and I wanted the students to see how a sophisticated type system could give you performance as-good-as or better-than C and C++, along with safety. ../Dave

On 2018-02-03 10:28 AM, David Mason via talk wrote:
I'd also comment on Rust being an interesting competitor to Go.
Rust has better performance, complete statically determined safety (enforced by the type system), no garbage collection, minimal runtime, and an active group targeting WebAssembly (i.e. very high performance browser programs). It's what you should be programming in if you think you need C.
Go has a simpler type system and good-enough performance for many applications. It might be what you should be programming in if you need a higher-performance Python (but with a lot fewer libraries).
They both interop with C and C++; I think Rust has a richer set of libraries (crates they call them).
https://github.com/rust-unofficial/awesome-rust#cryptography is what scared me off Rust when I was looking at it for a personal project to do with TLS certificates a year or so ago. Specifically, the multitude of crates for something that's so easy to get wrong made me wary. Has the situation changed much in Rust crypto land? Cheers, Jamon

I'm not a crypto expert. (Hugh?) Most of the crates seem like they are either rust connectors to other systems (like OpenSSL) or use https://github.com/briansmith/ring (which follows BoringSSL, which is Google's fork of OpenSSL). On the other hand, the links suggests that ring is currently failing tests, so ??? What Rust brings to the table, besides safety and speed, is a type system that could give you a lot more confidence about the correctness of an algorithm (though I haven't looked at these crates to see if they are exploiting this potential). ../Dave On 3 February 2018 at 23:26, Jamon Camisso via talk <talk@gtalug.org> wrote:
On 2018-02-03 10:28 AM, David Mason via talk wrote:
I'd also comment on Rust being an interesting competitor to Go.
Rust has better performance, complete statically determined safety (enforced by the type system), no garbage collection, minimal runtime, and an active group targeting WebAssembly (i.e. very high performance browser programs). It's what you should be programming in if you think you need C.
Go has a simpler type system and good-enough performance for many applications. It might be what you should be programming in if you need a higher-performance Python (but with a lot fewer libraries).
They both interop with C and C++; I think Rust has a richer set of libraries (crates they call them).
https://github.com/rust-unofficial/awesome-rust#cryptography is what scared me off Rust when I was looking at it for a personal project to do with TLS certificates a year or so ago. Specifically, the multitude of crates for something that's so easy to get wrong made me wary.
Has the situation changed much in Rust crypto land?
Cheers, Jamon --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk

On 2018-02-02 09:14, David Collier-Brown via talk wrote:
Later this month I'm joining a company that is fairly Go-intensive. They originally prototyped in Perl, but over time needed more performance but not to the level that would require assembler or even C.
What else have folks observed?
I've migrated a couple of personal and work stuff from Python 2 to Go in the last three months. I've found that there is a larger third party library community now and the syntax isn't that foreign looking to me anymore, (see this Gist for an example, <https://gist.github.com/myles/a8ed889f4de1cde6be8be2640b34c89e>). Also that speed gain is hard to ignore. I wouldn't write a web application in Go but I would write a bunch of background tasks and use gopy[0] to integrate Python and Go together. [0]: <https://github.com/go-python/gopy>

On 02/02/18 13:16, Myles Braithwaite 👾 via talk wrote:
On 2018-02-02 09:14, David Collier-Brown via talk wrote:
Later this month I'm joining a company that is fairly Go-intensive. They originally prototyped in Perl, but over time needed more performance but not to the level that would require assembler or even C.
What else have folks observed?
I've migrated a couple of personal and work stuff from Python 2 to Go in the last three months.
I've found that there is a larger third party library community now and the syntax isn't that foreign looking to me anymore, (see this Gist for an example, <https://gist.github.com/myles/a8ed889f4de1cde6be8be2640b34c89e>).
Also that speed gain is hard to ignore.
You might like https://github.com/PuerkitoBio/goquery - makes it easy to do the usual jquery type: thing.Find(".class").Each(func... processing. Cheers, Jamon
participants (10)
-
Christopher Browne
-
D. Hugh Redelmeier
-
Daniel Wayne Armstrong
-
David Collier-Brown
-
David Mason
-
Jamon Camisso
-
Jason Shaw
-
lsorense@csclub.uwaterloo.ca
-
Myles Braithwaite 👾
-
William Park