111–120 of 194 posts
Anecdotes like this makes me wonder how much funding money and electricity could be saved if people migrated en masse from Ruby/Python/Something else to Go. (Edit: not meant to be a political statement, more of a practical observation. I only recently started using Go.)
These guys went from 30 servers to 2 by switching to Go. http://www.iron.io/blog/2013/03/how-we-went-from-30-servers-...
Earlier quoted context omitted.
> Statically linking your SSL library makes you an asshole...Heartbleed 2.0. Go has its own SSL library, crypto/tls, which is not linked to any C libraries and wasn't affected by Heartbleed 1.0. You haven't written much Go if you don't know that. The argument is specious anyway, there's nothing difficult about building a binary from an old version of your code or just upgrading in most cases. Deploying a new Go binar…
"Go has its own SSL library, crypto/tls, which is not linked to any C libraries and wasn't affected by Heartbleed 1.0." Is it going to be affected by Heartbleet 2.0? How about whatever the next exploit is? "The argument is specious anyway, there's nothing difficult about building a binary from an old version of your code or just upgrading in most cases." Not in every case, and not for customers who don't have access…
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…
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…
Earlier quoted context omitted.
> gofmt is about code formatting. Design patterns are about abstraction and expressiveness. First, gofmt can do more than code formatting, such as applying simplifying code transformations that are semantically equivalent. 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 layout of code affects how abstractions a…
> 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…
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 fixing software design and architecture decisions. However, "design patterns" by their GoF meaning exist as to address shortcomings of the languages and tools used: most of their advice does not make sense as soon as you move away from Java into less object-oriented or less procedural languages. To talk about "the need for design patterns" as if they are some sort of mathematical truth is misleading and dangerous.
So, yes, I would argue that Go does not need the Visitor pattern (and so would Rob Pike [https://groups.google.com/forum/#!msg/golang-nuts/3fOIZ1VLn1...] ), code formatting tool notwithstanding.
Earlier quoted context omitted.
There are times when a step back is the mandatory step to get a new perspective on things. Just sayin'.
But this is a step back to the cold, dead, static systems of UNIX. How about stepping back and taking a look at the dynamic, hackable environments of Lisp?
Further, if I wanted maximum dynamism and runtime hackability I'd go for a Smalltalk.
> Resident memory usage dropped from 87MB down to a mere 3MB, a 29x reduction! This isn't so much Java vs. Go as it is JIT/interpreted vs. AOT-compiled. The numbers are entirely typical across a wide range of such comparisons. With an interpreter or JIT, you need to load all your code at startup and process it. Generally, _all_ of your dependencies need to be loaded and parsed upfront, either converted to some intern…
Earlier quoted context omitted.
If you're concerned about Go, you might also find better results with Rust or Nim. Both are up-and-coming in similar spaces to Go.
Go isn't going away anytime soon. Neither is Rust. You shouldn't choose Rust over Go because of fear of the language being abandoned. (I'm not too familiar with Nim's community so I can't speak to it.)
For the record, I've chosen to use Go over alternatives, although Nim sings to my very soul.
Earlier quoted context omitted.
I'm not sure what you'd expect a microservice with a straightforward bit of logic and a single HTTP route to actually cost in terms of lines? I suspect the same (or greater) linecount gains could have been gotten by using a language even more pithy. How much you wanna bet the equivalent Clojure or Scala versio would be half again as many lines?
> How much you wanna bet the equivalent Clojure or Scala version would be half again as many lines ? 263 lines?
Clojure is quite terse, and Scala can be when you're using the right toolsets.
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…
Java's "green threads" were N:1 threads, not M:N threads. While both are sometimes referred to as "green threads", they are very different things. (N:1 tends to give cheap concurrency but no parallelism, M:N tends to give cheap concurrency with as much parallelism as the hardware can handle, but with more overhead than 1:1 threads.)