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

241–250 of 297 posts

Re: Everyday hassles in Go

#241

Post by ufo »

theseoafs wrote: post #191
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).

In Ocaml's case its less about casting being a source of bugs and more about casting not playing well with Hindley-Milner type inference, which is Ocaml's "killer feature". (and Ocaml doesn't have type classes to solve this problem like Haskell does)

Re: Everyday hassles in Go

#242

Post by Peaker »

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…

I think you should spend some time familiarizing yourself with actual statically typed languages before expressing an extremely ill-informed opinion as fact.

Re: Everyday hassles in Go

#243

Post by Peaker »

gnuvince wrote: post #236
Peaker wrote: post #224

Earlier quoted context omitted.

Haskell doesn't ban imperative programming, it simply distinguishes it in the types.

True, what I mean is that I can be "messy" in OCaml for the sake of expediency. In principle, I prefer Haskell's clean approach, in practice I'm a bad programmer who sometimes does naughty things.

Well, Haskell does force you to go and update your types about your effects, and fix the use sites to do proper lifting.

I don't feel this costs much, though, so even in quick&dirty mode, I feel that Haskell is quite productive enough.

Re: Everyday hassles in Go

#244

Post by tankenmate »

Animats wrote: post #228

The article author points out, correctly, that Go code has far too much "interface{}" in it. That's an indication of real need for more power in the type system. Generics may be overkill. Parameterized types may be enough. The difference is that you have to explicitly instantiate a parameterized type. Generic functions and classes get instantiated implicitly when used, which gets complicated. (See C++'s Boost.) Go al…

Excellent idea. I think maybe having strict type interfaces for the implementation so you could roll your own would be a good idea too; à la perl's tie HASH => TIEHASH, FETCH, STORE, et alia, TIEARRAY, FETCHSIZE, STORESIZE, et alia, etc. Obviously then you can have slices, arrays, maps (hashes, dicts), that can be use whatever backing store / behaviour you want / need. This will mean that behaviour of individual data collections may not be as clear cut in their behaviour (skeuomorphically) but the upside is more flexibility.

Re: Everyday hassles in Go

#245

Post by nine_k »

AnimalMuppet wrote: post #194
nine_k wrote: post #161

Earlier quoted context omitted.

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…

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.

Re: Everyday hassles in Go

#246

Post by nine_k »

codygman wrote: post #203
nine_k wrote: post #151

Earlier quoted context omitted.

While it's kind of off-topic, let me still ask: what are the problems you see in using Haskell for networking? I see that building a library with the C calling convention might be hard, but a web service must be pretty language-agnostic.

I'm not sure why the xasos says that. For me Haskell has been great for apis. Regarding calling C, the Haskell ffi is very easy to use. Try Nim, Ocaml, or Haskell to replace Go in that order. I order it in terms of probable familiarity.

Calling C is easy. Calling from C might be not.

Re: Everyday hassles in Go

#247

Post by Retra »

kasey_junk wrote: post #197
Retra wrote: post #195

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. 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.

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 between unsolved and unsolvable, and how does your reaction not foolishly apply to both? How would you recognize progress in the context of my post?

Here's a Haskell factorial function:

    -- Basic factorial function.
    fac :: Integer -> Integer
    fac n = product [1..n]
Here's an attempt at a factorial function in another language:

    .r $15265f38a [] (44) ; dup n + offset;
    _
Which is better code? Do they both compute a factorial? Do they both terminate? How did you determine this without using any 'measurable' data?

Re: Everyday hassles in Go

#248

Post by [deleted] »

kasey_junk wrote: post #197
Retra wrote: post #195

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. 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.

[deleted]

Re: Everyday hassles in Go

#249

Post by threeseed »

vardump wrote: post #43
kator wrote: post #3

"Every computer language is an imperfect way of describing a potential solution to a poorly understood problem" -- Me I find it interesting when people wax poetic about how one language is better than another and how if we just did x, y or z then we'd have this perfect solution. That said I appreciate the author's write-up of some challenges with Go. In the end the reality of any "product" is building what the user's…

The big thing people miss is that while lack of generics might cost them effort worth X, other Go features benefits them Y. The value of Y is pretty large in case of Go, when it comes to concurrency and language level simplicity. It's hard to go wrong in Go. Whoever designed Go seems to have some experience debugging and maintaining large concurrent systems. When you design a language, you have to be so careful of th…

Nobody is saying Go should rush to implement generics or any other feature.

The issue is more the dismissive attitude towards them.

Re: Everyday hassles in Go

#250

Post by AnimalMuppet »

codygman wrote: post #238
AnimalMuppet wrote: post #231

Earlier quoted context omitted.

Perhaps you could. That's not the same as making them useful for me, though. I work primarily in embedded systems, where sequence is critical, many things are stateful, and there are multiple threads of control. So, for example, I could take the sequential aspects and re-write them as a monad. Or I could just do nothing, and let them be sequential imperative code. I know that in a pure functional world, sequence can…

The purity is not an illusion though. Writing those sequences as a monad gives you the ability to compose actions, creating a new sequence from code you've already written for one.

But that's not a net win for me, compared to just having the action in a function that is called from several places.

Worse, composing the actions means I have to think through how the composing is going to affect the sequencing of events. Just having a function doesn't give me that problem - the sequencing is explicit, not hidden, and therefore is easier to reason about.

Post reply on HN