Live data from Hacker News

Program your next server in Go

talks.golang.org

221–230 of 384 posts

Re: Program your next server in Go

#221
post #217

Earlier quoted context omitted.

I would contend that java should be considerably lower on the fun scale. Maybe they are counting other languages that target the JVM? Also perl is apparently as fun for humans python which I also find suspect after maintaining perl 5.x code. Turns out this subjective made up graph is subjective and made up I guess.

> Also perl is apparently as fun for humans python which I also find suspect after maintaining perl 5.x code. When people talk about a language being 'fun', they need to distinguish between writing something new for the first time vs maintaining something or figuring out someone else's code.

Yeah I suppose at this point the graph falls apart since even the prospect of writing new perl code does not sound fun to me but I am sure could be fun to someone.

Re: Program your next server in Go

#222
"Sometimes this means writing out a loop instead of invoking an obscure function."

I can't help but think this is specifically a dig in C++'s direction. Since C++11 lambda's I've been using a lot more and I don't think you could get me to go back at this point... Yes I had to learn exactly what a few methods do, but now I have beautiful straight line code...

Re: Program your next server in Go

#223

Earlier quoted context omitted.

I've been writing Go daily for almost two years now and outside of wishing for generics a few times I've never struggled to fit a solution into the type system. I've certainly never considered going back to a duck typed language like Python or Ruby. Not once. Not ever. We have slowly replaced even our glue scripts that are written in Python with Go versions because maintenance and understandability trump any perceive…

As soon as a system reaches a given size, not having static types becomes unwieldy. Go's type system is great. Though my code still uses the var type declarations.

The further I get away from Python the smaller that given size limit becomes. After two years? It's at about 100 lines...

To me, the power of Go's simplicity is almost always underestimated by the language's detractors. I can look at code my team wrote two years ago and with a few gd's in Vim I know what's going on. Obviously Python fails this test, but even a high-level static typed language like C# can suffer greatly from all the magic one can invoke (Linq being a great example).

What it comes down to is that Go doesn't give you many ways to be clever. Younger me who loved template metaprogramming in C++ would scoff at this statement, but if you go back and have to reverse engineer your own cleverness enough times you really, really start to dislike the practice.

Re: Program your next server in Go

#224

Earlier quoted context omitted.

I think it refers to the Perl-era idea that good code should be somehow "clever" rather than maintainable. It's how bad programmers who spend hours agonizing over how to reduce their line count (presumably to save disk space?) justify their behavior.

Personally, I think "cowboy coding" is the best derogatory name for this. IMO, what all of these ninjas have in common is that they don't realize that software development is a team exercise. Berkeley did a study on BSD and found that a file was opened 10x more often for reading that writing (i.e. people read code 10 times for every time they make a change). To my mind, "cowboy" conveys the proper amount of ignorance…

I totally agree with this sentiment. I think it's pretty well established at this point that in many cases clarity can trump optimization. Even more so when the optimization isn't performance based but rather line count based or "code golf" based. Also, do you happen to have a link to that berkley study? I can't seem to find it with a brief search.

Re: Program your next server in Go

#225

Earlier quoted context omitted.

We've been running splice.com on Go for 3 years now and handle 5TB of audio/binary data per day. Our memory usage is around 10-15MB per server and the GC pause time has been really low. You do need to stream your IOs instead of reading everything in memory. In regards to dependency management, we honestly had no issues and now with vendoring, it's even easier. We do use a main repo with lots of smaller packages and o…

Could you elaborate on what you mean by stream your IO? Is this just using buffered io it is there a concept I could read up on here?

yes buffered io, you use readers to read/write small chunks at a time instead of loading everything at once. Go offers way to do both since in some cases, such as loading an entire file in memory can be fine/better/faster.

Re: Program your next server in Go

#226
Go is a phenomenal systems programming language and becoming quite useful as a general programming language too. It's clear from the projects that are now coming into existence that Go lends itself well to the world of distributed systems and from the language design you can see that it was created with network programming in mind. The fact that concurrency is built into the language and errors are treated as values that should be dealt with just highlights those facts.

We used Go at Hailo for our microservices platform and it served us incredibly well. I've gone on to create an open source project called Micro https://github.com/micro/micro that builds on those past experiences. It's just a joy to write micro services in Go.

Re: Program your next server in Go

#227
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.

I'd love to hear about those languages.

Re: Program your next server in Go

#228
post #22
post #19

Earlier quoted context omitted.

The instructions are literally at the bottom of the first slide.

Oh didn't realize i had to read things to learn how to navigate things. Cool UX bro.

We've banned this account for repeatedly violating the HN guidelines. If you don't want it to be banned, you're welcome to email hn@ycombinator.com.

Re: Program your next server in Go

#229

Earlier quoted context omitted.

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

Not using a Result is a warning, not an error: https://is.gd/U43rdG

Re: Program your next server in Go

#230
post #159

Earlier quoted context omitted.

> We continue to use Go because of its strengths, but it just really surprises me how little Google seems to care about the language and ecosystem. Go is certainly a language that is used at Google, but AFAIK a lot of "Googlers" don't really like it and don't use it. It certainly not the "official language at Google", given the weight of C++ and Java there. But that's the consequence of being opinionated. Using Go me…

>> given the weight of C++ and Java there. Python as well. >> how little Google seems to care about the language and ecosystem Let's compare with Microsoft. The top four out of five users at StackOverFlow have top tags in C#, I guess Google have a long way to Go.

And yet the os group at ms is famous for their naked derision of the .net Framework.
Post reply on HN