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

161–170 of 224 posts

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

#161

Post by vorg »

kasey_junk wrote: post #89
schmichael wrote: post #79

At work (Lytics) 100% of our backend code has been in Go since the beginning over 3 years ago, so slide #6 highlights one of the most things with nearly every Go release: > Changes to the language: None https://talks.golang.org/2016/state-of-go.slide#6 We generally get our entire stack upgraded to the latest release within 1-3 months with little effort. It wouldn't be much more work to be ready to upgrade on release…

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.

Perhaps they were using some non-Sun/Oracle programming software besides Java, something like Groovy.

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

#162

Post by travjones »

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…

Programming languages are kind of like religion, or one's favorite beverage/food. Everyone has their own preference/coding style. I wouldn't let negative comments on HN steer you away from learning Go. Of course, I'm biased because I write Go code and enjoy it, but there will always be folks who love something and hate something. You'll never know whether you enjoy coding in Go unless you try it for yourself.

Some of the criticisms of Go are valid and some are just haters doing what haters do--hating. Keep in mind Go is very young for a programming language. It's only about 6 years old, but it's use is becoming more and more widespread as it matures.

Although you are correct in that the standard library is pretty much all you need to write CLI apps, this library is definitely useful if you're willing to pull in a third-party dependency: https://github.com/codegangsta/cli

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

#163

Post by tshannon »

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.

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

#164

Post by shawnps »

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…

Definitely take a look at Go. If criticism on HN is what you're concerned about, I can tell you that when I started writing Go ~3 years ago it got a lot more criticism on HN than it does now. I've used it as my primary language since then and it's a fun language.

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

#165

Post by masklinn »

gecko wrote: post #153
masklinn wrote: post #151

Earlier quoted context omitted.

> C# is not interpreted Unless you're asserting that e.g. Python is not interpreted; or you're using the relatively recent native toolchain, C# is interpreted. That's its original state and its widest deployment pattern.

You're misinformed, I suspect because you are conflating .NET programs being distributed as bytecode with .NET programs being interpreted. It is true that .NET programs are traditionally distributed as CLR bytecode. This is similar to a .class file or a .pyc file. But the CLR does now, and always has, had a JIT. E.g., the first line or two of https://msdn.microsoft.com/en-us/library/ht8ecch6(v=vs.71).a... , which is…

> You're misinformed, I suspect because you are conflating .NET programs being distributed as bytecode with .NET programs being interpreted.

No and no.

> But the CLR does now, and always has, had a JIT.

And Python has had a JIT[0] for as long as the framework has existed.

[0] https://en.wikipedia.org/wiki/Psyco now replaced by the pypy project

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

#166

Post by sreque »

kasey_junk wrote: post #89
schmichael wrote: post #79

At work (Lytics) 100% of our backend code has been in Go since the beginning over 3 years ago, so slide #6 highlights one of the most things with nearly every Go release: > Changes to the language: None https://talks.golang.org/2016/state-of-go.slide#6 We generally get our entire stack upgraded to the latest release within 1-3 months with little effort. It wouldn't be much more work to be ready to upgrade on release…

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.

The biggest issue I've seen with JDK upgrades is not the language changes but bytecode changes. Many tools and frameworks such as Guice, Spring, PowerMock, AspectJ, and code coverage tools all operate on byte code, not source code. Therefore, whenever there is a classfile format change, all these tools potentially break until they are updated.

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

#167

Post by cyphar »

freyr wrote: post #114
ebbv wrote: post #87

Earlier quoted context omitted.

> The whole point of this feature is to be terse... I get that. I don't think you understood my objection, which was that being terse is not as important to me as being elegant and easily understood. {{foo -}} is not clear looking at it what that - is gonna do. You have to already know, or look it up. There is basically no way to know from context what the desired behavior is. That's bad design IMHO.

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

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

#168

Post by cyphar »

notacoward wrote: post #144
aikah wrote: post #131

