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

251–260 of 297 posts

Re: Everyday hassles in Go

#251

Post by kasey_junk »

Retra wrote: post #247
kasey_junk wrote: post #197

Earlier quoted context omitted.

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.

What makes you think it can't be measured? Just because we don't have the infrastructure to do it doesn't mean it can't be done. >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 what if I had a solution? How does this comment help anything? What do you think the difference is be…

>I don't know why people keep saying this.

What I'm getting at is that determining which of 2 pieces of code are better is one of the biggest open question in the computer science/software industry. Further, it has been widely studied for a long time and across a wide variety of measurements and contexts, yet remains an open question.

If you have a measure that can be systematically reproduced by anyone for any 2 pieces of code that purport to solve the same problem, that would be a huge breakthrough worthy of wide publication and probable riches.

If you can make that machinable (even given caveats around provably impossible things like the halting problem) you could literally transform the entire industry.

Re: Everyday hassles in Go

#252

Post by AnimalMuppet »

nine_k wrote: post #245
AnimalMuppet wrote: post #194

Earlier quoted context omitted.

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…

Did you ever work with a list? Did you ever do things like foo = [bar(x) for x in quux] Or did you ever flatten a nested list? Congratulations, you've been using one of the most widespread monads. Monads are not artificial constructs. Monads, like functions, or loops, or conditional statements, emerge naturally when you try to describe a computation, even a simple one. This is like speaking prose without knowing that…

No, actually, I don't do things like that (see my parallel reply to codygman).

The Haskell types often seem to think that the computing they do is the same as the computing that everybody else does, and therefore that the problems that they want to solve are the ones that everybody else wants to solve. That's not a very accurate assumption.

Re: Everyday hassles in Go

#253

Post by the_af »

Peaker wrote: post #239
the_af wrote: post #212

Earlier quoted context omitted.

I'd find it depressing if there was any programmer out there who had trouble understanding the concept of "left associativity". I think I learned it in high school.

He's talking about the concept of currying, not left-associativity.

Original question:

> What's a parameter to what?

Answer:

> Application in Haskell is left associative so its

> ((Map String) Any)

Which looks crystal clear to me. This is also the part of the answer that user waps later quoted.

Re: Everyday hassles in Go

#254

Post by kyrra »

bsaul wrote: post #2

Although i'm still very unsure about rob pike's argument that go don't need generics since it has interface, a recent experience : After having implemented a mini web services in go and being fed up with its limited type system, i decided to stop coding in go and start recoding my project in java using what is often advertized here as the most minimal framework : dropwizard. Well, i downloaded the framework, configur…

Another big benefit of Go over Java is licensing costs. While it may not matter to company that is just a website, it does matter if you are shipping hardware with services running on it. Java you have to pay per device shipped. Golang from top to bottom is BSD licensed, no costs to ship apps with it.

Re: Everyday hassles in Go

#255

Post by adrusi »

Peaker wrote: post #222
danidiaz wrote: post #156

Earlier quoted context omitted.

I think Haskell is a possible alternative to Go/Python/Ruby for these kinds of tasks. But nothing's perfect. Some possible annoyances you might encounter: * Much of the functionality required to be a valid "Python alternative" is not on the base packages. You'll have to install extra packages much sooner than with Python. And you'll have to know what packages to install. * Despite having proper sum types, most I/O li…

Proper sum types aren't enough to replace exceptions. Imagine every IO action having its own error type in a sum type. How do you compose them? Composing the different error types wouldn't unify. The best attempt I've seen in Haskell is the control-monad-exception[1] library, but I'm not sure how well that would interact with everything. [1] https://hackage.haskell.org/package/control-monad-exception

Check out how rust handles error composition using its Result type

Re: Everyday hassles in Go

#256

Post by danidiaz »

Peaker wrote: post #222
danidiaz wrote: post #156

Earlier quoted context omitted.

I think Haskell is a possible alternative to Go/Python/Ruby for these kinds of tasks. But nothing's perfect. Some possible annoyances you might encounter: * Much of the functionality required to be a valid "Python alternative" is not on the base packages. You'll have to install extra packages much sooner than with Python. And you'll have to know what packages to install. * Despite having proper sum types, most I/O li…

Proper sum types aren't enough to replace exceptions. Imagine every IO action having its own error type in a sum type. How do you compose them? Composing the different error types wouldn't unify. The best attempt I've seen in Haskell is the control-monad-exception[1] library, but I'm not sure how well that would interact with everything. [1] https://hackage.haskell.org/package/control-monad-exception

> Imagine every IO action having its own error type in a sum type. How do you compose them?

Perhaps by converting each error type to a common sum type. Something like "Either (Either error1 error2) result". Typeclasses like "Bifunctor" are quite useful for massaging the errors around:

http://hackage.haskell.org/package/bifunctors-4.2/docs/Data-...

Asynchronous exceptions do pose a problem for this approach though, as they can pop up in any function at any time. And perhaps a fully sum-type-based approach would clutter function signatures too much anyway.

Re: Everyday hassles in Go

#257

Post by TheHydroImpulse »

ominous_prime wrote: post #183
TheHydroImpulse wrote: post #179

Earlier quoted context omitted.

I'm assuming he meant why would they expose or promote the use of a construct that bypasses type safety in a statically typed language. Although `interface {}` is not some sort of special feature, it's still circumventing the type system.

You don't lose "type safety", as interfaces retain all type information -- you're not casting `void*` pointers (without the unsafe package), and type conversions are limited and well defined. It however does pass the type checking to run-time instead of compile-time, which is a trade-off that some feel is worth the language simplicity.

> It however does pass the type checking to run-time instead of compile-time

That's absolutely still loosing type safety. Reflections don't substitute type safety.

Re: Everyday hassles in Go

#258

Post by gnuvince »

gws wrote: post #58

Every time I read an article criticizing Go I end up appreciating it even more. Maybe it's because I've never felt the need to use generics and in all these articles the examples they give are functions of a few lines that would be quicker to write 2-3 times for different types than remembering generic syntax. Maybe it's because they exalt one line functional functions over a nice, simple, easy to read FOR loop when…

> Maybe it's because they exalt one line functional functions over a nice, simple, easy to read FOR loop when the former are so difficult to read, figure out what they really do, what is the performance cost, debug...

Why do you even need `for` loops? Comparison + labels + jumps are good enough. You want to know the reason? It's easier to understand the intent of the programmer when there is a loop. `for i = 1 to n do ... done` means that the programmer wants the body to be executed n times. `while not (list.is_empty()) do ... done` means the body should be executed as long as the list isn't empty. If those are acceptable, why not also abstract away applying an operation to a collection, or removing elements from a collection, etc.? Basically it boils down to: I like Go, and everything it has needs to be there, and everything it doesn't have is unnecessary complexity.

Re: Everyday hassles in Go

#259

Post by threeseed »

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…

What does memory usage have to do with ease of deployment ? Congratulations Go uses less memory. Is that really a bottleneck these days ?

And sure you only need to replace one binary. Java can do that too but also has the flexibility to hot deploy new code/libraries so no costly outage.

Re: Everyday hassles in Go

#260

Post by dangerlibrary »

rjberry wrote: post #196
dangerlibrary wrote: post #185

Earlier quoted context omitted.

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 deciphe…

My comment was carefully worded in order to denote that it is not true in all cases.

Your Big O analysis is correct. However, in a real-world case the list could be an iterator over a log file on disk. Then you really don't want to use chained combinators, repeatedly returning to the disk and iterating over gigabytes of data on a spinning plate.

And yeah, you could benchmark to figure that out, or you could use the right tool for the job in the first place.

Post reply on HN