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

91–100 of 367 posts

Re: Go 1.6 is Released

#91

Post by voidlogic »

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…

>so is debugging

Have you used delve? https://github.com/derekparker/delve

Re: Go 1.6 is Released

#92

Post by 0942v8653 »

junkblocker wrote: post #69
Cyph0n wrote: post #51

Earlier quoted context omitted.

Thanks, it turns out I actually starred that already. A bit off topic: why isn't there (or is there?) an easy way to view all your starred repos on Github and search through them?

Does https://github.com/stars not work for you?

(It's listed under your profile picture in the top right; to get to your stars, just click it and choose "Your stars")

Re: Go 1.6 is Released

#94

Post by [deleted] »

Cyph0n wrote: post #20
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#.

The way I see it: 1) Go produces 100% portable code. I absolutely suffered doing the same for a very basic C++ program that used C++11's std::regex. Compiled fine on clang-3.5 on OS X, fails on clang on Linux. It took me hours of searching online to find and install the exact version of GCC that actually fills in std::regex instead of just keeping it empty. Trust me, there are some versions that do that! No errors du…

[deleted]

Re: Go 1.6 is Released

#95

Post by EugeneOZ »

jonesb6 wrote: post #32

The reason I love Go is that every time I pull it out, I write a small amount of it and it runs beautifully. For example my company has a critical micro-service implemented in ~300 lines of Go, it's been running for six months now without a single hiccup, highly performant, very sexy. The reason I will almost never use Go for web apps is because interaction with databases is limited (almost entirely) to raw queries.…

How different are people :) I personally prefer raw db queries as more flexible and performant way :) "Typing is not the bottleneck" (c) GeePawHill

Re: Go 1.6 is Released

#96

Post by lobster_johnson »

jdcarr wrote: post #90
lobster_johnson wrote: post #60

Earlier quoted context omitted.

For me, I like Go's slim profile. Native compilation, aggressive allocation, low memory usage, static compilation. JVM suffers from slow startup times and tends to eat a lot of RAM, even when the app doesn't technically need it around. It has an object model that spawns a bazillion tiny objects, and much of the JVM's GC design exists to cancel out those tiny object allocations. JVM has many upsides (the portability a…

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

Command-line programs.

Re: Go 1.6 is Released

#97

Post by hacknat »

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 golang from the start (so that it could be part of the libs). Also having your own scheduler kind of breaks debugging, you can build go programs with gccgo, but gdb doesn't work because it has no concept of what a "go routine" is. Delve (https://github.com/derekparker/delve) will eventually fill the hole of the missing debugger, imo.

Edit:

Formatting

Re: Go 1.6 is Released

#98

Post by hans0l074 »

jbeja wrote: post #82
autoreleasepool wrote: post #43

Earlier quoted context omitted.

I don't like Oracle. I don't like the JVM. I refuse to learn Java because I personally have a strong bias for native, compiled code. In fact, I really dislike everything about the Java way of programming. The mental image of a huge ram sucking IDE with code completion for frameworks is simply incompatible with what I would consider the ideal creative process for me as programmer. That being said, if I were starting a…

"I don't like Oracle. I don't like the JVM." You could just save yourself some (a bunch) of typing stopping there. All the other reason make you look like a clown.

Your comment is quite cryptic imho, and there is no need to respond in this fashion. Can you elaborate?

Re: Go 1.6 is Released

#99

Post by skybrian »

protomyth wrote: post #78

Can someone give a decent explanation of the following: 1) Supposed I have a library that was written in C that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled version of the Go program. 2) Supposed I have a library that was written in Go that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled vers…

Best to assume that you will need to recompile a Go program yourself. If you don't have the source and know how to build it, you're in trouble.

Re: Go 1.6 is Released

#100

Post by jerf »

mtrn wrote: post #26
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.

I am reading and writing Go and Java almost daily. Java has a tendency to be written in an over-engineered way. The Go community has an inclination towards cautious abstractions. Take interfaces. In Java you might start with them. In Go - in the best case - they emerge, when it's time for them. Java has more mature tooling, but then, I cannot remember gathering runtime insights with Java quicker than with Go pprof[1]…

"Take interfaces. In Java you might start with them. In Go - in the best case - they emerge, when it's time for them."

And it's a relatively subtle language feature that does this, the way that any struct that implements a given interface automatically conforms to that interface without having to be declared. Which means you can declare an interface that foreign packages already conform to, and then freely use them. Which means that you can code freely with concrete structs to start with, and then trivially drop in interfaces to your code later, without having to go modify any other packages, which you may not even own.

I completely agree that on paper Java and Go look virtually identical. But the compounding effect of all those little differences makes them substantially different to work with. Good Go code does not look like good Java code. You'd never confuse them.

Post reply on HN