the only thing that's preventing me from jumping on the Go bandwagon is lack of a nice collections library (a la lodash).
A little Golang way
61–70 of 194 posts
Re: A little Golang way
#62Earlier quoted context omitted.
> Because the tooling was a first-class design goal, a number of the problems that traditional design patterns were created to address are less problematic in Go code[1]. > [1] Again: gofmt… What does gofmt have to do with design patterns? gofmt is about code formatting. Design patterns are about abstraction and expressiveness. A code formatting tool does nothing to address abstraction and expressiveness of the langu…
> 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 layout of code affects how abstractions are presented, which affects which abstractions are easy to reason about and work with.
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)?
Re: A little Golang way
#63"Code size was reduced by almost half, from 175 lines down to 96." Hm, I how can we take a 175 LOC project as something relevant in any way?
The idea is that a server this small should probably not consume oodles of memory. They reduced RAM footprint by 100x. Apparently, their Java implementation of this toy service was wildly out of hand. I wish they provided the JVM startup info and stats to compare. Maybe JVM's resource usage could be shrunk, too.
As much as I am a fan of go, this sounds like it's a bad build infrastructure more than any fault of Java. JAR shading exists, their imports were probably out of hand (and significantly unused), and while they were microservices, they probably could have had groups of them share a JVM (and benefited from the shared permgen space).
Still, that's time and effort, and in Go you get all of those things for free. There's far fewer janky edges (I spent hours figuring out the problems with signed jars, shaded jars, and symlinks when trying to deploy)
Re: A little Golang way
#64Earlier 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…
> How does gofmt replace the Visitor pattern (just to pick one at random from the GoF)?
This would not be the first time that we have had a discussion on HN about this exact design pattern in Go, so it's hardly a random choice. And given past precedent, I think it's best if I end my half of the conversation here and propose to agree to disagree. To quote my previous post,
> I'm really not interested in starting another flamewar about why Go lacks $X and therefore $Y is better, because we have had enough of those on HN, don't you think?
Re: A little Golang way
#65And the cycle continues, from one crappy enterprise language to the next. I don't who said it, but whoever said "Go is a bold step backwards" is spot on.
Re: A little Golang way
#66Earlier quoted context omitted.
The idea is that a server this small should probably not consume oodles of memory. They reduced RAM footprint by 100x. Apparently, their Java implementation of this toy service was wildly out of hand. I wish they provided the JVM startup info and stats to compare. Maybe JVM's resource usage could be shrunk, too.
> The idea is that a server this small should probably not consume oodles of memory. The number of LOC has no bearing on how much memory something will consume. For all you know the service could just be poorly implemented.
This is true regarding heap space (you can allocate couple gigs in one line), but perm gen space and JIT space can also be significant in JVM case.
Re: A little Golang way
#67Earlier quoted context omitted.
> Go also discourages program extensibility through components Can you elaborate on this? Because in my experience with Go, I found that I had to make _far_ more components (assuming this means libraries?) than other languages. > Statically linking your SSL library makes you an asshole when it inevitably fails and now an application has to be regression-tested so that new features and new bugs don't hose you just bec…
I think the parent was saying that new releases would bring new features the end user may not want, in addition to something like a security fix for an included library. With shared libs, you can keep using an old version if it works for you, while still updating ssl to a fixed version (assuming api compat).
This, precisely. If I have to compile YourApp 1.5 with YourTLSLib instead of just `apt-get upgrade`, I'm going to be sending you flaming karmic poop for your karmic doorstep.
And not just new features--though SemVer is very often honored in the breach more than the observance--but breaking, sometimes undocumented changes (two Go projects, Packer and Terraform, both come to mind).
Re: A little Golang way
#68I'm all for replacing java bloat with a little bit of go, but it seems like the cause of the bloat becoming a real problem was hopping on the docker bandwagon, for a collection of services that always run together in an appliance and really benefited from being hosted in a shared JVM? Isn't the JVM + servlet container thing supposed to be able to isolate the different services? They get their own bunch of threads, an…
You should read Sun's J2EE specs. There is little semantic distinction between a stateless session bean and a container hosted micro-service. The specs were never fully grasped (imo) by the Java community and those who got it (per gossip I heard) -- appserver vendors e.g. IBM, JBoss, etc. -- effectively crippled the spec by resisting the completion of the APIs that would commoditize their containers.
Sun was really ahead of the game in various fronts.
Re: A little Golang way
#69I'm all for replacing java bloat with a little bit of go, but it seems like the cause of the bloat becoming a real problem was hopping on the docker bandwagon, for a collection of services that always run together in an appliance and really benefited from being hosted in a shared JVM? Isn't the JVM + servlet container thing supposed to be able to isolate the different services? They get their own bunch of threads, an…
Traditionally you'd deploy a bunch of apps to one container (Tomcat, or whatever) and they'd all share the same JVM. I'm not sure if jars are shared in this way or not. I think OSGI was supposed to allow deploy apps to reuse the same jars and resources but I don't know how commonly that is deployed.
Now it is more common to run Tomcat or Jetty embedded for your app so that they are isolated.
Re: A little Golang way
#70Earlier 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. You haven't written much Go if you don't know that. The parent poster obviously wasn't saying that crypto/tls was affected by Heartbleed specifically. It was a statement about the security implications of static linking.
[deleted]