Can golang be used for creating a client side application (system level)

[ksrang...@gmail.com]

Hi

I'm at verge of choosing the programming language to create a client side application on Linux platform, which needs to perform the following functions :

1. Collect the details of the hardware & software in the system. (Maybe using Terminal commands)

2. Send these info to a server using HTTP, as XML & JSON, when it changes.

3. Have a long lived connection which listens to the server, using TCP.

4. Run a service (daemon) at the background the whole time.

5. Periodically Connect Server using HTTP and Get data as XML/JSON

After a bit of analysis, I am confused as to which would be better, Python or GO.

Would love to incline towards GO. But, am a little circumspect, considering the fact that there is a lot of mention about GO as server side language. And, very little (if any) about GO as a client side language.

Are there any client side applications developed using go ? Is it possible to use GO for the above mentioned functions ?

Please advice.

Thanks in advance.

Rangaraj

[Konstantin Khomoutov]

On Mon, 12 May 2014 06:14:20 -0700 (PDT)
ksrang...@gmail.com wrote:

> I'm at verge of choosing the programming language to create a client
> side application on Linux platform, which needs to perform the
> following functions :
>
> 1. Collect the details of the hardware & software in the system.
> (Maybe using Terminal commands)
> 2. Send these info to a server using HTTP, as XML & JSON, when it
> changes.
> 3. Have a long lived connection which listens to the server, using
> TCP.
> 4. Run a service (daemon) at the background the whole time.
> 5. Periodically Connect Server using HTTP and Get data as XML/JSON

Yes.

> After a bit of analysis, I am confused as to which would be better,

> *Python or GO*.

The better would be the one you (your team) are familiar with.
That's not a dogma though; if you have a time to invest in making
yourself familiar with Go, disregard what I said.

> Would love to incline towards GO. But, am a little circumspect,
> considering the fact that there is a lot of mention about GO as
> server side language. And, very little (if any) about GO as a client
> side language.

Go was envisioned as a systems programming language. That is,
a language to do things people routinely do using C++ or even C,
but more up-to-date with recent reality and having a "scripting feeling"
to it.

The fact there's so many mentions of Go with regard to server-side web
programming stems simply from the fact there are way more web
programmers than systems programmers, and the former are easily sold on
"the next big things", amplifying any effect from the introduction of
the new language/technology in their field (which is contrary to the
systems programming niche where people are more conservative and
technologies more entrenched). Go's excellent standard library has
most of the tools to write HTTP servers, and there's a wide variety of
helper 3rd-party libraries providing higher-level tools for this task;
all this contributed to Go's rise as a HTTP server-side platform but
surely this does not limit its abilities to work in other fields.
For instance, I personally wrote a range of in-house tools in Go, and
neither of them is a web server/service.

[Benjamin Measures]

On Monday, 12 May 2014 14:14:20 UTC+1, ksrang...@gmail.com wrote:

Would love to incline towards GO. But, am a little circumspect, considering the fact that there is a lot of mention about GO as server side language. And, very little (if any) about GO as a client side language.

Go is positioned as a systems language: http://golang.org/doc/faq#What_is_the_purpose_of_the_project

It can be used for both sides of a client/server relationship. Indeed, it is not unusual for servers to make connections as clients, or for clients to accept connections for service, so the distinction is not so black and white.

Where the distinction may matter is in the context of web-development, where "client-side" usually means "runs in a browser". Go doesn't do this (yet).

[Shawn Milochik]

I'm primarily a Python guy. I'm very new to Go (about two months in).

I say go with Go for one simple reason: deployment. 

These things are big problems for deploying with Python:

1. Having to ensure that the host system has the correct version of Python.

2. Ensuring the correct Python packages are installed (possibly through pip or the system package manager).

3. Ensuring source packages from the OS's package manager are installed required for any of the Python dependencies to compile.

If you have full control over each client machine then it just becomes an annoyance and not really a problem.

Go is a good general-purpose language. It's good for creating services, but that doesn't in any way imply it's not good for "client" applications.

[egon]

On Monday, May 12, 2014 4:14:20 PM UTC+3, ksrang...@gmail.com wrote:

Hi

I'm at verge of choosing the programming language to create a client side application on Linux platform, which needs to perform the following functions :

