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

A little Golang way

aerofs.com

Post reply on HN
Print view View original

121–130 of 194 posts

Re: A little Golang way

#121

Post by mavelikara »

I have a question on Go's performance that I'd like someone here, who has experience writing programs in it, to help shed some light upon.

1) Go does not have a runtime. This means that there is no JIT to do any optimizations based on runtime profiling.

2) Go is also designed to compile fast. Since it compiles fast, the compiler's time budget to do compile-time optimizations is small and it probably can't do the best job possible.

Are these two points accurate? If so, how does Go perform as well as it is claimed to do? Where is the catch?

Re: A little Golang way

#122

Post by omginternets »

swah wrote: post #113
omginternets wrote: post #38

Earlier quoted context omitted.

I think Go invites comparison to dynamically typed languages because it's compiler is so damn fast. Yes, Go is technically compiled, but the development cycle is closer to that of dynamic languages. In a similar vein, I have a lot of trouble taking criticism of Go's type system seriously. Is it as robust as Rust's? Probably not (I've never used Rust), but that's way beside the point. Go's type system gives you a grea…

Me too. Some folks prefer to think instead of messing with the code and retesting. I hate it.

I honestly prefer to do both. Picking the right tool for the job implies that you've thought a great deal about your requirements.

Plus thinking is an enjoyable and rewarding experience.

Re: A little Golang way

#123

Post by mratzloff »

eropple wrote: post #33
travjones wrote: post #25

There have been several blog posts and conference presentations with a similar theme -- "Go is efficient, especially compared to X." I know it seems like hype, but I encourage others to try Golang out, maybe even slap a web app together with it. What you'll find is that your Go app will be extremely efficient and performant. It's kind of unfair to compare Go to many of the other languages of the web because it is com…

> What you'll find is that your Go app will be extremely efficient and performant. This is true, for sure. But my experience--and I've written plenty of Go, though I find it unpleasant to write and think about for all the usual reasons that Go partisans roll their eyes and so would rather deal with it as artifacts rather than actually writing it--has led to watching lots of developers make mudball codebases in the pr…

> But my experience--and I've written plenty of Go, though I find it unpleasant to write and think about for all the usual reasons that Go partisans roll their eyes and so would rather deal with it as artifacts rather than actually writing it--has led to watching lots of developers make mudball codebases in the process (while blogging very heavily about how great it is three weeks in, and less a year-plus in).

I get what you're saying, and I agree with some of the criticism around the tooling, although I do think much of that owes to the age of the language. There are some specific things in the (sometimes rather cranky) replies to you that I think are incorrect but I'm not going to debate the merits of the language. Use it if you like, don't use it if you don't.

I will say that we've been using Go for nearly all back end services for nearly 3 years now, and we all still think it's pretty great. Our code base has also remained pretty clean, and in fact we're investing more heavily in Go going forward.

Re: A little Golang way

#124

Post by cgag »

chadaustin wrote: post #84
grey-area wrote: post #75

Earlier quoted context omitted.

reinventing a lot of Java-1.4-era (because the language itself is essentially that) design patterns Really? Java 1.4 had an extensive and consistent standard library, implicit interfaces, composition instead of inheritance, static builds, and built-in concurrency? Go is not early Java, it's more like C 2.0, and I don't really see anything faux about the simplicity, it really is pretty simple, perhaps too simple for s…

> extensive and consistent standard library yes > implicit interfaces no > composition over inheritance yes > static builds no > built-in concurrency sure, with an 1:1 thread model as opposed to an M:N thread model. M:N is not always a clear win over 1:1: https://mail.mozilla.org/pipermail/rust-dev/2013-November/00... http://xiao-feng.blogspot.com/2008/08/thread-mapping-11-vs-m... Also, to be very clear, Java's threa…

I don't know if the programming model of threads and channels that's used by haskell and golang strictly depends on the existence of M:N threading, but it sure is nicer to use than the model in java/rust.

Re: A little Golang way

#125

Post by dragonwriter »

cgag wrote: post #124
chadaustin wrote: post #84

Earlier quoted context omitted.

> extensive and consistent standard library yes > implicit interfaces no > composition over inheritance yes > static builds no > built-in concurrency sure, with an 1:1 thread model as opposed to an M:N thread model. M:N is not always a clear win over 1:1: https://mail.mozilla.org/pipermail/rust-dev/2013-November/00... http://xiao-feng.blogspot.com/2008/08/thread-mapping-11-vs-m... Also, to be very clear, Java's threa…

I don't know if the programming model of threads and channels that's used by haskell and golang strictly depends on the existence of M:N threading, but it sure is nicer to use than the model in java/rust.

It doesn't strictly depend on it, but it is strongly supported by M:N threading since that threading model decouples the supportable degree of concurrency from the supportable degree of parallelism (unlike 1:1), without abandoning parallelism (unlike N:1).

