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

Everyday hassles in Go

crufter.com

Post reply on HN
Print view View original

191–200 of 297 posts

Re: Everyday hassles in Go

#191

Post by theseoafs »

jondubois wrote: post #123

Statically typed languages impose unnatural hardware-oriented constraints on your business logic - It forces you to spend extra time and effort to make sure that your logic is in a format which the compiler can understand. Yes, this can sometimes help you to find silly errors in your code at compile time (and thus occasionally save you a bit of time) but, unfortunately, that occasional benefit doesn't make up for the…

Have you never used a statically-typed language? Most statically typed languages can handle adding an integer and a float together. The only one I can think of that isn't capable of that is OCaml, though this is probably a strength of OCaml rather than a weakness (int-to-float casting can be a common source of bugs if it happens unexpectedly).

Re: Everyday hassles in Go

#192

Post by Chinjut »

jbooth wrote: post #155
nine_k wrote: post #152

Earlier quoted context omitted.

This, and using something like `Either` / `Result` instead of the `result, error := MethodCall()`. (Alas, the authors of Go seem to consider notions like 'monad' or 'Kleisli category', both pretty simple, impractical.)

Words like 'monad' and 'kleisli category' (which I've never heard of) absolutely REEK of impracticality to me, regardless of the concepts. There's a rule for academic papers where if the author is writing in clear language, he has something interesting to say, and if he's writing in fancy academese, he's probably saying absolutely nothing. I don't really see a huge additional value for your proposed method call seman…

Why should words you've never heard of reek of anything to you? You've never heard of them; you have no idea what they mean!

Re: Everyday hassles in Go

#193

Post by Xorlev »

vardump wrote: post #103
threeseed wrote: post #91

Earlier quoted context omitted.

You don't need to configure the JVM as in many cases the defaults are fine. And most of the frameworks in use today do not require an application server. Go is definitely simple. But I wouldnt characterise modern day Java development as being that complicated.

Well, you don't need the JVM and any dependencies it pulls . That's also worth something in the era of "cloud" services. Less to install. Less to update. Ideally you only need to update the deployed application. Which in case of Go is that one binary. Another big thing is that same app written in Go just takes (significantly) less RAM than when written in Java. Go has arrays (and slices) of structs, not just struct p…

Java also has arrays. And on heap/off heap RAM allocation.

We deploy all our services as uberjars, we have a single Amazon AMI with JDK 8 installed. It's pretty frictionless. It goes from a simple Gradle project, to a single jar on S3, and pulled from S3 by our AMI. Automatically launches via an upstart script.

I'll give you less RAM usage for sure. But when I'm launching a whole VM for a service anyways, I don't care that much. I tend to lean toward Go when I want a low-footprint coprocess for another service, or other small apps.

Re: Everyday hassles in Go

#194

Post by AnimalMuppet »

nine_k wrote: post #161
jbooth wrote: post #155

Earlier quoted context omitted.

Words like 'monad' and 'kleisli category' (which I've never heard of) absolutely REEK of impracticality to me, regardless of the concepts. There's a rule for academic papers where if the author is writing in clear language, he has something interesting to say, and if he's writing in fancy academese, he's probably saying absolutely nothing. I don't really see a huge additional value for your proposed method call seman…

These words are merely unfamiliar . Do you think that 'pointer arithmetic', or 'open-closed principle', or 'abstract class', or 'exception propagation' sound less intimidating for a layman? But in reality none of these are complex after you've put a small effort to comprehend the notions behind them. Specifically, try reading these completely un-academic un-papers. 'Either' monad, with nice kid-friendly pictures: htt…

I've been trying to get my mind around this kind of stuff for maybe a year. And I have to say that monads don't look like the solution to any of the problems that I actually face or have ever faced, in a thirty-year career.

So, no, it's not just that the words are unfamiliar. It's that the problems that they're trying to solve are so abstract that they're completely disconnected from the work that I actually do.

And before you tell me that I'm really doing this stuff without realizing it: Maybe so. That doesn't mean that my life would be improved by doing it explicitly.

It seems to me that the "everything is category theory" approach has the same over-abstraction problem that the Java "AbstractFactoryFactoryFactory" approach has, and deserves to be as frequently mocked.

Re: Everyday hassles in Go

#195

Post by Retra »

kasey_junk wrote: post #180
NateDad wrote: post #175

Earlier quoted context omitted.

This is just not true. Many simple lines are easier to read than fewer more complex lines. It's hard to miss a bug in x = x + 1 foo[x] But easier to miss a bug in foo[x++]

As an industry we have no objective measures for what makes code "better", so in many ways these debates are pointless. That said, I'd add 3 points to this particular thread: 1) You cherry picked one of the most confusing uses of operators (and sources of bugs) that we have. If it weren't so ingrained in our educations/history (and so useful for old fashioned looping semantics) I think we all would have moved on from…

> As an industry we have no objective measures for what makes code "better", so in many ways these debates are pointless.

I don't know why people keep saying this. We write code to solve problems. The best code solves the most problems in the most correct and efficient ways.

Regardless of your measure of efficiency, if someone cannot quickly tell if your code is correct, does what is intended, and does or does not apply to their problem, then the code isn't good.

That's your measure: Can the people who want to solve the problem you are trying to solve efficiently identify, evaluate, and employ your attempted solution?

Re: Everyday hassles in Go

#196

Post by rjberry »

dangerlibrary wrote: post #185
rjberry wrote: post #129

Earlier quoted context omitted.

Sure ... but if a loop is effectively doing a map, a filter, and a bunch of other operations all at once? It's a lot quicker to figure out what's going on if it's been written with combinators (once you're familiar with them) than if it's the vanilla loop.

It can be a lot less performant to chain several combinators.

If we assume the operations we're talking about take time linear in proportion to the list, you've just gone from a * n time to b * n time, where b > a. Both of these are still O(n) in Big O notation, which drops constants, because constants unless they're very large or n is extremely large, tend to have relatively little effect on the running time of an algorithm.

Choosing to write more verbose, difficult to decipher, difficult to maintain code, under the claim that it will perform better, is not a good thing: "premature optimisation is the root of all evil".

In practice, if this becomes an issue (which you find out through benchmarking once you know there is a perf issue), most modern languages offer an easy way to swap out your data-structure for a lazily evaluated one, which would then perform the operations in one pass. Languages like Haskell or Clojure are lazy to begin with, so do this by default.

Re: Everyday hassles in Go

#197

Post by kasey_junk »

Retra wrote: post #195
kasey_junk wrote: post #180

Earlier quoted context omitted.

As an industry we have no objective measures for what makes code "better", so in many ways these debates are pointless. That said, I'd add 3 points to this particular thread: 1) You cherry picked one of the most confusing uses of operators (and sources of bugs) that we have. If it weren't so ingrained in our educations/history (and so useful for old fashioned looping semantics) I think we all would have moved on from…

> As an industry we have no objective measures for what makes code "better", so in many ways these debates are pointless. I don't know why people keep saying this. We write code to solve problems. The best code solves the most problems in the most correct and efficient ways. Regardless of your measure of efficiency, if someone cannot quickly tell if your code is correct, does what is intended, and does or does not ap…

Nothing in your measure can actually be "measured". That is given 2 different solutions to the same problem, how do you determine which is better?

The reason people keep saying that we don't have any measures that do this, is that it is a bafflingly tricky problem that has been studied for decades with hardly any forward progress, and lies at the heart of most of the big issues in our industry.

Re: Everyday hassles in Go

#199

Post by dominotw »

tarikjn wrote: post #61

I couldn't agree more with this article. I did some Go a year ago and liked it. Then coming back to it a year later after having done some functional programming in Clojure, it's not just the lack of generics that disrupt my flow but also having to think about all sorts of imperative programming details like naming and creating variables and scope placements in cases that would otherwise be unnecessary in a functiona…

F# ?

Re: Everyday hassles in Go

#200

Post by kasey_junk »

Xorlev wrote: post #193
vardump wrote: post #103

Earlier quoted context omitted.

Well, you don't need the JVM and any dependencies it pulls . That's also worth something in the era of "cloud" services. Less to install. Less to update. Ideally you only need to update the deployed application. Which in case of Go is that one binary. Another big thing is that same app written in Go just takes (significantly) less RAM than when written in Java. Go has arrays (and slices) of structs, not just struct p…

Java also has arrays. And on heap/off heap RAM allocation. We deploy all our services as uberjars, we have a single Amazon AMI with JDK 8 installed. It's pretty frictionless. It goes from a simple Gradle project, to a single jar on S3, and pulled from S3 by our AMI. Automatically launches via an upstart script. I'll give you less RAM usage for sure. But when I'm launching a whole VM for a service anyways, I don't car…

Comparing Java's off heap allocation to golangs (or the CLRs) structs is pretty misleading isn't it? I mean there are all kinds of things you can do off heap to reduce gc, but the other platforms make it easy.
Post reply on HN