Program your next server in Go • Hacker News Board

Re: Program your next server in Go

#191

Post by weberc2 » Tue, Jun 07, 2016, 9:35 PM UTC

inglor wrote: post #58

The slides are awesome and I really am fond of go, but the examples using channels are all more code to write considerably than I'd write in C# or JavaScript with async/await and not any more robust or safe. Go is great for actor based systems where you model things using channels and goroutines for what they stand conceptually - not when you use it to simulate Task.WhenAll/Promise.all with a timeout. I think _that's…

Yes, but in Go you don't have to deal with the [colored function problem][1], and the code to parallelize I/O is no different than the code to parallelize computations. I agree that these examples don't do justice to Go's concurrency facilities--the most compelling examples are probably too complex for a slide deck.

[1]: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

Re: Program your next server in Go

#192

Post by zZorgz » Tue, Jun 07, 2016, 9:36 PM UTC

I had a PHP program that processed HTTP requests and stored some data onto a local database, and decided I needed to rewrite it for various reasons so I decided to choose Go. Some points I recall:

* Static typing is good.

* As I expected, the standard library and other packages available had the http & routing stuff I needed, which is all good.

* I like that errors are specified in function signatures, unlike exceptions in languages like ruby/python.

* I don't like errors being easily ignored, and return values being assigned default or arbitrary values. I once may have also accidentally used the wrong equality operator against nil.

* Defer is nice, but would be better if it was based on current {} scope.

* Append on arrays? has very bizarre semantics sometimes mutating or returning a different reference.

* Initially I ran into trouble reasoning how to use some sql package and ran into "invalid memory" deference issues or some such when passing a reference. Thus, I'm skeptical about "memory safety."

This was only a simple program though and turned out to be worthwhile for me in the end.

Re: Program your next server in Go

#193

Post by Matthias247 » Tue, Jun 07, 2016, 9:40 PM UTC

The presentation focuses a lot on [web] servers and google scale, but I found that Go also works quite well for applications/services on embedded linux systems.

Main pros for me there are:

  - Easy to cross compile and deploy  
  - Daemons often need to do a lot of communication (some also for providing web APIs) and need to embrace concurrency. Both are covered very well by Go's ecosystem.  
  - Compile-to-binary eases distribution concerns in cases where you want to avoid to publish all source code (and thereby know-how) compared to VM languages or scripting languages.

Re: Program your next server in Go

#194

Post by weberc2 » Tue, Jun 07, 2016, 9:42 PM UTC

takeda wrote: post #185

weberc2 wrote: post #165

Earlier quoted context omitted.

Your analogy seems weak at best. Go is mostly a subset of Java, so there's almost no difficulty in a Java developer learning Go. A Java developer can immediately read 90% of Go programs, and within a couple of hours, he can write real, interesting programs. I'm not sure that a good analogy could be made incorporating English, nor do I think there's value in doing so.

I don't think you understood my analogy. Go supposed to be Toki Pona. I'm saying that once you are used to a language that's more powerful you feel constrained. I know many languages and some bring interesting things to the table, go doesn't really deliver (at least based on the hype). The concurrency supposed to be the killer feature, but it is limited to specific cases. BTW: The Go is not subset of Java if anything…

> I'm saying that once you are used to a language that's more powerful you feel constrained.

I did misunderstand your point, though I don't find this one more compelling. While Java has more features than Go, the only one I would consider to be "more powerful" would be generics.

> The concurrency supposed to be the killer feature, but it is limited to specific cases.

How do you figure? To which specific cases is it limited? How is Java better?

> BTW: The Go is not subset of Java if anything it's very similar to Algol-68

My argument wasn't that Go is most similar to Java; only that Go's featureset is almost a strict subset of Java's. Go gives you tighter control over memory and a better concurrency story, but most of the rest of it looks the same.

Re: Program your next server in Go

#195

Post by eropple » Tue, Jun 07, 2016, 9:43 PM UTC

weberc2 wrote: post #161

kmiroslav wrote: post #101

Earlier quoted context omitted.

> you have to first unlearn your existing ways of thinking and then you will have a place for it. Unlearning is not always acceptable, especially when you have to unlearn sound and proven practices, which Go often requires to do. I think it really depends where you're coming from: people coming from dynamically typed languages like Python and Ruby are quite happy with Go since it's a small ramp up on the type ladder,…

> especially when you have to unlearn sound and proven practices, which Go often requires to do. Such as? I'm not really sure what "sound and proven practices" a Java developer would have to "unlearn" to adopt Go. Most of the differences between Go and Java amount to removing features that 20 years of Java experience have proved to be unsound or unnecessary (inheritance and exceptions, for example). From a feature pe…

