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

A year with Go

vagabond.github.io

Post reply on HN
Print view View original

181–190 of 235 posts

Re: A year with Go

#181

Post by waps »

jballanc wrote: post #120
tptacek wrote: post #113

I could be wrong, but I feel like when people talk about how great the Golang tooling is, what they're really saying is "the compiles are instantaneous". I'm sure he's right that the coverage tool isn't 100% perfect, or even 60% perfect. OK. Fine. The compiles are instantaneous . Write a better one! Golang is not an especially impressive programming language --- as a language. But it seems to me like it is an undenia…

I completely agree. Some languages are written to adhere to an ideal (everything is lists), and make sacrifices in order to stick to that ideal. Some are written to be close to the metal, or to be as abstract and flowery as possible, and make different sacrifices. Every language has some primary goal, and all the rest must bend to accommodate that goal. Go's primary goal is: excellent tooling.

But Go's tools suck ...

Debuggers - http://blog.securitymouse.com/2014/10/golang-debugging-turni...

Code analysis tools - aside from "go fmt" ... don't know any. There's certainly nothing compared to the C++ tooling.

Versioning - nonexistent

Editors, IDEs - nonexistent

Re: A year with Go

#182

Post by codygman »

crimsonalucard wrote: post #95
codygman wrote: post #84

Earlier quoted context omitted.

As someone who used Go in the past for work and now uses Haskell, I can say that the advantages of Haskell over Go are more than "just theoretical". In my day job I use Haskell to "just get shit done". However when it comes time to refactor I can do it much faster and safer in Haskell. The ease of refactoring creates an incentive to improve code.

Seems like Go and other imperative languages are easier to start a project off with, but functional languages really shine when the code becomes really large and complex.

I can agree with that, but once you are experienced with functional languages I think "easier to start off with" becomes a very low value. I'm assuming by start off with you solely mean "starting a new project" and not "starting to use language from scratch".

At least that seems to be what has happened in my case.

Re: A year with Go

#183

Post by tmsh »

What's confusing about Go, in comparing it to other languages, is that it's a minimum orthogonal refactor of a language. It was born out smart engineers observing the web and other languages for decades and thinking that they needed something low level but high level enough. It's built staring precisely at the past two decades.

C, C++, Java, Python, and an appreciation of formal specs over frameworks form Go.

Most languages to perform professionally in you have to know what not to do (not use C++ templates too much, not give into verbosity in hierarchies in Java, not use the GIL, etc.). In Go, because it is a relatively clean refactor, you don't have to worry about this.

But you do have to invent your own smaller libraries for what you want to do sometimes. Because it's a younger language. This is good though if you like programming and stacking lego pieces on you way to stacking paper.

Re: A year with Go

#184

Post by waps »

nosequel wrote: post #129
Alphasite_ wrote: post #89

Earlier quoted context omitted.

Yeah. But you don't have to, you're literally complaint that the user has options. It's not like Go doesn't have a GC either.

Exactly, and Go's GC is years behind the JVM.

2 things play in favor of Go on memory usage though:

1) Go is in honeymoon phase. There aren't any 10 million plus lines of code Go codebases. So "Go is not complex".

That said in java-land there is often not a very good reason for complexity. I just examined a GWT job scheduling tool and for displaying fields in the UI they had 5 interworking classes - just to avoid manually coding the dialog. In java-land people constantly do that - why ? They had recordbuilders and ui-from-record-builder and ...

That said, these days you see people using Go's introspection to create dialogs in javascript - that was a lot more complex still.

So while the length of backtraces in Go's crashes has been steadily going up, it seems to be at around 6-8 levels deep these days. I have to say though, I much prefer panics and exceptions over Go's error handling (or as you will come to see it after seeing what "average" programmers do with the errors - Go's error ignoring)

This honeymoon also means the amount of idiot-written code in Go is much smaller than in Java. Also, a lot of code in java was written to the previous sets of programmer fancies. Half the libraries you use in a particular project are XML configured, because that was the best practice in 2000-2005 (even still visible in things like android apps), another set is using dependency-injection patterns, another set requires POJOs and uses introspection, and the last set has it's own custom configuration language (I hate gradle, and yes this is because just doing things with cli tools is apparently not done in java-land, I don't care).

2) Go has a better memory model than Java. Because you can nil out every java object, every java object has to be a pointer. So initializing an object that contains 5 other objects requires 6 heap allocations and constructor invocations - minimum. After construction the GC has a new tree of 6 objects to walk on every invocation.

