Live data from Hacker News

Program your next server in Go

talks.golang.org

111–120 of 384 posts

Re: Program your next server in Go

#111
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 ?

Re: Program your next server in Go

#112
post #41

I once tried to convince an enterprise java developer to give golang a try. The guy passionately hated it and the reasons were very very petty. The other younger engineers who did not have prior bias loved golang and they were productive so fast. The person truly had a java supremacy attitude that was very difficult to deal with. Golang is a kind of shift in thinking that you have to first unlearn your existing ways…

> 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,…

The good programmers I know are not attached to their tools. They prefer to use the right tool for the job. Many other programmers want to solve the problems using tools they know. There is nothing wrong with that. A company with good programmers who could do similar things more efficiently will add to competitive advantage.

Re: Program your next server in Go

#113

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…

> Google itself doesn't actually have any real API libraries for their cloud services.

We're (I'm one of the contributors) working on them.

Check them out here: https://github.com/GoogleCloudPlatform/gcloud-golang

Datastore docs: http://godoc.org/google.golang.org/cloud/datastore

Re: Program your next server in Go

#114

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…

Slide 13 (https://talks.golang.org/2016/applicative.slide#13) is interesting. I was expecting Go to be very close to C/C++ on the X axis (fast/efficient) as it doesn't use VM, but it is more close to Java ?

Re: Program your next server in Go

#115
post #62

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…

To be fair, Go's GC got A LOT better over the past few versions and it's getting much better still. What I would really like to be able to do though is be able to write unmanaged blocks when I need them and know better than the compiler rather than having to "run my own heap" on top of a buffer like I typically have to do in managed languages that don't have that opt out.

Crystal might be worth checking out if you have that kind of need.

Re: Program your next server in Go

#116

Earlier quoted context omitted.

> They autogenerate all API libraries for golang, which means they're not idiomatic, are convoluted to use, and the documentation is a jungle. Are idiomatic API libraries really a good thing? If an API is used heavily throughout your application, doesn't that mean it's time to wrap that part of the API in some idiomatic wrapper code that is meaningful in your domain? Functions are idiomatic in all languages. Personal…

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

Re: Program your next server in Go

#117
post #50
post #32

Earlier quoted context omitted.

Absolutely. It's unfortunate that Nim is relatively unknown - here's hoping it gets a large backer sometime soon to boost its popularity! I'd also add D (above C++, level with Java) and Rust (above C++, close to Go).

And Crystal ( http://crystal-lang.org/ ).

Definitely, but isn't Crystal still in its early stages? I heard it doesn't even have Windows support yet for example.

Re: Program your next server in Go

#118

Earlier quoted context omitted.

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. I never made that claim, I just emphasized the widely accepted fact that having types is better than not having them. To a Java developer, Go feels like the Java of ten years ago in that respect, so you will encounter some justified push back. > Right tool for the job is a better flexible mindset Of course, but not all tools are equal. In programmi…

javascript and python would disagree with you.

Re: Program your next server in Go

#119

Go has been great for me at providing things like simple microservices, network plumbing, CLI tools and that kind of thing. The C integration is also super simple and makes it easy to wrap up third-party libraries. It's also a bit tedious to write in practice. It's dogmatic, and that's obviously a benefit in some ways but comes with the cost that quite a lot of time in my experience is wasted fiddling around with pro…

Last night I was beating my head against the desk on some highly concurrent code that involved each co-routine satisfying a simple rate limit, among other things. Two hours later I had it working and the final implementation ending up half the size of the original (~1k LOC -> 500 LOC).

I would upgrade your phrasing to: "frustratingly dogmatic in an ok way".

Re: Program your next server in Go

#120
post #117
post #50

Earlier quoted context omitted.

And Crystal ( http://crystal-lang.org/ ).

Definitely, but isn't Crystal still in its early stages? I heard it doesn't even have Windows support yet for example.

Yes, you're right that it is in an early stage of development and doesn't yet support Windows (to be fair, even Rust added full Windows support fairly late in their development cycle to 1.0). Crystal is probably in a slightly earlier stage than Nim, though not by much. Both are very interesting languages that I think would plot in similar locations on the chart. D is also a lot of fun. I think all are competing in this same native compiled realm that seems to be popular right now.
Post reply on HN