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

211–220 of 224 posts

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

#211

Post by yrro »

cyphar wrote: post #167
freyr wrote: post #114

Earlier quoted context omitted.

How much programming language syntax is really intuitive, as compared to what you've grown familiar with over time? Once you use the Go(/Jinja/Perl) syntax once or twice, then putting a minus sign to remove whitespace will be easily understood. I am interested in an alternative that you find more elegant.

> I am interested in an alternative that you find more elegant. Why not make it a filter/pipeline (I haven't used template/text in ages, does it support this?), like in Django {{ thing|trimleft }}.

{{ foo -}} does not strip white space from the output of foo. It eats up the following white space.

So "{{ foo -}} bar" renders the same as "{{ foo }}bar".

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

#212

Post by colin_mccabe »

mike_hearn wrote: post #207
colin_mccabe wrote: post #174

Earlier quoted context omitted.

While I agree that compaction is desirable in theory, empirically it's not really necessary. For example, there are no C/C++ malloc/free implementations that compact, because compaction would change the address of pointers, breaking the C language. Long-lived C and C++ applications seem to get by just fine without the ability to move objects in memory. Java code also tends to make more allocations than Go code, simpl…

Experience with C/C++ is exactly why people tend to value compaction. I've absolutely encountered servers and other long-lived apps written in C++ that suffer from heap fragmentation, and required serious attention from skilled developers to try and fix things (sometimes by adding or removing fields from structures). It can be a huge time sink because the code isn't actually buggy and the problem is often not easily…

Well, I can only say that your experience is different than mine. I worked with C++ for 10 years, on mostly server side software, and never encountered a problem that we traced back to heap fragmentation. I'm not sure exactly why this was the case... perhaps the use of object pools prevented it, or perhaps it just isn't that big of a problem on modern 64 bit servers.

At Cloudera, we still mostly use CMS because the version of G1 shipped in JDK6 wasn't considered mature, and we only recently upgraded to JDK7. We are currently looking into defaulting to G1, but it will take time to feel confident about that. G1 is not a silver bullet anyway. You can still get multi-minute pauses with heaps bigger than 100GB. A stop-the-world GC is still lurking in wait if certain conditions are met, and some workloads always trigger it... like starting the HDFS NameNode.

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

#213

Post by colin_mccabe »

mike_hearn wrote: post #206
colin_mccabe wrote: post #177

Earlier quoted context omitted.

The difference is that you can upgrade each Go application to Go 1.6 separately, whereas with Java, once you upgrade the JVM, all of your applications get upgraded at once. While you could technically have two different JVMs installed side-by-side, in practice nobody actually does this because of the operational complexity and the way that Java handles dependencies. Perhaps this will become an issue for Go if people…

I really don't get this at all. The JVM is a program. It sits in a single directory. I routinely have several installed on my laptop. There are no operational complexities from having multiple different versions installed, if you want that. I suspect this really boils down to operational complexities of Linux distros, not Java. If your package manager only lets you install one JVM then maybe this seems "complicated"…

It's not a Linux issue. People almost always install the Oracle JVM themselves rather than using a package manager (it's a long story...)

The desire for a single JVM comes partly from the architecture of Hadoop itself. Hadoop is structured as a framework (you give your MR job to YARN and it runs it by creating new JVMs for you).

The Java standard library is weak in many areas. The "write once, run anywhere" ideology is part of it, but there are also just... weak parts.

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

#214

Post by twotwotwo »

geodel wrote: post #157
blakeyrat wrote: post #139

Earlier quoted context omitted.

Great tooling? Does Go have any quality IDEs with integrated debuggers yet? I feel that open source developers mean something entirely different with the phrase "great tooling" than developers used to Visual Studio would mean. :)

Absolutely! They do not mean big GUI based IDE when they say tooling. Infact this is why Go will remain unviable option to .net developers. Go is likely to be much more popular among dynamic languages users and even some Java developers who are tired of enterprisey bloat.

https://github.com/visualfc/liteide exists with, basically, many of the same things as you see people augment vim, etc. with (autocomplete, format on save, etc.) but a GUI editor. It has interactive debugging, but I don't use it so I dunno how it is. I can't promise you'll like it, but I dig it for some uses and it's there. The GUI itself seems to be maintained by one developer and as such it is unlikely to ever have full feature parity with Visual Studio. :)

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

#215

