Re:Swift and Go: Building a Fast Future
by notduncansmith on Tuesday November 18, 2014 @03:28PM
(#8626119)
How does a language without generics claim to "do more with less code"? Don't get me wrong, I like Go, but it's hard to get behind any language with that low of an abstraction ceiling. Then again, I work in a web shop, building CRUD apps for a living, so maybe it doesn't matter for people who only have to build one version of something.
[ Parent
| on HN ]
Re:Swift and Go: Building a Fast Future
by GFK_of_xmaspast on Tuesday November 18, 2014 @04:30PM
(#8626482)
I saw a transcript of Rob Pike's "Less is More" where he says
"What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden. I find that an odd claim. I spend very little of my programming time struggling with those issues, even in languages without generic types."
and I had literally not three days before fixed a bug in somebody's c++ code caused by using their own hand-rolled stack class instead of std::stack, so I'm not inclied to be charitable on go's lack of generics.
Re:Swift and Go: Building a Fast Future
by lomnakkus on Tuesday November 18, 2014 @06:57PM
(#8627232)
... and yet you see quite a lot of code using the Go equivalent of "void *" and casts to get its work done. (That would be the empty interface.)
Go looks like it was invented in the 80s.
As a web developer, my tinkerings with Go haven't ever left me wanting for generics. I can't say that this would be the case for every usage case, but it was never an issue for me personally.
It's not really my place to argue for or against them, just figured I'd share an anecdote.
Go is really minimalistic.thus,you either follow its philosophy or you cant use it.That's why I believe this language isnt for everyone.Try to look for alternatives such as D if you want a concurrent "safe" C ,which doesnt eat as much memory as the JVM.
Re:Swift and Go: Building a Fast Future
by Roboprog on Tuesday November 18, 2014 @03:42PM
(#8626209)
We survived getting things into and out of Lists in Java 1.2 to 1.4 somehow. The typecasting on the .get(...) calls is a nuisance, but a minor one.
Re:Swift and Go: Building a Fast Future
by threeseed on Tuesday November 18, 2014 @05:49PM
(#8626910)
Sure. And that era of Java was responsible for much of the crap, duplicated code that many of us enterprise developers have had to maintain for a living.
To ask developers to go through that again is a bit rich.
>We survived getting things into and out of Lists in Java 1.2 to 1.4 somehow
Being able to survive something is a pretty low bar.
Back in 2002. 12 years ago!