Program your next server in Go • Hacker News Board

Re: Program your next server in Go

#271

Post by snovv_crash » Wed, Jun 08, 2016, 5:45 AM UTC

mahyarm wrote: post #252

pvelagal wrote: post #114

Earlier quoted context omitted.

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 ?

In my experience programming speed goes like this: - 1x benchmark - C / static C++ - 2x slower - pure virtual C++ / objective-c - 3x slower - statically typed GC languages (java,go) - +6x slower - dynamically typed GC languages (js, python, etc) After a well optimized implementation, speed comes down to manual vs GC memory management, static vs virtual function dispatch, dynamic vs static typing and heap vs stack all…

That 6x is for when you have a JIT. Without one (I'm looking at you, CPython) it is 20-30x, with perhaps the exception of Lua.

Re: Program your next server in Go

#272

Post by mratzloff » Wed, Jun 08, 2016, 5:45 AM UTC

eropple wrote: post #196

vertex-four wrote: post #186

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…

You must explicitly ignore errors in Go.

result, _ := someFunc()

Re: Program your next server in Go

#273

Post by niothiel » Wed, Jun 08, 2016, 5:45 AM UTC

Jtsummers wrote: post #175

yanilkr wrote: post #149

Earlier quoted context omitted.

"insurmountable advantage" - I don't think so. the simplicity that javascript and python provides is an enormous advantage to many kinds of projects.

It's not simple when you have to maintain it or debug it. There are many classes of errors that can occur when writing software. Languages with implicit variable creation like python obscure errors like mistyping the name of a new variable (versus an explicit declaration like in C or an ML where the mistyped name will result in an error immediately modulo name conflicts). It looks correct at a glance, but: def foo(a_…

Per your typo point, this has already been solved by linting. If I made a typo like that, any decent editor (Sublime in my case) would draw a big red box and complain at me for using an undeclared variable. In the case of a typo on assignment as in your example, the linter would report a variable declaration without usages.

Per your testing point, so what? Doesn't everyone strive for 100% code coverage anyway? One of the big advantages of dynamic languages is that more functionality can be implemented in less code which in turn makes it easier to hit that 100% coverage.

Re: Program your next server in Go

#274

Post by mratzloff » Wed, Jun 08, 2016, 5:56 AM UTC

readams wrote: post #233

Matthias247 wrote: post #170

Earlier quoted context omitted.

Not necessarily. I think by providing native slice and map types Go reduces the need for generics already by a large margin. Other things that often use generics (higher order functions, future types, ...) are no idiomatic Go which leans more to the imperative way of doing things. In total I have not really missed generics in Go up to now (but I have up to now only written about 20kloc in it) - while I certainly miss…

As long as your needs are sufficiently basic that you never need to create data structures then what's in Go can be ok. People who are fans of Go seem to be people who don't know what they're missing in more advanced languages. This seems to include C programmers and dynamic language programmers. Programmers used to better type systems are generally not happy with Go.

This comment is patronizing and implies that liking Go makes someone a "junior varsity" programmer, or ignorant of alternative programming models. It doesn't. I'm well-versed in half a dozen other languages, many of which include generics. I like Go just fine. Yes, there are cases where it is not the best choice. That's fine, too.

How much Go have you written, out of curiosity?

Re: Program your next server in Go

#275

Post by mratzloff » Wed, Jun 08, 2016, 6:12 AM UTC

codedokode wrote: post #266

Here are the problems I had when tried to write a simple CLI utility (tool to run any program in seccomp-bpf based sandbox) in Go: - using case of a first letter of identifier as a public/private flag. You end up with half names starting in a lowercase letter, half in an uppercase (the code looks inconsistent) and forgetting how to spell them. And having to rename the function everywhere when you decide to change it…

Many of these points are simply wrong, or confused.

Re: Program your next server in Go

#276

Post by voltagex_ » Wed, Jun 08, 2016, 6:16 AM UTC

Can anyone convince me to use Rust over Go, or the other way around?

My target machines range from i7s with massive amounts of RAM to Raspberry Pi with slightly-less-massive amounts of RAM.

Re: Program your next server in Go

#277

Post by voltagex_ » Wed, Jun 08, 2016, 6:19 AM UTC

chrisbroadfoot wrote: post #123

akavlie wrote: post #122

Earlier quoted context omitted.

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.

For a production app, wouldn't you "pin" your dependency to a particular version? I know I wouldn't be allowed to track master in my workplace.

Re: Program your next server in Go

#278

Post by i_feel_great » Wed, Jun 08, 2016, 6:36 AM UTC

geodel wrote: post #227

MustardTiger wrote: post #55

Earlier quoted context omitted.

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.

Erlang and Ada are two that I consider superior to Go.

Re: Program your next server in Go

#279

Post by saturn_vk » Wed, Jun 08, 2016, 6:40 AM UTC

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.

One of my starting languages was Perl. It was definitely fun to write small stupid scripts, especially with dealing with strings.

Re: Program your next server in Go

#280

Post by colin_mccabe » Wed, Jun 08, 2016, 6:42 AM UTC

squiguy7 wrote: post #94

ridiculous_fish wrote: post #81

Earlier quoted context omitted.

IME, clarity and reasoning are weak points of Go, relative to other systems programming languages (but perhaps not to dynamic languages): 1. Slices make it hard to reason about aliasing. bar = append(foo, val): does bar now alias foo? The answer is the worst possible: "sometimes." 2. Closure semantics make it hard to reason about thread safety. I converted this serial loop to parallel using goroutines; did I introduc…

I didn't mean to gloss over the go routine problems. You're absolutely correct, when there exist tools like the race detector it makes it evident that you can write incorrect concurrent programs. Becoming proficient at using the concurrency patterns in Go takes time but it is an advanced topic. Thanks for writing up these common mistakes.

Those aren't common mistakes, just things he dislikes about the language. For example, I don't care whether := sometimes does not introduce a new variable (have never had a bug related to that). I don't find the closure semantics any worse than Java's (sure Java requires captured variables to be final, but it doesn't require them to be immutable).

I find append's semantics to be pretty intuitive. But then again, I'm familiar with realloc in C, which is where it came from. At any rate, slices are references to an underlying array. If you are making one slice from another slice in a way that potentially doesn't involve copying, you should expect the new thing to alias the old thing.

People often complain about channels having limited buffer sizes. But if channels had unlimited buffering, they'd complain about memory leaks and inefficiency.

A list of common mistakes in Go would be interesting. It would probably start with the "assigning a typed nil value to an interface leads to interface != nil" wart.