Earlier quoted context omitted.

Nim doesn't have interfaces. The amount of plumbing required to implement them is ridiculous. It has generics though. My point is how can recent OO languages miss this kind of stuff when designing their type system ? Crystal looks like a better bet, unfortunately it doesn't run on Windows.

At risk of sounding like a Go advocate when generics come up, the lack of interfaces doesn't bother me because interfaces themselves are a bit of a hack. When you have inheritance, object variants, generics, and a strong template/macro system, what's left for interfaces to do? I'd much rather have all of these other things than interfaces alone.

The fact that you can create an online interface and an unrelated library (which you didn't write) can have structures that implement your interface automatically is pretty useful (and cool) IMHO.

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

#169

Post by wstrange »

15155 wrote: post #136
aikah wrote: post #40

Earlier quoted context omitted.

> Go as a completely unnecessary move-along-now-nothing-to-see-here project I don't like Go type system, but it handles concurrency quite nicely. It's fairly easy to learn and to use so I can see why managers chose it. And it's backed by Google so it can give a sense of safety and it can be used as an argument to sell the language. So it's a bit unfair to say it's unnecessary. It can help when performance is a concer…

Devil's advocate: > but it handles concurrency quite nicely So does Erlang/Elixir, Haskell, Clojure. > And it's backed by Google so it can give a sense of safety How is Dart doing in this department?

Dart is doing fine.

It has not replaced Javascript (that was never going to happen) but it has seen a slow but steady growth in adoption.

There are some amazing things happening with Dart on mobile (flutter.io), Dart on embedded (fletch), and improved JS interop with things like the Dart Dev Compiler (DDC).

Angular 2 is still in Beta, but has first class support for Dart.

Perhaps it did not live up to it's initial hype - but Dart is a pretty "safe" bet

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

#170

Post by colin_mccabe »

kasey_junk wrote: post #89
schmichael wrote: post #79

At work (Lytics) 100% of our backend code has been in Go since the beginning over 3 years ago, so slide #6 highlights one of the most things with nearly every Go release: > Changes to the language: None https://talks.golang.org/2016/state-of-go.slide#6 We generally get our entire stack upgraded to the latest release within 1-3 months with little effort. It wouldn't be much more work to be ready to upgrade on release…

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.

While I agree that Java has been one of the most stable and backwards-compatible languages out there (especially compared to things like Scala, which regularly breaks source and binary backwards compat), there are still rough edges. I am not the original poster, but I can speak for why JVM deployments take time on Hadoop (which I work on).

* In order to upgrade the JVM, all the software you run has to work with the new JVM. If there's even one minor library that doesn't work or is suboptimal, you can't cut over. This is not an issue with Go because everything is compiled to an x86_64 binary there, whereas in Java everything is a jar file that must be run under (almost always a single) JVM.

* During a JVM version change, often Oracle removes or modifies non-public APIs that you need to achieve acceptable performance. For example, there is still no public way to free a DirectByteBuffer or create a FileChannel from a FileDescriptor, so you have to use the non-public APIs. Go almost never has this sort of problem since they tend to provide public APIs for everything you need, including platform-specific things.

* We run really big JVM heaps (>100 GB), and so minor changes in the GC behavior or default settings can cause major issues. For example, JDK8 changed the defaults for many GC tunables. It takes weeks of work at least for us to validate that there are no significant regressions. This is an issue that I would expect Go to have as well since they are changing the GC.

* Enterprise customers are extremely risk-averse, and they're not enthusiastic about deploying a new JVM. Operationally, they don't see any upside, only downsides. Of course JVM upgrades have to happen eventually, but they usually happen when new software is rolling out as well. Oracle's decision to stop shipping security updates for older JVM versions has "helped" in a sense by making the issue seem more urgent.

* Open source projects don't like dropping support for users running older software. There is usually someone around to argue against dropping support for anything that rolled out within the last 5 years.

Post reply on HN