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

351–360 of 384 posts

Re: Program your next server in Go

#351

Post by eropple »

colin_mccabe wrote: post #281
eropple wrote: post #195

Earlier quoted context omitted.

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…

Java's concurrency story is weak overall. Nearly all code still uses the old-style "synchronized" blocks, rather than ReentrantLock. This shouldn't be a big surprise, considering that ReentrantLock was only introduced recently. With synchronized blocks, you don't have any way of releasing the lock other than by exiting the block, which leads to some very contorted-looking code. The fact that you can synchronize on li…

So this doesn't map to anything I see in the JVM. It's super interesting that you say it (and I want to stress I'm not calling you a liar or anything, it's just different experiences). Personally? I haven't used synchronized blocks since college (so ~2010 or so). I've been using NIO about that time. I don't feel like I'm swimming upstream using it.

Re: Program your next server in Go

#352

Post by eropple »

weberc2 wrote: post #257
eropple wrote: post #195

Earlier quoted context omitted.

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…

Debugging is definitely a valid counter-point. Go's debugging story is rapidly evolving, but it's not particularly friendly or settled at this point. Goroutines are subtly different than coroutines, mostly in that goroutines are not bound to the OS thread they're created on, and also that they don't need to be explicitly yielded--any I/O or lock-blocking (including reading or writing on channels) are potential interr…

> goroutines are not bound to the OS thread they're created on

