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

Go 1.6 is Released

blog.golang.org

Post reply on HN
Print view View original

231–240 of 367 posts

Re: Go 1.6 is Released

#231

Post by mahmoudimus »

cdelsolar wrote: post #225
kasey_junk wrote: post #54

Earlier quoted context omitted.

There are less options in golang so its easier to get started or to jump into the middle of a project. For certain classes of problems the golang standard library is dramatically better than the java ones so you don't have to spend as much energy researching alternatives. It tends to perform well by default for web service and/or cli applications. Compared to java it is more terse (though not compared to some jvm alt…

abysmal tooling? ... extremely primitive concurrency support?? Are you talking about Go?

It is pretty much an undisputed fact that modern Java tooling beats mostly everything else out there for any other language. If you're coming from a more modern JVM background, yes, the first thing I have felt was that most plang tooling is abysmal ... relative to the JVM.

Re: Go 1.6 is Released

#232

Post by pjmlp »

kasey_junk wrote: post #110
jdcarr wrote: post #90

Earlier quoted context omitted.

What's your use cases where you've found startup time to be a significant issue?

Long running processes without a lot of events can also deal with "startup issues", in that they won't trigger JIT.

You can set the JIT threshold to 0, then it will JIT the full bytecode on startup, but it might perform worse.

Re: Go 1.6 is Released

#233

Post by pjmlp »

jahewson wrote: post #136
jdcarr wrote: post #90

Earlier quoted context omitted.

What's your use cases where you've found startup time to be a significant issue?

Short-lived processes are an issue, because while startup time can be ok, code won't perform well until it's hot enough to be JITed.

You can set the JIT threshold to 0, assuming the impact would still be worthwhile.

The alternative is a commercial JDK, almost all of them do support AOT compilation.

Re: Go 1.6 is Released

#234

Post by pjmlp »

taf2 wrote: post #12
meddlepal wrote: post #8

Earlier quoted context omitted.

Java SE and a fat jar... checks all the boxes and has generics and superior tooling. I still don't get the Go love.

Go starts very fast compared to jvm. Go compiles into a binary that does not require a jvm to be installed... Go does not require an IDE to develop in... Go is also less verbose

> Go compiles into a binary that does not require a jvm to be installed.

Java also does not need a JVM to installed.

1 - Use a fat jar

2 - Use the upcoming Java 9 linker which bundles everything together

3 - Spend some money and get a commercial JDK with AOT compilation to native code. All the major ones support it.

4 - Eventually Java 10 Oracle JDK will support AOT compilation to native code, but it remains to be seen if will remain commercial only

Re: Go 1.6 is Released

#235

Post by pjmlp »

rhodysurf wrote: post #19
golergka wrote: post #13

Earlier quoted context omitted.

Why GUI though? Go shines for servers, but I would never want to write a desktop application with it though. Especially if I could do it in C#.

Because a C# GUI on Linux or Mac is not very native looking. Also for the same reason some like Go over Java, static binaries instead of requiring JVM or CLR be installed. On another note, because writing programs in Go is much faster than say C++ or C for most use cases.

There is this thing called AOT compilation for Java and .NET.

Re: Go 1.6 is Released

#236

Post by pjmlp »

hacknat wrote: post #97
dh997 wrote: post #68

Go CSP is minimal and ortongonal, I just wish it did three things: 0. could lto optimize or link against a shared library to reduce the titanic size of compiled programs and cut down on duplication of instruction. Therue is no practical sense in wasting memory and storage on systems with dynamic linkers: edge cases of including the world for rare situations but YAGNI in real production systems. 1. could output flat b…

0. It does dynamic linking on most stdlibs (libc, etc) 1. What do you mean self-hosted runtime? Anyways, golang will likely never be a good candidate for kernel development, but in theory you could do it (go supports assembly) 2. Generics would be nice. Who knows, maybe they'll be in 2.0? Go wasn't developed in llvm, because they wanted to build something very fast, and they were planning on writing the compiler in g…