I'll say that Java doesn't do currency worse than Go, that's for sure. It has all of the primitives in whatever arrangement you want to put them (Javaflow and now Coroutines if you want go-I'm-sorry-coroutines, native threads if you want those, and Go channels can be implemented in maybe two dozen lines), more flexible, battle-tested abstractions (such as Akka offering you an asynchronous, message-passing actor model, which could be written in Go but seems in practice to be passed up in favor of channels), and tooling around these that I find to be head-and-shoulders better than anything Go has (like multi-threaded debugging).

I've basically (willingly or unwillingly) turned into a Ruby person over the last few years, as neither Go nor the JVM really have a ton to offer me right now, but I don't think a fair comparison of concurrency-related stuff, either in terms of tooling, libraries, or the language itself (I'd give Go this, except that you can't build an unbounded buffered channel and at that point the use of channels for what I write rapidly approaches zero), is nearly as clear as you assert.

Re: Program your next server in Go

#196

Post by eropple » Tue, Jun 07, 2016, 9:46 PM UTC

vertex-four wrote: post #186

kmiroslav wrote: post #142

Earlier quoted context omitted.

Again, we all agree about the motto. If you need to screw something and you have a choice between 1. A screwdriver 2. Electric drill A 3. Electric drill B you will certainly look funny at someone considering the screwdriver over the alternatives. Someone who automatically narrows this choice between the two electric drills is not "attached to their tools", as you say. They are just picking the better tool.

So as someone who's written some Go, I'd argue that Go is the screwdriver - it's one of the only modern languages which explicitly refuses to tackle the error handling problem, which has resulted in some of my code being more about the failure case than the success case. Of course, others will disagree - fine. But to argue that e.g. Java is definitely the screwdriver is a subjective judgement.

To add to this: Go's inexpressivity (hi, generics!) makes common patterns that I see in Kotlin, Java, and Scala (as well as Rust, off-JVM) makes error handling a complete bear, to the point where my eyebrows are really raised at vertex-four being downvoted for this.

The use of please-check-this error conditions instead of something like a Try (Result in Rust) and an inability to just map over these as 0- or 1-element collections is such a huge pain, and it certainly does matter when you're piling up multiple error-handling cases. Even more when you'd otherwise use Scala's `recover` to get back on a happy path. Go's inexpressivity directly impinges on one's ability to get things done.

(Food for thought: forgetting to handle the error case from Rust's Result is a compiler error. Is "if err != nil" really that good an idea in such a universe?)

Re: Program your next server in Go

#197

Post by jonathankoren » Tue, Jun 07, 2016, 9:47 PM UTC

the_common_man wrote: post #111

thom wrote: post #89

Holding up Perl and JavaScript as examples of languages that are 'fun for humans' makes it pretty clear I'm not the target market.

Can't speak for perl because I have only seen some horribly complicated code in it (which probably speak more of the author and not the language itself) but what's not fun about JavaScript ?

I used Perl for years, and it's still my go to language for quick text parsing. I stayed away from the bizzare "object oriented" syntax (They're not classes. They're packages, just called with arrow operators instead of like normal functions. But being Perl, you can just use the package and call the functions yourself because TMTOWTDI! (Blech.)) Also Perl's support (or at least Perl 5 (Does 6 even exist? It's like a unicorn like Duke Nukem Forever or Guns-n-Roses Chinese Democracy, only those eventually got released.)) for complex data structures (including multidimensional arrays) requires explicit reference instanteation and dereferencing, like C pointers. It's the biggest pain point.

Re: Program your next server in Go

#198

Post by im_down_w_otp » Tue, Jun 07, 2016, 9:50 PM UTC

davidw wrote: post #189

im_down_w_otp wrote: post #184

Earlier quoted context omitted.

I think compared to most FFI API's the NIF interface is extremely clean and straight forward.

See my other reply though: it's not just about the API, which is nice, but about getting the architecture right. It does make the system more robust, but it requires more thought and planning.

Sure. Once you cross that barrier, you now have unlimited ammo and all the feet that ever were or will be, so you have to be a lot more diligent about what you're doing.

Re: Program your next server in Go

#199

Post by mikecb » Tue, Jun 07, 2016, 9:50 PM UTC

justinsaccount wrote: post #56

> Lingo: Logs analysis in Go, migrated from Sawzall Would love to play around with this

As far as I could find not open sourced, but talked about at the data science blog (which is generally awesome): http://www.unofficialgoogledatascience.com/2015/12/replacing...

Re: Program your next server in Go

#200

Post by IndianAstronaut » Tue, Jun 07, 2016, 9:52 PM UTC

fpgaminer wrote: post #49

All of the server backends at my company are written in Go. This was a result of me writing a couple servers in Python a few years back, ending up with lots of problems related to hanging connections, timeouts, etc. I tried a couple different server libraries on Python but they all seemed to struggle with even tiny loads. Not sure what was up with that, but ultimately I gave Go a swing, having heard that it was good…

Another major issue I have had with Go is database connectivity. The db drivers are really lackijg for Go. Makes it tough for those of us who use Teradata or Hive.