Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Program your next server in Go

talks.golang.org

Post reply on HN
Print view View original

121–130 of 384 posts

Re: Program your next server in Go

#121

Post by rdtsc »

yanilkr wrote: post #106
kmiroslav wrote: post #97

Earlier quoted context omitted.

That's odd. I think the absence of generics in Go is a reasonable answer for a JVM developer to justify they are not interested. No need to go petty.

This feeds into language supremacy mindset. There is no universal best language nor there will ever be the one. Right tool for the job is a better flexible mindset. If you are a master painter, you could paint something amazing with anything you have got. Same thing applies to programmers.

> There is no universal best language nor there will ever be the one.

But there are better languages for some task than others.

Having a better type systems suites many types of tasks and environments. So making that observation seems rather rational.

Re: Program your next server in Go

#122

Post by akavlie »

chrisbroadfoot wrote: post #116
akavlie wrote: post #110

Earlier quoted context omitted.

You're arguing that it's good to (intentionally) break with common code idioms for certain classes of libraries?? Also, have you actually seen the auto-generated APIs he's referring to? Here are the Godocs for the BigQuery API: https://godoc.org/google.golang.org/api/bigquery/v2 Here's some example code demonstrating the API's bad habits -- such as deeply nested struct pointers, and Do() methods everywhere: https://g…

Here's the idiomatic library for bigquery: https://godoc.org/google.golang.org/cloud/bigquery

Thanks for that link, looks like that API was created after I started the project using BigQuery.

It's still labeled "experimental" though, which makes me a bit wary to use it just yet.

Re: Program your next server in Go

#123

Post by chrisbroadfoot »

akavlie wrote: post #122
chrisbroadfoot wrote: post #116

Earlier quoted context omitted.

Here's the idiomatic library for bigquery: https://godoc.org/google.golang.org/cloud/bigquery

Thanks for that link, looks like that API was created after I started the project using BigQuery. It's still labeled "experimental" though, which makes me a bit wary to use it just yet.

That's right. It's production-quality, but the API surface might change.

If you're OK with changing your code sometime in the future, then I'd recommend giving it a try for this or your next project. Changes will likely be minimal.

Re: Program your next server in Go

#124

Post by baby »

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 ?

especially with React Native, NodeJS and Electron... you can pretty much write anything you want, easily, that will run on a bunch of platform. I still prefer Python/Ruby/Perl... over JS. But I would pick JS anytime over Java.

Re: Program your next server in Go

#125

Post by rom16384 »

tokenizerrr wrote: post #6

What about debugging? This is the major pain point for me. I've tried using GDB, but... > GDB does not understand Go programs well. The stack management, threading, and runtime contain aspects that differ enough from the execution model GDB expects that they can confuse the debugger, even when the program is compiled with gccgo. As a consequence, although GDB can be useful in some situations, it is not a reliable deb…

I've found godebug [1] useful. It's pretty basic, but has 90% of what I need.

[1] https://github.com/mailgun/godebug

Re: Program your next server in Go

#126

Post by Cyph0n »

MustardTiger wrote: post #55
nimmer wrote: post #31

I'd love to see Nim on this diagram: https://talks.golang.org/2016/applicative.slide#13 - it could be close to the top right corner.

The go devs are very careful to avoid mention of all the other languages that compete in the same space and are significantly better.

Good point, but in the end it's a subjective graph.

Re: Program your next server in Go

#127

Post by nvarsj »

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…

> Dependency management is a nightmare

Is it that bad now in 1.6 with vendor support? And a tool like `govendor` makes it easy to stick things inside of vendor.

> it just really surprises me how little Google seems to care about the language and ecosystem

To be blunt, google's priority is google, not the open source community or other companies using golang. Dependency management wasn't a priority because of mono repo. Having said that, they are pretty good about improving things for everyone, but it will never be like a company such as Typesafe whose product is the language and tooling itself.

Re: Program your next server in Go

#128

Post by moron4hire »

I've been experimenting with this concept with C# recently [0], where I have a small backend written in C#, exposing a simple, RESTful HTTP server, that automatically finds itself a local port to run on and opens the default browser to a default page.

It's actually kind of nice. Until I did this the first time, I hadn't realized just how much bullshit I had previously put up with, with setting up local web servers, trying to get configurations down, etc., etc. At some point, I think most web framework's configuration options just got too complex to be considered configuration options and became weird, poorly defined scripting languages for defining web servers. Having a real programming language to do that instead is just a wonderfully smooth experience.

Some things I plan on implementing with it:

* local file system access, to ultimately implement an FSN [1] clone in my WebVR project.

* my own Leap Motion WebSocket service, because the default one doesn't use the latest Orion beta and its associate JS library is complete garbage.

* A similar dude for MS Kinect data.

* Ultimately, get the previous two to run over WebRTC instead (not easy, there is no WebRTC library for Windows outside of major browser implementations) to be able to stream their respective camera data.

* Live raytracing of model textures for baked lighting in scenes in the WebVR session.

Right now, it's just a source file I drop into a standard C# console project. I'm thinking about making it a full-on library, though at this point there isn't much need.

[0] https://github.com/capnmidnight/HereTTP

[1] https://en.wikipedia.org/wiki/Fsn

Re: Program your next server in Go

#129

Post by shurcooL »

I like slide 41 [0].

    What just happened?
    
    In just a few simple transformations we used Go's concurrency primitives
    to convert a

    - slow
    - sequential
    - failure-sensitive

    program into one that is

    - fast
    - concurrent
    - replicated
    - robust.

    No locks. No condition variables. No futures. No callbacks.
It's the ability to make these kind of transformations effortlessly at any level, whenever I need to, that make me appreciate choosing Go when solving many tasks.

[0] https://talks.golang.org/2016/applicative.slide#41

Re: Program your next server in Go

#130

Post by eternalban »

spriggan3 wrote: post #54
avitzurel wrote: post #2

I love Go. It has become the default Go-To (pun intended) language for me for almost anything that needs to be small and portable. However, I don't see myself writing a full server with it, I would still prefer a dynamic language like Ruby/Python for that and use Go for micro-services CLIs and the rest. For example: Our main application is Rails, it communicates with SOLR as the search index, in between the applicati…

Go type rigidity makes Go code tedious to write. Instead of thinking "How can we solve that problem" developers writing Go end up thinking "How can we make the problem fit Go type system". I'm not even talking about concurrency here, I'm talking about Types. Saying otherwise would be dishonest, unless one has never used anything but C... Anybody who doesn't believe me just has to look the reflect package. Reflection…

All languages require investment. Zero sum game, with some opting for syntactic simplicity that entails a long term investment of "idioms", subtle semantics, post-processing, etc., and others present a high initial investment and subsequent clarity, regularity, and possibly robustness. C/Go/Java/C# are in the former category. Scala, Haskell, Rust, for the latter.

(C++ uniquely bites you at both ends :)

Post reply on HN