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

161–170 of 297 posts

Re: Everyday hassles in Go

#161

Post by nine_k »

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…

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: http://fsharpforfunandprofit.com/posts/recipe-part2/

Bonus: Martin Fowler, of all men, endorses the above approach, in Java, of all languages: http://martinfowler.com/articles/replaceThrowWithNotificatio...

A Kleisli category, with examples in down-to-earth, compact, un-hairy C++: http://bartoszmilewski.com/2014/12/23/kleisli-categories/

This stuff is not hard and is utterly practical. It can very well be used in current industrial languages.

The worst service you can render to yourself is to start thinking that you already know all what is worth knowing, and close your mind to new concepts. Guys that thought that Fortran and Cobol are enough to get by for foreseeable future were technically correct — both are still in some demand! Unfortunately, their market share has dramatically shrunk, deservedly, as have employment opportunities.

Re: Everyday hassles in Go

#162

Post by friendly_chap »

iends wrote: post #73
friendly_chap wrote: post #56

Earlier quoted context omitted.

Well Rust became production ready well after Go and the low level focus it has doesn't match my problem domain. I have the luxury of not caring about the constraint of a single consumer box - hacking mostly on backend stuff living in the cloud, so all those pointer types for example would only get in my way.

What about Elixir? Lack of static typing?

Yes, I used to ignore anything non-static, nowadays I am reconsidering this, for me untyped languages are all the same (they provide on compile time type checks), give or take syntactic sugars.

Re: Everyday hassles in Go

#163

Post by NateDad »

kasey_junk wrote: post #144
NateDad wrote: post #119

Earlier quoted context omitted.

This is old and tired. Go has a ton of features java 1.0 didn't. Hell, go has features java 1.7 doesn't (possibly 1.8, but I'm not as familiar with it).

Actually, it isn't the same argument as golang == java 1.0. It's java 1.0 had similar goals and made similar design choices that golang is making (and had similar responses from developers). In many ways this rings true. Java 1.0 and Golang do share many of the same goals. A couple of areas where it really falls down though are that Java 1.0 lacked the emphasis on tooling which is golangs greatest strength and added…

Kudos. That is perhaps the best reasoning I have ever seen for this comparison. I agree totally, though I don't think most people who make the comparison are thinking along the same lines. I think they generally just mean "compiled, GC, no generics".

Re: Everyday hassles in Go

#164

Post by frowaway001 »

jackielii wrote: post #78

Ok, we all know the problem, but do you have a solution? Have you considered the researches done by others, for example this one: http://research.swtch.com/generic

Yes, and Go apologists would also know at least one solution if wouldn't keep pretending that they can't keep reading the post until the very _first_ comment on the same page.

Re: Everyday hassles in Go

#165

Post by coldtea »

vardump wrote: post #130
brianolson wrote: post #106

The first point "no generics, no code reuse" is the best one. Go really needs generics/templates/macros or _something_. It doesn't even have subclassing, although you can kinda extend a type if you only use its public interface. I've been tempted to see if I could reasonably use the "text/template" package and feed that back into the Go compiler to achieve this. The rest is mostly a Haskell fanboy whining that Go isn…

Best joke in the industry: "Code reuse!" Cracks me up every time. ;-) We fall for those words over and over again. But in reality, sadly, reuse almost never happens. Maybe one day, maybe even in the next project...

>We fall for those words over and over again. But in reality, sadly, reuse almost never happens. Maybe one day, maybe even in the next project...

I don't know in what industry you work for. In the IT industry code reuse very much happens every time.

It might not be using code from your previous project to build the next one (through people do that ALL the TIME), that it's very much using common libs for thousands of projects.

The kind of code reuse he talks about has been working perfectly fine for ages. E.g a generic sort, filter etc function, instead of having to handle the basics every time.

Re: Everyday hassles in Go

#166

Post by NateDad »

falcolas wrote: post #135
NateDad wrote: post #107

Earlier quoted context omitted.

Go has a very nice standard library. The whole thing is reusable code.

Not every problem can be solved with the standard library. At some point you need a 3rd party library, which may require your modification to work with your data types.

The point is that everyone assumes you need generics to reuse code. And that's simply not true. For some very specific problems that can be true, but in many many cases it's not. My point is not that you never need anything outside the standard library, just that the standard library does a hell of a lot and it is by definition reusable.

Re: Everyday hassles in Go

#167

Post by coldtea »

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.

>Are generics really that important?

For the kind of work we do in 2014, yes.

Re: Everyday hassles in Go

#168

Post by LBarret »

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…

While I understand your gut reaction, the fact that those words are unknown to you does not imply that they cover complicated concepts. It's just a new word, nothing more. it has nothing to do with .

Monad is just a way to establish a (type verified) set of rules for a sequence of functions. This set of rules can be -for example- about the management of return value of these functions : executing the next function if we get a result, returning immediately if we have an error.

What is powerful with Monads, is their genericity. They can be applied to many different contexts, and still provide the same type safety.

You're likely already building very limited/specific monads without knowing it.

Re: Everyday hassles in Go

#169

Post by bstpierre »

danidiaz wrote: post #156
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…

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 stands for either language.

Re: Everyday hassles in Go

#170

Post by llambda »

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…

> I am looking for a replacement programming language to 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.

You may want to have a look at ClojureScript, which has come a long way in the last few years. While the tooling is still not as nice as Clojure-on-the-JVM in my opinion, it continues to get better everyday--this week support for a better REPL via NodeJS[1] was introduced, for instance. A lot of smart people are putting good effort into the compiler and ecosystem and I suspect we'll see a continued uptrend in cljs adoption. Anyway, it may be just what you want: an elegant, productive, pragmatic language with first-class support for concurrency (atoms, core.async) and well-suited to short-lived and scripting-domain problems. (Bonus you can write your frontend and backend in the same language if you want!)

[1] http://swannodette.github.io/2014/12/29/nodejs-of-my-dreams/

Post reply on HN