This is not the case in Go (uninitialized non-pointer objects aren't nil, you only use pointers where you actually need them), and results in much more compact memory. I see it as a flaw in java these days.

Re: A year with Go

#185

Post by merb »

coldtea wrote: post #150
sagichmal wrote: post #147

Earlier quoted context omitted.

> If you were a strong C, C++, Java, Scala, Clojure etc > developer you could equally deliver a highly scalable > solution in 2 hours. I guess the point is, no, you couldn't. An equivalent solution would be less robust/reliable or take (much) longer. Or both.

With some of this languages it would have been much faster AND much more reliable.

I think the language doesn't matter It has more Ton so with Ohr Brain. Sole People feeling Continental with go sind bot. Sole Need generis Sole not. Language doesn't matter too much Write The Language which Young Feel is right foR the job

Re: A year with Go

#186

Post by gambiter »

samora wrote: post #170

I think a lot of us miss the Go point. There is nothing special about Go. It's simple and just works. Every time I used Go for a project it just worked. No fuss. With very little effort. And that's the point.

But that doesn't answer any of the (very valid) points raised in the article?

Go is interesting as a replacement for a scripting language, perhaps. But it seems very lacking in many other areas. All of the points in the article, plus what libraries are available.

I think some of it could be explained by it being a young language, but if that's the case, why is it getting the adoption it has so far? Just because it came from Google?

Re: A year with Go

#187

Post by NateDad »

serge2k wrote: post #175
jballanc wrote: post #120

Earlier quoted context omitted.

I completely agree. Some languages are written to adhere to an ideal (everything is lists), and make sacrifices in order to stick to that ideal. Some are written to be close to the metal, or to be as abstract and flowery as possible, and make different sacrifices. Every language has some primary goal, and all the rest must bend to accommodate that goal. Go's primary goal is: excellent tooling.

except for, apparently, poor code coverage tools?

The coverage tool is fine. He didn't really explain the problem well. Coverage is per package, and only counts coverage from tests in that package. This makes sense because packages are independent and you can't count on another package to test yours.

Re: A year with Go

#188

Post by NateDad »

serge2k wrote: post #177
NateDad wrote: post #139

Earlier quoted context omitted.

Really, all I need is gofmt on save, and even that is mostly because I've gotten so used to it that I drop ugly unformatted dreck into my editor and let gofmt clean it up. I worked full time for year without go to definition, mostly because full text search is almost as good most of the time, due to how regular formatted go code is. I don't really use anything else, mostly because I don't need anything else and I hav…

I really don't get the amount of love for gofmt. It's a formatter. wow! amazing! That's never been done before.

Yes, but it had the One True Format, which is the only way it can possibly work. I've used a formatter at other jobs in other languages, and you end up having your formatter fighting with everyone else's, unless they're configured exactly the same, which no one can ever agree on.

Re: A year with Go

#189

Post by NateDad »

Dewie3 wrote: post #166
jerf wrote: post #65

Earlier quoted context omitted.

"code is often needlessly repetitive and obtuse to write." I think it helps to remember that Go's use case is a lot of teams interacting to produce fairly large code bases, i.e., at Google. I'm getting into it for my job because it has the same use case, and I find it hits a nice sweet spot in what you can do, vs. what you can't do, and I happen to be in a position in which I am routinely hit hard by other people's "…

The Java approach to larger-scale programming.

Which, uh, has been very successful for java.

Re: A year with Go

#190

Post by vezzy-fnord »

nemothekid wrote: post #103
seanmcdirmid wrote: post #94

Earlier quoted context omitted.

It is not unprecedented, e.g. see: http://en.wikipedia.org/wiki/Crash-only_software Martin Rinard at MIT has done a lot of work in this area. It can be safe if you can rollback to a good state to avoid data corruption. Glitch, my current project, does not bother with reader locks for multi-core execution; instead it can rollback and retry when a write-after-read is detected effects are logged (dependencies are traced…

I'm aware of crash only software (isn't this how Erlang/OTP does things?), however this doesn't seem to be what the OP intended. Running your code without caring about data races means your data can be corrupted and program might not crash.

In this case, it's different. The Erlang/OTP approach involves maintaining internal supervisor trees that are bound to the semantics of the VM and its language constructs, whereas the author's involves using an OS process supervisor (daemontools) to just reexec the program every time it crashes/hangs. The potentials for data corruption and tainted state is higher in the latter, though it's still relatively good for a surprising number of problems.
Post reply on HN