Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Go: Where we are in February 2016

talks.golang.org

Post reply on HN
Print view View original

121–130 of 224 posts

Re: The State of Go: Where we are in February 2016

#121

Post by mschulze »

iends wrote: post #115
ssmoot wrote: post #65

Earlier quoted context omitted.

Please keep in mind I may have completely misinterpreted your comment. > Java? Lots of JEE/App server issues to consider Why? Why not just package as an assembly, scp it up to a server, fire up Netty in a main-class and call it a day (this is basically all Play Framework does)? It's going to be faster/simpler in every way than any Ruby/Nginx stack you can imagine. No need to fight with matching cores to processes per…

Sorry, I used to work at IBM and in my mind Java is WebSphere and a lot of suffering. Certainly, there are other simple ways to use the Java stack with things like Play. DropWizard, etc. But there is certainly a lot more complexity around tooling and deployments and such in the Java ecosystem than either Go or Node.js (although I can't say I'm a Java expert, so it could just be I'm just wrong).

With Spring Boot (not saying Spring is one of the "uncomplex" parts of the Java ecosystem) build and deployment goes like this: `gradle build`, `scp` the jar file to a server and then you can symlink it to `/etc/init.d/` and just use it as a service.

Re: The State of Go: Where we are in February 2016

#123

Post by EugeneOZ »

iends wrote: post #118
krisdol wrote: post #82

Earlier quoted context omitted.

>If you want a reasonably fast statically compiled language, what would you use? I'd go for rust.

Rust seems like a nice systems language, but is it really best suited for non-system programming? I may be too risk adverse, but it seems too early to make that bet at this point.

Works fine for the web needs.

Re: The State of Go: Where we are in February 2016

#124

Post by jibalt »

notacoward wrote: post #113
iends wrote: post #57

Earlier quoted context omitted.

The value of Go is: 1) Reasonably fast (better than Node at CPU bound tasks, faster than Ruby/Python) 2) Statically compiled 3) Great tooling (except package management, but it's getting better) If you want a reasonably fast statically compiled language, what would you use? Java? Lots of JEE/App server issues to consider TypeScript? I'm a fan, but it's compile time type checking and not runtime type checking. TypeClo…

> If you want a reasonably fast statically compiled language, what would you use? Nim. More similar to Go than most languages are to each other, but Nim has (a) more modern features, (b) better compatibility/integration with C libraries, and (c) an amazing macro system. The only thing in Go's favor is the size of its community/ecosystem, which seems to be an accident of timing and most definitely not about inherent q…

Nim is fun but it's not even at version 1 and has a very small developer and user base.

"The only thing in Go's favor ..."

The selectivity of a true ideologue.

Re: The State of Go: Where we are in February 2016

#125

Post by _ph_ »

martijn_himself wrote: post #17

A Golang beginner's question: do these GC improvements make Golang a suitable language/ platform for writing games? EDIT: I realise this is a vague question. I suppose I was wondering if the order of magnitude GC performance in Go is likely to interfere with game loops you might find in reasonably CPU/ GPU intensive Indie games (i.e. NOT Crysis).

It should be suitable - but whether it is depends also on your memory usage. GCs are not black boxes which magically work or not work. They do get bad reputation by people who do heap allocations without thinking about them. They key to good GC performance is about the allocation profile. GO gives you very good control about heap allocation, so it should be possible to arrange the main game loop such that no fresh heap is allocated, which also would mean that the GC does not run. The GO GC runs when, the allocated heap grow to a set multiple (by default 2x) of the heap size after the last GC run. Adjusting this factor to your memory usage should give you pretty good control when the GC runs and when not.

Re: The State of Go: Where we are in February 2016

#126

Post by jibalt »

FenugreekAcerb wrote: post #8
abiox wrote: post #7

Earlier quoted context omitted.

is this kind of like "why is there a black history month and not a white history month"?

https://en.wikipedia.org/wiki/Black_History_Month#Criticism

" I just think that treating them "differently" is not the solution."

They are already treated differently ... duh.

Re: The State of Go: Where we are in February 2016

#127

Post by AsyncAwait »

martijn_himself wrote: post #17

A Golang beginner's question: do these GC improvements make Golang a suitable language/ platform for writing games? EDIT: I realise this is a vague question. I suppose I was wondering if the order of magnitude GC performance in Go is likely to interfere with game loops you might find in reasonably CPU/ GPU intensive Indie games (i.e. NOT Crysis).

Nim (http://nim-lang.org), is a language in some ways filling a similar niche to Go and they are suitable for games, because you can tune or even change the GC. Not the case with Go, so may be less suitable for soft real-time like games.

Re: The State of Go: Where we are in February 2016

#128

Post by sdegutis »

softawre wrote: post #60
sdegutis wrote: post #42

Earlier quoted context omitted.

Yeah, you're in the minority. Technology is more or less a popularity contest. I've seen plenty of really good programming languages that simply die out because they don't have high-profile personalities behind them. And there's plenty of "meh" or even terrible languages that make it big because the hype is strong with this one. It's not great but at the end of the day, bits are bits and bytes are bytes, most program…

Brainfuck wants a word with you

I thought esoteric languages were obviously excluded :P

Re: The State of Go: Where we are in February 2016

#129

Post by notacoward »

jibalt wrote: post #124
notacoward wrote: post #113

Earlier quoted context omitted.

> If you want a reasonably fast statically compiled language, what would you use? Nim. More similar to Go than most languages are to each other, but Nim has (a) more modern features, (b) better compatibility/integration with C libraries, and (c) an amazing macro system. The only thing in Go's favor is the size of its community/ecosystem, which seems to be an accident of timing and most definitely not about inherent q…

Nim is fun but it's not even at version 1 and has a very small developer and user base. "The only thing in Go's favor ..." The selectivity of a true ideologue.

It's the Go fanatics who are the ideologues here. Anything Go has is important, anything it doesn't have is trivial. What a horrible attitude to bring into any kind of technical discussion.

I've defended Go against detractors who say it's worthless because it has mandatory GC or doesn't have generics (which I do consider a weakness but not a fatal one). There's nothing particularly wrong with Go, but there's not all that much special about it either and it does have flaws. Can you name some other feature that (a) distinguishes Go from Every Other Language and (b) matters? Something that might sway a CEO, as we were discussing? "Goroutines" perhaps? Riiight. That CEO will be really impressed. Don't project your bias onto others.

Re: The State of Go: Where we are in February 2016

#130

Post by vram22 »

kyrra wrote: post #101
kasey_junk wrote: post #89

Earlier quoted context omitted.

Can you speak to why you were behind latest on the JVM? I can think of less than a handful of breaking changes over the last 15 years. I'd say it was more stable than Go.

Issues I've seen with JDK upgrades over the years (that I can think of right now): * when "enum" keyword was added, if you had a variable named enum you had to rename it. * If you use any of the sun.* packages you always ask for trouble on major upgrades. * GC changes over the years can change how your program runs (latency changes, OOM issues). This probably applies to Go as well.

> If you use any of the sun.* packages you always ask for trouble on major upgrades.

IIRC, that caution about using sun.* packages was mentioned by Sun in docs of early Java versions, like 1.2 / 1.4 etc. Not sure about more recent ones.

Post reply on HN