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

81–90 of 297 posts

Re: Everyday hassles in Go

#81

Post by tarikjn »

felipehummel wrote: post #63
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…

You may try out using Scala as script language like this: "scala myScript.scala". The first startup times are slower, and even after that it may be slower than Python/Ruby but it still may be sufficient for your use case. Using "sbt ~run" (re-runs your program automatically at every file change) may also be an option.

I don't see a reason why Clojure couldn't achieve the same startup time? I am trying to avoid the JVM startup time itself so that leaves out Scala/Clojure.

I'd like to be able to have a fast startup time when, say, running a script with its containerized environnement, when it is done the container exits, so I can't leave a vm running.

So I believe that leaves out JVM languages.

Independently from that, I did try Scala before Clojure and found its grammar to be overkill and unintuitive so it wouldn't be my first choice.

Re: Everyday hassles in Go

#82

Post by hahainternet »

friendly_chap wrote: post #21
NateDad wrote: post #12

"Why Go is not Haskell"

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.

Re: Everyday hassles in Go

#83

Post by friendly_chap »

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…

This question is not easy. Most languages I consider well designed do not become mainstream - which comes with a host of problems. Nowadays I think if having no type system at all is better than having a broken type system, thus I am considering picking up a mainstream dynamic language (JS being an obvious candidate - but the runtime puts me off).

Re: Everyday hassles in Go

#84

Post by stephencanon »

dalke wrote: post #57
mrweasel wrote: post #33

Earlier quoted context omitted.

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.

C11 added the _Generic keyword, so someone must have complained. A common complaint is the desire to have, say, cos(x) work on floats, doubles, and long doubles rather than calling respectively cosf(), cos(), cosl().

Huh? C has had the header for 15 years, which lets cos(x) do exactly that, and work on complex types besides.

Re: Everyday hassles in Go

#85

Post by Someone »

kasey_junk wrote: post #60
TeeWEE wrote: post #52

While the author has a lot of valid points, he forgets the goal of Go. Go was designed as a simple language, that is fast, but has similar power to existing dynamic languages such as python. The tradeoff in these designs are to prevent tuple types, always keep using structs, prevent using algebraic types over structs. Allow for nil, but try prevent common Null errors etc. Haskall is theoretical a much better language…

> Go was designed as a simple language, that is fast, but has similar power to existing dynamic languages such as python. I'd like to see a citation for this as I've never seen this as a stated goal of golang. In fact, if it were the stated goal that is one of the most damning arguments against golang as it very clearly fails at this task. I've been under the assumption that golang was designed to make writing/deploy…

http://golang.org/doc/:

"Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language."

That comes reasonably close.

Re: Everyday hassles in Go

#86

Post by lmm »

NateDad wrote: post #46
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.

It seems like Rust is what Go would become of you added all the Haskell-ness to it. Which is fine, but we already have Rust. So... Maybe we should be asking what Rust is missing from Go? Or if Rust is good enough, just use that.

Rust is missing garbage collection (which is by design, but IMO manual memory management is the wrong hair shirt to wear), and maturity.

What I want is OCaml without people complaining about concurrency (which I suspect is mostly FUD - how many people who choose go "for performance" actually profile their programs? I get the sense there is this group of people who think any high-level language is inherently as slow as Python). Or Haskell without laziness (maybe Idris will eventually become this?), and perhaps with a lower-friction approach to I/O. Or Scala with native compilation (again I think complaints about this are probably mostly FUD, but if nothing else the JVM startup latency is real). Or any of these three getting the hype that Go gets, tbh.

Re: Everyday hassles in Go

#87

Post by jbooth »

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.

Re: Everyday hassles in Go

#88

Post by ominous_prime »

aikah wrote: post #22
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…

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

> Or why expose this interface {} feature and allow people to use it in a statically typed language?

`interface{}` isn't anything special, or something akin to `void*`. Interfaces are a core part of the language, and `interface{}` is just the literal form for an "interface with no methods", which happens to match anything since all types can fulfill an empty method set. It's no different than using this `Something` for exmaple:

    type Something interface {
    }

Re: Everyday hassles in Go

#89

Post by im_dario »

friendly_chap wrote: post #44
im_dario wrote: post #39

This article has some good points but I'm going straight for the first one: I don't miss generics. Indeed, they are useful. I use them in Java every time I find a good reason to do it. So, I should say in another way: I don't miss generics in Go. Given my experience [0] in Go in the last years, I realized that if you miss generics in Go, your code is trying to cope with too much. I didn't miss them when I developed M…

Did you miss it when you were working on larger codebases? The library you mentioned clocks at 500 LOC, and while the LOC metric is pretty inaccurate, it takes a lot more time to really miss language features.

No. I didn't. I have around 2K public LOC in several projects (I can't check now my private projects, I guess I had typed more than that) but I would trust better NateDad's experience.

I have two years of sustained Go usage (since end of 2012) and never missed them.

Re: Everyday hassles in Go

#90

Post by jbooth »

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.

If you read the article, he puts forth a few examples where generics make code re-use possible, where it was impossible before. This not only means less effort, it means fewer bugs.
Post reply on HN