You can do Erlang-style concurrency with 1:1 or N:1 threading models (and there are libraries for languages whose many implementations are N:1 or 1:1 rather than M:N that do that), but it makes most sense when you have M:N.

Re: A little Golang way

#126

Post by pcwalton »

slapresta wrote: post #114
pcwalton wrote: post #62

Earlier quoted context omitted.

> First, gofmt can do more than code formatting, such as applying simplifying code transformations that are semantically equivalent Which also has nothing to do with design patterns. (At least not if you're limited to the extremely basic -r gofmt rewrite rules.) > Second, code formatting and design patterns are indeed related, because the way code is laid out in text is the way that design patterns are expressed. The…

> No, I don't buy that a code formatting tool obviates the need for design patterns. How does gofmt replace the Visitor pattern (just to pick one at random from the GoF)? Asking if a code formatting tool "obviates the need for design patterns" is the wrong question, because it assumes that there is a need for design patterns in the first place. I do agree with you that a code formatting tool is not capable of somehow…

You do need design patterns in Go. A prime example: the interface that Sort() requires is basically the Strategy pattern. You need it in Go because the language is missing generics. There are many other examples.

In that message, Rob Pike misunderstands what the visitor pattern is for. Go's "type switch" is just chained Java instanceof. Java still benefits from the visitor pattern for (e.g.) compiler transformations, even though it has instanceof.

Re: A little Golang way

#127

Post by flippant »

mavelikara wrote: post #121

I have a question on Go's performance that I'd like someone here, who has experience writing programs in it, to help shed some light upon. 1) Go does not have a runtime. This means that there is no JIT to do any optimizations based on runtime profiling. 2) Go is also designed to compile fast. Since it compiles fast, the compiler's time budget to do compile-time optimizations is small and it probably can't do the best…

1) Go has a runtime that's included in the binary that you get when you run `go build`. It takes care of garbage collection, goroutines etc. It does not do any JIT compilation afaik.

2) Go compiles fast because it gives up a lot of modern features (namely generics).

Re: A little Golang way

#128

Post by coldtea »

vorg wrote: post #89
travjones wrote: post #25

There have been several blog posts and conference presentations with a similar theme -- "Go is efficient, especially compared to X." I know it seems like hype, but I encourage others to try Golang out, maybe even slap a web app together with it. What you'll find is that your Go app will be extremely efficient and performant. It's kind of unfair to compare Go to many of the other languages of the web because it is com…

> slap a web app together with it Web apps are on the decline, being gradually replaced by Android/iOS apps. When people can use Go to slap up a performant Android app, it may find more use.

Nobody cares about Android apps. And they ain't gonna make you rich. Neither will iOS apps for that matter. That's a market raced to the bottom, that only makes sense for a few top players.

The web is not going away anytime soon.

Re: A little Golang way

#129

Post by dragonwriter »

slapresta wrote: post #114
pcwalton wrote: post #62

Earlier quoted context omitted.

> First, gofmt can do more than code formatting, such as applying simplifying code transformations that are semantically equivalent Which also has nothing to do with design patterns. (At least not if you're limited to the extremely basic -r gofmt rewrite rules.) > Second, code formatting and design patterns are indeed related, because the way code is laid out in text is the way that design patterns are expressed. The…

> No, I don't buy that a code formatting tool obviates the need for design patterns. How does gofmt replace the Visitor pattern (just to pick one at random from the GoF)? Asking if a code formatting tool "obviates the need for design patterns" is the wrong question, because it assumes that there is a need for design patterns in the first place. I do agree with you that a code formatting tool is not capable of somehow…

All languages need design patterns; they are about designing how to implement certain functionality.

Languages differ in which design patterns have a native expression in the language, which can be reduced to simple reusable library code, and which require type-it-in-each-time fill-in-the-blanks code recipes.

The fact that Design Patterns were popularized in software development by the GoF book which, among other things, included code recipes to illustrate its patterns, and that the patterns in it tended to be ones for which the popular languages of the day required code recipes (lacking native implementations or the ability to provide general implementations as library code), has unfortunately associated the term with the code recipes, which aren't really the central point of understanding and using patterns.

Re: A little Golang way

#130

Post by pcwalton »

cgag wrote: post #124
chadaustin wrote: post #84

Earlier quoted context omitted.

> extensive and consistent standard library yes > implicit interfaces no > composition over inheritance yes > static builds no > built-in concurrency sure, with an 1:1 thread model as opposed to an M:N thread model. M:N is not always a clear win over 1:1: https://mail.mozilla.org/pipermail/rust-dev/2013-November/00... http://xiao-feng.blogspot.com/2008/08/thread-mapping-11-vs-m... Also, to be very clear, Java's threa…

I don't know if the programming model of threads and channels that's used by haskell and golang strictly depends on the existence of M:N threading, but it sure is nicer to use than the model in java/rust.

Why is it nicer to use than that of Rust?
Post reply on HN