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

201–210 of 297 posts

Re: Everyday hassles in Go

#201

Post by gnuvince »

bstpierre wrote: post #169
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…

I found ocaml to be a more flexible alternative -- I can sprinkle printf for quick debugging without having to alter types. (I think this is what you mean by "having to use the IO monad". I didn't work with haskell much, so it's possible there's an easy way around this there.) And stack traces in ocaml are reasonable, though not quite as verbose as python's. But your point about needing to install extra packages stan…

OCaml is currently my language of choice. I love functional programming, been doing it for a while now, but it's nice to know that if I read an algorithm in a textbook, I can just implement it as-is instead of doing a translation to be purely functional (and sometimes having to fight to get back the asymptotic complexity). The module system is also absolutely great, and should be copied shamelessly by more languages.

Re: Everyday hassles in Go

#202

Post by Pxtl »

mrweasel wrote: post #33
aikah wrote: post #22

Earlier quoted context omitted.

> That said I do worry that the Generics argument seems to be slowly approaching a religious war that will distract people from the other enjoyable aspects of Go Because generics are important.We're not talking about crazy C++ templates here but a more rigid feature that would still make Go language more expressive. Or why expose this interface {} feature and allow people to use it in a statically typed language? Peo…

Are generics really that important? Java didn't have generics for 9 or 10 years, C# only got them in version 2. C still doesn't have generics and I never heard anyone complain. As a former C# developer I would agree that life got easier with the introduction of generics, but you can develop the exact same software with and without generics.

C has macros, which allow you to create something close-enough to generics.

And as somebody who developed in Java and C# before generics, those languages were awful before those features were added.

Re: Everyday hassles in Go

#203

Post by codygman »

nine_k wrote: post #151
xasos wrote: post #136

Earlier quoted context omitted.

> solve small problems for which Python/Ruby would have traditionally been used, good file system, stream and networking APIs, but concurrency as a first class citizen, garbage collected, fast startup time I think for the most part, you won't be missing a lot in Haskell. If you are looking for what you say above, Go should satisfy your needs greatly. Haskell is amazing for functional programming needs - fast prototyp…

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.

Re: Everyday hassles in Go

#204

Post by lmm »

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…

When I found out about monads it was after I'd already implemented the same abstraction. It actually comes up quite a lot (async calls, error handling, audit logging, database access). http://m50d.github.io/2013/01/16/generic-contexts.html . Just like when I was told about "the visitor pattern", my reaction was mostly "that? I've been doing that for years. So that's what it's called".

Still, it's worth knowing the name for a concept so that you can talk to people about it, and it's certainly worth knowing the library tools that exist and can save you time. Pretty often I'll write two or three lines of code, look at it, and then realise "oh, that's just traverseM" or some such. Even if it doesn't save me any time writing, replacing three lines with one library call is a huge bonus to maintainability.

Re: Everyday hassles in Go

#205

Post by codygman »

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…

If you give some examples of the work that you do perhaps we can make some of the abstractions concrete.

Re: Everyday hassles in Go

#206

Post by skybrian »

dons wrote: post #5
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…

Languages may not be perfect, but language features can be compared, and some features are strictly more powerful than others. There is scope for legitimate criticism of language design based on the expressive power^1 of their features. In this case, generics would make Go strictly more expressive, as, without it you must write O(n) more code or perform a global refactoring to simulate it. 1. http://citeseerx.ist.psu…

You can compare language features this way, but it won't tell you which language is a better fit for a particular problem. JSON is strictly less powerful than JavaScript and it's easy to come up with examples of data that can be better compressed in JavaScript. But for what we use JSON for, not being Turing complete is a feature.

When programming in an intentionally restricted language, the question is whether the limitation in power is put to good use in some other way.

Re: Everyday hassles in Go

#207

Post by skybrian »

dons wrote: post #5
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…

Languages may not be perfect, but language features can be compared, and some features are strictly more powerful than others. There is scope for legitimate criticism of language design based on the expressive power^1 of their features. In this case, generics would make Go strictly more expressive, as, without it you must write O(n) more code or perform a global refactoring to simulate it. 1. http://citeseerx.ist.psu…

You can compare language features this way, but it won't tell you which language is a better fit for a particular problem. JSON is strictly less powerful than JavaScript and it's easy to come up with examples of data that can be better compressed in JavaScript. But for what we use JSON for, not being Turing complete is a feature.

When programming in an intentionally restricted language, the question is whether the limitation in power is put to good use in some other way.

Re: Everyday hassles in Go

#208

Post by microtonal »

protomyth wrote: post #187
TazeTSchnitzel wrote: post #38

Earlier quoted context omitted.

Java would be a lot nicer to work with had it had generics from the beginning.

That's one of the big problems with adding major features later, the standard libraries don't get rewritten to fully use the new feature.

That's not Java's major problem. It's that generics were implemented using type erasure to stay source and binary compatible with older libraries.

Re: Everyday hassles in Go

#209

Post by TheHydroImpulse »

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

Uhmm, what? That seems entirely ignorant for ignoring an expressive concept and rather "do it the hard way". And, "remembering the generic syntax" is no different from remembering any other features' syntax, and I don't imagine you have issues remembering those, do you?

Re: Everyday hassles in Go

#210

Post by lmm »

ominous_prime wrote: post #118
rjberry wrote: post #92

Earlier quoted context omitted.

All loops encode simple logic? I don't think that's true. Either way, a very good reason for not using loops is to make code more readable. If I see a loop I have to run it inside my head to figure out what the intent is, and if there's multiple things going on, that can take time. If I see a 'map' I think "right, this is tranforming every element in this list in this way"; if I see a filter, I think "right, this is…

Expanding a map to a for loop is very simple. Yes it removes a shortcut available when writing code, but when reading code I can consume that simple chunk of logic in one mental bite just as easily as I can a call to map.

By that logic why bother with for? You can implement any control structure with goto, after all.

The value of using map is precisely that it can't do everything a for loop can. It can only do one simple thing, which makes it easy for the reader to understand what it's doing.

Post reply on HN