Post by twotwotwo »

pjmlp wrote: post #199
twotwotwo wrote: post #176

Earlier quoted context omitted.

Another weird thing is, the background collection is still using a core (plus somewhat slowing foreground code, with write barriers) when it runs. It's kinda like you have a varying amount of CPU power. One approach is just to program as if you had less CPU, as if there were always a GC running. I suppose if you have some code that isn't smoothness critical (game AI, say), or CPU-affecting detail settings you can twi…

Back in the 80's and early 90's, that type or remark was intended to anyone trying to use Turbo Pascal, C, AMOS, Turbo Basic, Forth, Modula-2.... for game development. No sane game developer would use anything other than Assembly. The more things change, the more they stay the same.

Wasn't to discourage at all--was trying to give my understanding (based on the design docs, talks, etc.) of what your CPU budget looks like and speculate about ways to deal.

"It'd be really cool" was absolutely sincere; the Go folks have given us some new toys and it'd be neat to see how far we can take 'em.

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

#216

Post by pjmlp »

twotwotwo wrote: post #215
pjmlp wrote: post #199

Earlier quoted context omitted.

Back in the 80's and early 90's, that type or remark was intended to anyone trying to use Turbo Pascal, C, AMOS, Turbo Basic, Forth, Modula-2.... for game development. No sane game developer would use anything other than Assembly. The more things change, the more they stay the same.

Wasn't to discourage at all--was trying to give my understanding (based on the design docs, talks, etc.) of what your CPU budget looks like and speculate about ways to deal. "It'd be really cool" was absolutely sincere; the Go folks have given us some new toys and it'd be neat to see how far we can take 'em.

That was my point as well.

The culture in the gamedev world is such that the big teams only switch tooling when forced to do so. Only amateurs tend to try out new ways.

Back when the move from Assembly to higher level languages started, many games would be filled with inline Assembly.

The compilers weren't that good generating code and they didn't want to loose the power of Assembly.

Just like now with the managed runtimes and having tons of C and C++ underneath. Languages that weren't that speedy 30 years ago.

We need to keep the spirit of taking things far alive, because in computing seeing is believing.

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

#217

Post by BuckRogers »

tshannon wrote: post #163
woofiefa wrote: post #160

I develop a lot of command line tools for Linux using shell scripting. The scripts are getting huge and ugly, so I have been looking at Go and it seems I can do so many things by just using the standard library and in general a big improvement over using scripting. However, everytime Go is discussed at HN I see many posts criticizing the language for various reasons and this has put me off getting started learning Go…

I suggest just writing something in it. A lot of the criticisms turned me off as well, but I dove in anyway. I stopped paying attention to the criticisms when I found out how incredibly productive I was able to be in Go. Give it a try and make your own call on it. The cognitive overhead of jumping into Go is so small compared to many other languages.

> The cognitive overhead of jumping into Go is so small compared to many other languages.

I'm not using Go now, though I have tried it out years ago. Your point is exactly why it stays on my radar for possible future use. Especially if you consider any sort of business aspect, ramping up the help. I would strongly consider using it for any serious backend project in a business environment due to the performance, ease of learning and compatibility promise.

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

#218

Post by BuckRogers »

iends wrote: post #57
armitron wrote: post #36

Am I in the minority to think of Go as a completely unnecessary move-along-now-nothing-to-see-here project? (as if we didn't have enough of that already). The only niche I see for it is for those poor souls who are still wasting their time with Python/Ruby but that by itself surely can't lead to great things for the language, especially since it's riding on air. More dense air than Python but air nonetheless. Also Ro…

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?

Anything that is C ABI compatible. I'm sympathetic to Go's philosphy, but Go is not that.

In general, I'd be on the lookout for Swift on the server in the next few years. It has the backing of Apple, is compiled, and the possibility of removing yet-another-language from your stack. Since many shops want or need an iOS frontend, running Swift on the server makes sense.

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

#219

Post by BuckRogers »

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…

Agreed, I think timing with Go is a huge factor. Though I think the size and scope of Go's popularity is overstated. I looked into it for a recent web project and found many formerly popular libraries now unmaintained. I felt more confident and went with Django on Python 3.5.

If I want something compiled, the killer for Go for me has always been C ABI incompatibility. It's its own island. I'm not saying I wouldn't consider using Go for some things, but that has been a big redflag vs other choices.

Post reply on HN