1. Collect the details of the hardware & software in the system. (Maybe using Terminal commands)

2. Send these info to a server using HTTP, as XML & JSON, when it changes.

3. Have a long lived connection which listens to the server, using TCP.

4. Run a service (daemon) at the background the whole time.

5. Periodically Connect Server using HTTP and Get data as XML/JSON

 

For those kinds of stuff it's quite nice.

 

After a bit of analysis, I am confused as to which would be better, Python or GO.

Would love to incline towards GO. But, am a little circumspect, considering the fact that there is a lot of mention about GO as server side language. And, very little (if any) about GO as a client side language.

Are there any client side applications developed using go ? Is it possible to use GO for the above mentioned functions ?

Currently, the only thing that Go doesn't do nicely is Native UI; for everything else it's really nice. (It can be done, but the configuration/set-up is pain). Of course, if you need to integrate with some lesser known weird protocols and you don't have time to implement yourself, then some other languages might be preferable.

+ egon

[ksrang...@gmail.com]

Thanks a lot, guys..

It has increased my confidence in proceeding with GO..

[Péter Szilágyi]

Hi,

  Just to add to the previous comments. Before switching to Go, I've used various languages for various tasks - among others - C++, Java, Python and Erlang. My projects included patent analyzers, web crawlers, hosting platforms, heck, even positioning the solar panels of the ISS. After about 1.5 years with Go - writing a dotScale finalist cloud messaging system, pwning at international algorithm contests, currently being a scoreboard leader at a data mining match - I can confidently say that Go unequivocally shames all other languages.

  Of course, as everything else, Go has its weaknesses, where its better to use different tools. Currently I have three such scenarios that I've come across, where I'd pick something else:

• Client side graphical user interfaces. Somehow Go was never meant as a GUI language. Its core design concepts are different, its event and/or synchronicity model and mechanisms are different than what's generally used in GUIs. Eventually Go will - as all others - gain some support for designing and implementing GUIs, but I don't think it will ever be a real competitor in this area (take it with a grain of salt).
• Web apps. Go is perfect for serving stuff to web applications as a backend service. I have used it in such a manner as a decentralized RESTful component of my mapping service. It is however - yet at least - not really useful as a (supporting pillar of a) web app front-end. There are various web-app containers and frameworks in Java for example, but those require enormous amounts of work, and Go has not gained a foothold yet in those areas. Or Dart is also a potential contender in this area.
• Short scripts. Although Go is very powerful and generic, it does have a minimal amount of boilerplate and associated effort required. Unless you exceed a certain level of complexity, a scripting language will be a better option (i.e. bash, python).

  For your particular use case however, I would say Go is a match made in heaven :) Hope it was helpful.

Cheers,

  Peter

On Tue, May 13, 2014 at 12:59 PM, <ksrang...@gmail.com> wrote:

Thanks a lot, guys..

It has increased my confidence in proceeding with GO..

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ksrang...@gmail.com]

 

For your particular use case however, I would say Go is a match made in heaven :) Hope it was helpful.

Indeed it was very helpful, Peter. Thank you..

 Go has its weaknesses, where its better to use different tools. Currently I have three such scenarios that I've come across, where I'd pick something else:

• Client side graphical user interfaces. Somehow Go was never meant as a GUI language. Its core design concepts are different, its event and/or synchronicity model and mechanisms are different than what's generally used in GUIs. Eventually Go will - as all others - gain some support for designing and implementing GUIs, but I don't think it will ever be a real competitor in this area (take it with a grain of salt).
  

But, just for the sake of General Knowledge, have a doubt as to why you say it has shortcomings in Client side GUI. I was skimming through the list of 3rd party libraries offered to aid GO, and, found "go-gtk" & "wxGo" in addition to a whole lot more. Aren't they enough ? Or I'm I wrong in assuming that ? 

Rangaraj

[Dobrosław Żybort]

You should definitely check `qml` package:
http://godoc.org/gopkg.in/qml.v0

Some examples:
http://blog.labix.org/2014/04/25/qml-contest-results

[Péter Szilágyi]

Indeed, I've forgotten about Gustavo's qml package. All in all I've never tried to do GUI in Go, but as a matter of fact I try to steer as far away from any kind of GUI as I can. That is why I wrote to take the GUI part with a grain of salt :)