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

321–330 of 384 posts

Re: Program your next server in Go

#321

Post by geodel »

IndianAstronaut wrote: post #200
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…

Another major issue I have had with Go is database connectivity. The db drivers are really lackijg for Go. Makes it tough for those of us who use Teradata or Hive.

Well drivers are mostly written by database vendors or respective community in case of open source db. There is not much Go can do there.

Re: Program your next server in Go

#322

Post by kasey_junk »

mratzloff wrote: post #272
eropple wrote: post #196

Earlier quoted context omitted.

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()

Not if they are the only return value. You should use an analysis tool to avoid this but nothing about the language requires it.

Re: Program your next server in Go

#323

Post by geodel »

blub wrote: post #314
ajmurmann wrote: post #254

Earlier quoted context omitted.

I've also found though that these languages attract primadonnas who care more about "attractive" code and getting to play with cutting edge technology that might not be ready for prime time yet than they care about providing business value. Edit: fixing typo. Pay -> play

Then Go should be in the list too. In fact any language that's trending is automatically in that list. The only languages that don't attract prima donnas are the "not hip" ones like Java, C++, C#, Perl, etc.

Not really. Considering Go does not offer features that PL theory enthusiasts love, it remains a boring language.

Re: Program your next server in Go

#324

Post by IshKebab »

oconnor663 wrote: post #262

> When writing code, it should be clear how to make the program do what you want. Sometimes this means writing out a loop instead of invoking an obscure function. For example instead of the obscure function a.reverse() you can use the clear for loop for i := len(a)/2-1; i >= 0; i-- { opp := len(a)-1-i a[i], a[opp] = a[opp], a[i] } :(

Yes there are clearly examples where the loop is less clear than the function. But I think they wanted to avoid complex 'functional' code like this:

    Averager averageCollect = roster.stream()
        .filter(p -> p.getGender() == Person.Sex.MALE)
        .map(Person::getAge)
        .collect(Averager::new, Averager::accept, Averager::combine);
                   
    System.out.println("Average age of male members: " +   averageCollect.average());
From here: https://docs.oracle.com/javase/tutorial/collections/streams/...

A lot of the time it is clearer as an explicit loop, especially for other people to read. But it is annoying a lot of the time. I still think they should add generics.

Re: Program your next server in Go

#325

Post by idobai »

mratzloff wrote: post #274
readams wrote: post #233

Earlier quoted context omitted.

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?

> This comment is patronizing and implies that liking Go makes someone a "junior varsity" programmer, or ignorant of alternative programming models.

Because that's the truth and that was intentional at its design.

> I'm well-versed in half a dozen other languages, many of which include generics.

It depends in which languages.

Re: Program your next server in Go

#326

Post by matthewmacleod »

skj wrote: post #240
spriggan3 wrote: post #63

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…

> but AFAIK a lot of "Googlers" don't really like it and don't use it Where on earth did you hear that? It's simply not true. (googler)

I must admit that I heard exactly the same from multiple Google engineers, who were all quite dismissive of it.

Re: Program your next server in Go

#327

Post by pjmlp »

Pxtl wrote: post #230
dtamhk wrote: post #159

Earlier quoted context omitted.

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

Because of political wars that lead the .NET team to base the Framework on the CLR instead of the COM+ Runtime that was being prototyped.

Why do you think that WinRT is basically the return of .NET the Ext-VOS project origins, but with .NET metadata instead of COM type libraries?

.NET Native is what Ext-VOS was going to be, if it wasn't for the decision to create the CLR instead.

Re: Program your next server in Go

#328

Post by pjmlp »

IshKebab wrote: post #324
oconnor663 wrote: post #262

> When writing code, it should be clear how to make the program do what you want. Sometimes this means writing out a loop instead of invoking an obscure function. For example instead of the obscure function a.reverse() you can use the clear for loop for i := len(a)/2-1; i >= 0; i-- { opp := len(a)-1-i a[i], a[opp] = a[opp], a[i] } :(

Yes there are clearly examples where the loop is less clear than the function. But I think they wanted to avoid complex 'functional' code like this: Averager averageCollect = roster.stream() .filter(p -> p.getGender() == Person.Sex.MALE) .map(Person::getAge) .collect(Averager::new, Averager::accept, Averager::combine); System.out.println("Average age of male members: " + averageCollect.average()); From here: https://…

I can fully understand that example, only someone without FP knowledge would not get it.

Re: Program your next server in Go

#329

Post by stymaar »

shadowmint wrote: post #319
voltagex_ wrote: post #276

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.

I think the tldr; of this (often raised...) argument boils down to: Don't use rust if you're asking that question. If you could implement your solution in go or rust, then go is probably a more appropriate choice; it's a good high level solution for high level problems. Rust is not a good solution for high level problems; it's a good solution for low level problems where go would be a terrible choice; and it's a good…

> Rust is not a good solution for high level problems

Who is saying that ? Not the Rust team, nor the Rust users … Rust is a general purpose programming language, and it's pretty high-level (in terms of features, think about functional programming for instance). The only reason I wouldn't advise everyone to write their stuff in Rust atm, is the youth of the ecosystem (which is growing rapidly, but is still a bit too early-stage): their is no intrinsic limitation in the language that make Rust «not a good solution».

Re: Program your next server in Go

#330

Post by FreeFull »

shadowmint wrote: post #319
voltagex_ wrote: post #276

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.

I think the tldr; of this (often raised...) argument boils down to: Don't use rust if you're asking that question. If you could implement your solution in go or rust, then go is probably a more appropriate choice; it's a good high level solution for high level problems. Rust is not a good solution for high level problems; it's a good solution for low level problems where go would be a terrible choice; and it's a good…

Because Go is a garbage collected language, programs will often require more memory than they would in Rust, although pretty often that's an acceptable trade-off. If the trade-off is acceptable though, it might be worth looking at Nim and D too.
Post reply on HN