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

151–160 of 297 posts

Re: Everyday hassles in Go

#151

Post by nine_k »

xasos wrote: post #136
tarikjn wrote: post #116

Earlier quoted context omitted.

Yes, I did describe what Go is good at, that's because I am trying to find something to put it against for what I use it for currently. Let's say I prefer Haskell's syntax/approach. Coming from Go, what could I be missing in Haskell?

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

Re: Everyday hassles in Go

#152

Post by nine_k »

jbooth wrote: post #87
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…

Go has first-class functions, if it had generics it'd be trivial to put together libraries for most of the functional-collection goodies, while still having imperative style available for when you care about performance or when it's just simpler for the problem.

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

Re: Everyday hassles in Go

#153

Post by frowaway001 »

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…

Scala is pretty nice. Concerning the JVM startup time: It's usually in the range of milliseconds for your use-case.

What gave the JVM a bad name regarding startup time are large JavaEE application servers which had dependencies to hundreds of MBs of libraries. In this case, startup is slow, otherwise: not so much.

Re: Everyday hassles in Go

#154

Post by vardump »

zzzcpan wrote: post #133
vardump wrote: post #122

Earlier quoted context omitted.

You don't like locks, but you want refcounting that requires a large number of atomic ops for acquire/release semantics and thus scales like crap? Ah, you really mean, single threaded as in no other threads? Well... ok. But that'd make Golang a lot less useful. For compiled regular expressions: just use PCRE library for compiled regular expressions. I bet there's already some library that does it for you. Maybe you s…

Refcounting and a single threaded runtime, instead of GC and a multithreaded one. By compiled regexpes, I meant replacing things like bytes.Equal(foo, "qwe") with things like foo.m(`^qwe$`) or even foo.m/^qwe$/ that have the same performance. All the loops that scan through slices could benefit from it, golang has a lot of them. Plus more overall matching/scanning consistency, that should lead to fewer mistakes.

Well, if you're happy to run them only over byte arrays, then you should be able to use PCRE and satisfy your performance requirements. Your regular expressions will get compiled into native code at runtime.

http://sljit.sourceforge.net/pcre.html

Re: Everyday hassles in Go

#155

Post by jbooth »

nine_k wrote: post #152
jbooth wrote: post #87

Earlier quoted context omitted.

Go has first-class functions, if it had generics it'd be trivial to put together libraries for most of the functional-collection goodies, while still having imperative style available for when you care about performance or when it's just simpler for the problem.

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 semantics, can you explain more? Some(Result) can make nil go away, but you've still got the error to deal with. So you're talking some type system where a single value encapsulates Result/Nil/Error?

Re: Everyday hassles in Go

#156

Post by danidiaz »

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 libraries in Haskell rely on exceptions for signalling errors. And Haskell has no proper stack traces. If you are not careful, you might find yourself pining for Go's multiple return values.

(Some would add "having to use the IO monad" to the list of annoyances, but I think it actually helps.)

Re: Everyday hassles in Go

#157

Post by falcolas »

vardump wrote: post #146
falcolas wrote: post #139

Earlier quoted context omitted.

Like c's 'libc', or C++ boost, or pythons 'requests', or... Lots of code reuse there that depends on generics.

Yes, libraries get used. That's their point. My point was, that very little of application code ever gets reused, although we somehow always think it will.

And most people are asking for generics to write libraries which don't rely on unblocking interfaces.

Even in the process of writing a single program, there are a number of times where you reuse certain bits of logic, and having generics makes it easier to refactor those into a single function, instead of duplicate code with multiple types (or overly generic types).

Re: Everyday hassles in Go

#158

Post by frowaway001 »

NateDad wrote: post #40
rtpg wrote: post #31

Earlier quoted context omitted.

maps and filters are things that have existed for a long time, and are extremely commonplace. They are also very representative of common operations in programming. Not having generics means we can't properly build these ourselves, and Go doesn't offer list comprehensions, so instead we're forced to for loop.

Yes, loops, just like we learned in CS101.

  I used to play with a small plastic hammer when I was in 
  kindergarden thirty years ago!
  
  I will be very irritated if people laugh at me for trying 
  to build my new house with this hammer now.

                                               -- Golangers

Re: Everyday hassles in Go

#159

Post by irq-1 »

sentiental wrote: post #113
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…

I am starting to think they'll be recommending we use `go generate` to do handwritten templates before too long. It saves them the hassle of building generics into the type system and they clearly want it to be part of the build cycle. http://blog.golang.org/generate

> Just keep in mind that it is for package authors, not clients...

Generics by author-template sounds exactly like what the Go authors would want: source code is still shared (rather than binaries), no Make/Include/Macros for the build, and no hassle for the _user_ of a package.

> Also, if the containing package is intended for import by go get, once the file is generated (and tested!) it must be checked into the source code repository to be available to clients.

Moving external processes into the source code is characteristic of how they've developed Go.

A GCO/SWIG style generator built-in to `go` would be a great next step. It wouldn't have to be perfect, just deal with includes and defines separate from Go build. Even if the output needed to be hand edited it would be a great starting point.

Re: Everyday hassles in Go

#160

Post by friendly_chap »

hahainternet wrote: post #82
friendly_chap wrote: post #21

Earlier quoted context omitted.

Author here. I think that is a very valid point. However, a lot of features I mentioned are present in other imperative languages, like Rust. The Go authors however picked other solutions I consider inferior, hence the article.

Your article is unbelievably arrogant. You should have been honest, not dishonest. These aren't everyday hassles, these are hassles you have selected to promote Haskell.

I write Go exclusively during my day job - these are indeed chores I encounter daily.

I could and probably will blog about problems with the Haskell as well - nothing is perfect.

Post reply on HN