[aws_ls]

The point is, it is broad. You gained by using it in a traditional case where earlier you would have used C.

But I've used it in the web app scenario. Replacing Java (jetty/tomcat servlets with pure Java code) with Golang. My own discovery was it could replace the jetty/tomcat with servlets part seamlessly, just with a bunch of http url handlers. I know it could be possible still more easily in other languages/stacks which are "zillion" times more productive.

Now, we all know that nothing comes free. For e.g. C++ templates cause compilation to take more time; have heard people complain about Ruby/ROR (including one on this page); I myself hated the Java configuration of the app servers, even in minimalist use of just a Servlet (the least needed for a web app thing), not to forget the SOAP-Servlets (Axis et al) before JSON ( good common sensical structure IMHO from the XML schemas/dtds (any one remember them?!)) became fashionable.

So the bloat/overhead can be in terms of useless jargon (e.g. the latter part of above para) which are too verbose and mean something very simple. Slowness e.g. Ruby/Rails. Or simply memory bloat (Which means more servers for the same amount of app processing capability).

So please do understand that there could be reasons other than "just can't get by without the iron hand of the compiler", where people use Go. :-)

People who have come to realize they wasted a decade chasing promises whether they were called OOP, EJBs, SOAP, XML, App Server, etc. Only to have been left with mysterious crashes because of "out of memory exceptions" (heck, jetty/tomcat are open source, but does any app developer should be debugging them. No, right? )

So there are also people disillusioned by the promises they fell for earlier. Who now prefer the minimalist approach. And actually very much appreciate when the wise people developing Golang, are hesitant to add a thing like Generics, despite the pressure from many quarters.

To summarize, why I use it:

Don't try to make it too easy for me, and pinch me at wrong times (when I start to get more users for e.g). Just Give me speed and give me transparency baby. I know how to make it work.

Edit: Typos and minor rephrase

[Mick-Jogger]

I'd love to hear more about replacing tomcat. Can you lead me to some info material on that topic. In our company we rely heavily on application servers, faster alternatives are always worth checking out.

[aws_ls]

Sure. Let me try to share some details. But before that, just want to make a point (which you surely know) that its also a major decision of a language change from Java to Go.

In the Tomcat/Jetty/<any other Java app server> world. If we want to have a web app (HTTP) we need to code servlets and add them into web.xml config, matching urls to Servlet Names. And within the Servlet we have coded, we need to call other Java code (the logic).

The container/app server takes care of the TCP/HTTP layers. Thread pools (which you can configure etc.).

Now in the Golang world. We just use the http package[1] for all that.

To listen to url:

  http.Handle("/doSearch", &MySearch{"MySearch"})

Where MySearch is a struct which just needs to implement the interface:

  func ServeHTTP( w http.ResponseWriter,r * http.Request)

Within this function you can put all the code which you will put in a java Servlet.

And to make this a service in your main package/program you will also do:

  err := http.ListenAndServe("localhost:10001", nil)

So these 3 pieces are the ones needed to have your own micro service or any web service running.

In our case, the similar functionality when moved resulted in lower memory usage and much higher stability (very less crashes, in the rare event of the service needing memory, which OS doesn't have. So the OS will kill that service anyhow - tech independent. We check using dmesg | grep <program name>)

Another benefit of this move, from our experience is getting rid of that webapp folder in any Java Servlet container. You will often end up plugging along multiple smaller apps, alongside your main one. And all reside in the same process.

That's not ample segregation, in our use. Its better you have different processes. So even if one dies, the others are independent.

This is also easier to manage. Deploy new ones - restarting just the ones changed.

Now we all know hot loading (without restart) is offered in several techs including some Java containers. But in practice, there always is some silly reason for you to restart. And sometimes the reason is psychological :-), we are not convinced that there is some baggage until we restart.

So hope my brief experience share is of some use. All the best.

Edit: Just want to add You must review this package page, if you are considering it

[1] https://golang.org/pkg/net/http/

[Mick-Jogger]

Thank you so much for the reply. I will definately try this out!