Live data from Hacker News

Rewriting a large production system in Go

matt-welsh.blogspot.com

151–160 of 196 posts

Re: Rewriting a large production system in Go

#151
post #93
post #86

The number of strongly typed garbage collected compiled languages is surely shrinking. I can understand someone's disgust towards Java considering dwindling velocity in adding next-gen features and now sleeping in same bed as lawyer run Oracle. That pretty much had left C# in the arena until Go came on the scene. I was honestly hoping Go would give us head-to-head battle with C# but from initial looks Go pretty much…

Yep, Go would be hardly mentioned here if it wasn't being developed at Google. Having said this, Go can be a nice replacement for many use cases one would use C for.

This isn't a fair statement. A better statement would be "Go would be hardly mentioned here if it weren't for all of the effort and documentation put into it." There is no doubt though that Go would not be moving along so quickly if it weren't for Google, but I think this is a case of 'correlation is not causation.' Dart comes from Google also, and while I see it from time to time here, nowhere like I do Go. Myself, I tend to trust and prefer Mozilla as a company more. That said, I find Rust not only unusable, but really too big of a language. I find Go the perfect mix of features I desire, and I cannot be the only one. So, I like Go as a community and as language and certainly not because Google is behind it.

Re: Rewriting a large production system in Go

#152
post #93

Earlier quoted context omitted.

Yep, Go would be hardly mentioned here if it wasn't being developed at Google. Having said this, Go can be a nice replacement for many use cases one would use C for.

Go seems to be gaining traction. Does it matter if that's because of where it came from? Maybe in a cultural, I-want-to-think-about-why-some-languages-get-adopted sense, sure, then it can matter. And I think it's worth having those discussions. But I get the impression that people think there's some absolute injustice in the idea that people are adopting a language, and it's partly because it's from Google. Consider:…

It matters if you try to count backwards from popularity to quality, by correcting for other factors.

Re: Rewriting a large production system in Go

#153

Earlier quoted context omitted.

No, we can just see the "if err != nil". It's still there in Java or Ruby or Python, lurking in the notional space between the lines and waiting to branch to an exception handler you installed in the caller's caller's caller.

Same in Go, because of panic and recover. For example, "foo.Bar", if foo is a nil pointer, can invisibly branch to an exception handler you installed in the caller's caller's caller.

Can but idiomatically, usually does not. In most code, that would behave like a segfault with a more helpful crash log.

Re: Rewriting a large production system in Go

#154
post #134

Go is a nice language with awesome features except that it doesn't fucking allow unused imports/variables. It makes exploratory programming with Go annoying as hell.

    don't {
        print x for {x : unused variables}
        x() for {x : function from unused imports}
    }

Re: Rewriting a large production system in Go

#155
post #23

Earlier quoted context omitted.

If I'm going to use Go, or any language, I definitely want to use it idiomatically. Don't fret, if this were eight years ago you'd have seen me railing on significant whitespace. And we all know how that went.

> If I'm going to use Go, or any language, I definitely want to use it idiomatically. Idioms evolve, and they evolve because they are challenged.

fine, but I've learned enough languages to know that the absolute worst thing you can do when you start out with language Y is make it act just like your previous language X. It's a very natural instinct for almost everyone (just read "Python is not Java" for an example), but for at least the first year or two of using a new language I think you have to do it as idiomatically as possible, before you have any insight into how to challenge the designer's idioms.

Re: Rewriting a large production system in Go

#156
post #150

Earlier quoted context omitted.

Did you ever actually use Go for a few minutes? Most of these bullet points are plain wrong.

Would you care to elaborate on this?

  * Their implementation sucks so much that most decently built
    concurrency implementation will beat Go-routines by a wide
    margin. Just have a look at all those people on the Go mailing
    list whining about the scheduler. Not even talking about the
    fact that building concurrency mechanisms into the language is
    plain stupid. We all saw how well that worked out in plenty of
    other languages before.
  * You know why pretty much no one uses structural typing?
    It's not because the “brilliant” designers of Go “invented” it,
    it's because most language designers realized that it is a poor
    idea before shipping the language. I think it is pretty telling
    that in languages which support both nominal and structural
    typing pretty much nobody is using structural typing.
  * I'm not seeing how a language which requires passing around
    void* pointers in every data-structure and casting at pretty
    much every corner can be considered memory efficient.
  * Hard-coding collection classes with special cased syntax into
    the language, so that everyone who needs to have something
    slightly different is completely fucked ... what is this? 1980?
  * Their packaging system is an unmitigated failure. Nuff' said.
  * Do they have a working Unicode implementation yet (I mean more
    than the “We use UTF8 for strings ... which is like 0.5% of
    what Unicode is about”)? What about (Big)Decimal? A working
    date/calendar abstraction which isn't a terrible joke?

Re: Rewriting a large production system in Go

#157
post #2

> If I could get out of the 1970s and use an editor other than vi, maybe I would get some help from an IDE in this regard, but I staunchly refuse to edit code with any tool that requires using a mouse. So you've shown that Go is appealing to rigid curmudgeons. Personally I'm still hung up on the "every function (edit: that does anything which might itself return an error code, which in large scale code is quite a lot…

Exceptions are just glorified gotos. The longest single time in my life chasing a bug was because an exception was firing somehere down udner and nobody noticed, because it was kind of part of the logic but a fringe case.

this is a thoroughly debunked argument that Joel tried to make. Unlike goto, exceptions have stack traces, so when used correctly, their source and propagation are immediately obvious and traceable. An unreported exception in your buggy program is certainly no worse than an ignored error code.

Re: Rewriting a large production system in Go

#158
post #98
post #2

> If I could get out of the 1970s and use an editor other than vi, maybe I would get some help from an IDE in this regard, but I staunchly refuse to edit code with any tool that requires using a mouse. So you've shown that Go is appealing to rigid curmudgeons. Personally I'm still hung up on the "every function (edit: that does anything which might itself return an error code, which in large scale code is quite a lot…

That is exactly because of those type of developers in the industry that the latest Bret Victor's talk is so interesting http://vimeo.com/71278954 Basically he goes on to show how many people still code like the 70's instead of adopting languages and paradigms that were already possible in late 60's systems.

i hate watching videos but yes, this is really interesting - von neumann: "I don't see why anyone would need anything other than machine code". I deal with the resistance thing a lot in my work with ORMs, I should integrate some of this into my writing.

Re: Rewriting a large production system in Go

#159
post #57

Earlier quoted context omitted.

The Go module system for sure. Also I really like Go's interface model (as opposed to Java or C++ classes) as it is more flexible and in some ways more precise. Note that I don't know Ruby so I can't compare Go to that...

Thanks for the article, it was a very interesting read! Since this always comes up in Go discussions: did you miss generics in this project or was the lack of generics a non-issue?

I haven't found that I needed generics so far, though I can see places where they would be useful.
Post reply on HN