> What do you mean self-hosted runtime? Anyways, golang will likely never be a good candidate for kernel development, but in theory you could do it (go supports assembly)

Oberon, AOS, EthOS, Singularity and Midori projects prove otherwise.

Go just needs an OS research PhD student proposing "Goberon" to their tutor.

Re: Go 1.6 is Released

#237

Post by pjmlp »

meddlepal wrote: post #40
sinatra wrote: post #33

Earlier quoted context omitted.

Yes, I'd say modern Java is a good candidate too. However, the verbosity is a deal-killer for me. Go's error handling can be verbose, but while scanning the code, if I want/need to, I can easily skip through the error handling parts mentally. Java, though, is verbose everywhere. EDIT: Actually mtrn said it better: Java feels over-engineered.

Okay, ditch Java if it's too verbose and adopt one of Kotlin, Groovy (w/ @CompileStatic) or Scala.

I would forget about Groovy and focus in Scala, Clojure, Kotlin instead.

Here in Germany you almost don't hear about Groovy anymore in any JUG event.

If it wasn't for Gradle and Android adopting Gradle, I bet we would hear even less about it.

Re: Go 1.6 is Released

#238

Post by pjmlp »

hacknat wrote: post #194
aikah wrote: post #179

Earlier quoted context omitted.

> 2. Generics would be nice. Who knows, maybe they'll be in 2.0? There will be no 2.0 and there will be no generics, at all.In fact there will never be any changes to the type system, cause it's impossible at this point.

Not that I even care that much, but that's total crap. Compile-time generics, which is what most people seem to be referring to when they say they want generics in Go, are eminently doable. It would not be hard to implement. Runtime generics are probably possible as well. What are you even basing your assertion on? Edit: What do you mean, "there will never be a 2.0"? Do you have a crystal ball?

The team has already stated "The language design is done".

Re: Go 1.6 is Released

#239

Post by _0w8t »

sinatra wrote: post #5

Go checks a lot of boxes for my ideal language for developing web services: Static type, C derived, has garbage collection, generates a single binary, supports concurrency very well, is opinionated, is small/simple, its community prefers to just use standard lib for most work, etc. Yes, Generics is an issue and so is debugging. But, overall, I can't think of many other options that check so many boxes. EDIT: I must h…

Go tools support code generators. So just use those for advanced data structures. As auto-generated it can support more features than even an advanced generics could provide.

For me the big minus of Go is that it is memory unsafe language when it runs with GOMAXPROCS>1 (default since 1.5). It is not that bad like in C as opportunities for bugs are not common, still this is an issue as consequences of such bugs is arbitrary code execution.

Another problem is lack of union types leading to poor code practice when those are emulated through (foo, err) or similar return types.

Re: Go 1.6 is Released

#240

Post by aktau »

pcwalton wrote: post #173
jerf wrote: post #171

Earlier quoted context omitted.

The list of languages that permit that in a principled way is short, and the list of languages where it's a good idea is even shorter. I've come to the conclusion that it's generally not a good idea. (And it's not Go making me say that, it's more Haskell.) Keeping dependencies flowing in one direction seems to be a good plan.

I totally disagree. It's not only a good idea, it's essential for certain core functionality to work at all. Take serialization, for example: without this feature it's impossible to write a good serializer as a library without code generation (messy and brittle) or reflection (very slow). To give another example, try writing a linear algebra library that's generic over the data type without this feature (and such lib…

> To give another example, try writing a linear algebra library that's generic over the data type without this feature (and such libraries are essential for high performance graphics programming).

I disagree. My best, fastest to compile code has always focused on just one type. You mention graphics programming: for 99.999% of the cases you want to pick a type. Usually, this will be float, and thus for SIMD a 4 or 8-vector of these, like https://github.com/aktau/threedee-simd/blob/master/include/t.... Despite the support of recent graphics cards for doubles, the fact is that they are usually quite a bit slower. Even when precision bound, there are usually tricks that will let one keep using floats (esp. wrt to Z-buffers).

Post reply on HN