The State of Go: Where we are in February 2016 • Hacker News Board

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

#151

Post by masklinn » Wed, Feb 03, 2016, 10:25 PM UTC

djur wrote: post #142

blakeyrat wrote: post #137

Earlier quoted context omitted.

There are a heck of a lot games written in C#, which is not only interpreted, but probably has a less-tuned GC. Including heavy-processors like Kerbal Space Program. If KSP works in C#, you can write a game in Go no problem.

C# is not interpreted, and the CLR has a generational GC on par with the JVM. Many C# games are built on game engines like Unity which are implemented in C++, anyway.

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

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

#152

Post by geostyx » Wed, Feb 03, 2016, 10:27 PM UTC

oliv__ wrote: post #135

I get where we are...but where are we going?

Go 1.7 Planning: https://groups.google.com/forum/#!topic/golang-dev/TerfinvPf...

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

#153

Post by gecko » Wed, Feb 03, 2016, 10:42 PM UTC

masklinn wrote: post #151

djur wrote: post #142

Earlier quoted context omitted.

C# is not interpreted, and the CLR has a generational GC on par with the JVM. Many C# games are built on game engines like Unity which are implemented in C++, anyway.

> 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 for .NET 1.1, which explicitly states that, even at that time, the bytecode is JITed prior to execution.

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

#154

Post by gnuvince » Wed, Feb 03, 2016, 10:47 PM UTC

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.

I'm learning Rust by writing a toy compiler, definitely a high-level task, and I'm finding that Rust is pretty good for that. Some highlights:

- Algebraic datatypes and pattern matching: extremely nice for compiler work where you need to manipulate symbol data.

- Result + try! macro: a bit more verbose than a language that can let an exception bubble up, but definitely nicer than the boiler-plate that people in Go must use.

- Module system: easy to expose only what you want.

- Cargo: one of the best, maybe the best, language package manager that I've used. Super easy to add dependencies to your project.

I will say this however: I'm moving more slowly than I would in a language like OCaml. I still haven't assimilated all of the borrow checker rules in my programming sub-conciousness, so I still make errors and it can take a little while to figure out what's happening and how best to address the problem.

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

#155

Post by pcwalton » Wed, Feb 03, 2016, 10:50 PM UTC

geodel wrote: post #150

mike_hearn wrote: post #143

Earlier quoted context omitted.

OK, the tradeoff they're making that I missed is that it's not a compacting collector. So eventually your heap can fragment to the point where allocation gets expensive or impossible. Unusual design choice.

Unlike Java Go has first class value types and memory layout can be controlled by developers. So it leads to much less objects on heap and compact layouts both will lead to far less fragmentation. As you can see here Go apps use quite less memory than Java. https://benchmarksgame.alioth.debian.org/u64q/go.html

You can't really compare total memory usage of a JIT to total memory usage of an AOT compiler that way if what you're trying to show is that value types reduce memory usage.

Also, I suspect that the fact that JVMs use a generational GC (and a compacting GC) blows everything else out of the water when it comes to fragmentation. There's no way a best-fit malloc implementation can possibly beat bump allocation in the nursery for low fragmentation.

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

#156

Post by amelius » Wed, Feb 03, 2016, 10:52 PM UTC

nulltype wrote: post #93

amelius wrote: post #84

Earlier quoted context omitted.

The only thing missing is a good binding to a javascript engine, for code that has to run on both client and server.

If you need to write code that runs on your go server and on the client, there's always https://github.com/gopherjs/gopherjs

That is nice. But I hope that you understand that such a solution is not always preferred in every situation. For example, for performance reasons, it is always better to code in the native language.

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

#157

Post by geodel » Wed, Feb 03, 2016, 10:58 PM UTC

blakeyrat wrote: post #139

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…

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.

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

#158

Post by bboreham » Wed, Feb 03, 2016, 11:01 PM UTC

masklinn wrote: post #151

djur wrote: post #142

Earlier quoted context omitted.

C# is not interpreted, and the CLR has a generational GC on par with the JVM. Many C# games are built on game engines like Unity which are implemented in C++, anyway.

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

What are you talking about? .Net is compiled to native code on load. (Or earlier)

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

#159

Post by voidlogic » Wed, Feb 03, 2016, 11:04 PM UTC

schmichael wrote: post #105

kyrra wrote: post #101

Earlier quoted context omitted.

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.

GC changes is a big one in the JVM, but not so much in Go (so far) as Go offers basically no GC tunables. So while your awesome CMS tweaks from JDK7 become worthless once you switch to G1 on JDK8, with Go all you can do to optimize the GC is to create less garbage to begin with. Not trying to say one approach is better than the other: Go's approach is operationally simpler but far less sophisticated than the JVM's.

>as Go offers basically no GC tunables.

This isn't actually true, Go has a single tunable: "GOGC" https://golang.org/pkg/runtime/

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

#160

Post by woofiefa » Wed, Feb 03, 2016, 11:20 PM UTC

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.