Neither is a coroutine in Java using the Coroutines library (Javaflow used thread-locals, but Coroutines doesn't), or a Lua-based coroutine...I'm not sure what you're driving at here?

> If you're using Ruby

Sorry, this was inartfully said. If I am using the JVM, i.e. I want to be using something where I can be bombing around on multiple threads etc., I'm probably going to want my inter-thread channels to be unbounded. BlockingQueues in Java give you that; Go channels don't.

Re: Program your next server in Go

#353

Post by [deleted] »

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…

[deleted]

Re: Program your next server in Go

#354

Post by weberc2 »

inglor wrote: post #288
weberc2 wrote: post #191

Earlier quoted context omitted.

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

The code to make I/O concurrent _should_ in my humble opinion look different from the code to parallelize computations since well - in I/O you only care about concurrency and in computation you care about parallelism.

It's not obvious to me why this distinction is useful. Could you explain?

Re: Program your next server in Go

#355

Post by epynonymous »

golang is great, i use it to do 3 things thus far: restful api server (net/http, gorilla mux), dynamic web server (net/http, amber, sql), and websocket server (net/http, gorilla websocket, redigo/redis). the libraries are well implemented, the syntax is beautiful imho, and i'm able to quickly write code similar to interpreted languages like ruby, python, but scale much higher. i used to do lamp, then shifted to python tornado, ruby sinatra, nodejs/expressjs, but find golang to just be more compact and fast. my sinatra environment required rbenv, gems, and i just wasn't impressed with it.

what i like the most about golang is that the end result is a binary where my production server doesn't need to have any dependencies except for the ability to run elf binaries. i like having this option, but in reality the binary size gets pretty unwieldy for upload, so i actually end up doing a pull on the source code, compiling and starting up.

package management has not been a problem for me.

i do find html template packages to be a bit deficient, amber, ace, there are ports of haml and jade, but they all seem pretty half baked. i had to have a lot of hacks in my code to get this stuff working.

also sucks that there isn't a standard orm, but i can hang and keep up with raw sql.

the language expressiveness is not as convenient as say ruby, but it's pretty close.

Re: Program your next server in Go

#356

Post by chrisbroadfoot »

voltagex_ wrote: post #277
chrisbroadfoot wrote: post #123

Earlier quoted context omitted.

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.

Yes! Please do that.

Use something like git-vendor: https://github.com/brettlangdon/git-vendor

Re: Program your next server in Go

#357

Post by weberc2 »

airless_bar wrote: post #287
weberc2 wrote: post #166

Earlier quoted context omitted.

Many folks come to Go from "modern" languages, Python and Java in particular. I don't think this can be considered "dismissing".

I don't think anyone considers Python or Java modern. Nevertheless, this isn't about where adoption comes from, it's about how the language design was influenced by the advancements in language design in the last 40 years.

> I don't think anyone considers Python or Java modern.

This is why I put "modern" in quotes; these languages are "modern" relative to the 1960s-era languages.

> Nevertheless, this isn't about where adoption comes from, it's about how the language design was influenced by the advancements in language design in the last 40 years.

Precisely. The OP implied that Go programmers are "bad programmers" because they can't adapt to post-1960s languages. I countered his hypothesis by pointing out that the lion's share of Go developers were previously competent Python, Ruby, JavaScript, or Java developers. If his hypothesis were correct, one would expect the Go community to be primarily C expats.

For whatever reason, a large swath of developers find the features Go adds to be more useful than the "advancements" Go omits (or perhaps they just find value in the omission of those "advancements" altogether). At any rate, Go's popularity can't be reasonably attributed to graybeard developers who can't grok Java.

Re: Program your next server in Go

#358

Post by insulanian »

spriggan3 wrote: post #331
insulanian wrote: post #247

Which kind of applications does one write in Go? Asking this from perspective of a developer working mostly on business apps with Angular frontend and .NET (C#/F#) backend.

If you use C#/F# you don't need Go, .net is coming to Linux by the way so you definitely don't need Go. With Go you'll basically have to rewrite asp.net from scratch if you're used to that, because frankly the ecosystem is poor if you don't stick to data transformation/ marshaling with an HTTP server. No full featured ORM, no good Logging library, no Razor like view layer, piss poor web frameworks and an extremely ri…

Oh, I definitely don't want to switch to Go :-) I did take a look at it once and decided that it is not for me.

That being said, I still wonder what types of applications are so suitable for Go that people decide to use it instead of other languages?

Re: Program your next server in Go

#359

Post by weberc2 »

eropple wrote: post #352
weberc2 wrote: post #257

Earlier quoted context omitted.

Debugging is definitely a valid counter-point. Go's debugging story is rapidly evolving, but it's not particularly friendly or settled at this point. Goroutines are subtly different than coroutines, mostly in that goroutines are not bound to the OS thread they're created on, and also that they don't need to be explicitly yielded--any I/O or lock-blocking (including reading or writing on channels) are potential interr…

> goroutines are not bound to the OS thread they're created on Neither is a coroutine in Java using the Coroutines library (Javaflow used thread-locals, but Coroutines doesn't), or a Lua-based coroutine...I'm not sure what you're driving at here? > If you're using Ruby Sorry, this was inartfully said. If I am using the JVM, i.e. I want to be using something where I can be bombing around on multiple threads etc., I'm…

> Neither is a coroutine in Java using the Coroutines library (Javaflow used thread-locals, but Coroutines doesn't), or a Lua-based coroutine...I'm not sure what you're driving at here?

I'm not familiar with Coroutines or Lua-based coroutines; coroutines are almost always bound to the thread on which they're created, I was pointing out that this is a primary difference between goroutines and coroutines--goroutines are M:N threads.

> BlockingQueues in Java give you that; Go channels don't.

Go channels aren't meant for this purpose; they're synchronization primitives, not dynamic data structures. You can easily build a BlockingQueue in Go.

Re: Program your next server in Go

#360

Post by weberc2 »

amelius wrote: post #305
weberc2 wrote: post #259

Earlier quoted context omitted.

You can toggle the GC with https://golang.org/pkg/runtime/debug/#SetGCPercent . Turn it off before you enter your block and enable it again at the end of your block.

But can you guarantee that the GC actually makes progress that way?

What does it mean for a GC to "make progress"? My understanding was that the OP wanted to stop the GC for a particular code block, so it would seem that any "progress making" would be undesirable.
Post reply on HN