Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leaving Go

jozefg.bitbucket.org

Post reply on HN
Print view View original

211–220 of 220 posts

Re: Leaving Go

#211

Post by cryptos »

I've the same feelings about Go. After working several month on a side project with Go, I have given up, because I've felt not as productive as with Java (not to mention Scala). There are lots of annoying things: missing generics leading to a lot of uselesse code which could carry bugs. Without generics you can not create an Option datastructure, but have to return nil (the million dollar mistake of Hoare). Without generics you can not write concise object/functional code like someCollection.map(i -> i * i). Go has no good support for immutability. Mocking is awkward, because you have to code your mocks by hand. Unicode handling is a pain.

That is why Go attracts mainly people from scripting languages (they get a bit more type safety and better performance) and C (they get a bit more type safety and less errors). Coming from other languages Go is not that attractive. I'm hoping for Rust to succeed.

Re: Leaving Go

#212

Post by Chattered »

deadghost wrote: post #98
astine wrote: post #66

Earlier quoted context omitted.

I think that part of the problem is that more 'powerful' languages often more concept heavy than more 'pragmatic' languages and that makes them harder to learn for a lot of programmers. Take Clojure for example. A lot of people including myself like this language a lot, but to be productive in it, you have to get used to the JVM, Lisp s-expressions, a heavily functional programming style with few side effects, a sign…

Not to mention emacs and the REPL. Emacs was my biggest hurdle learning Common Lisp. Learning a language - OK. Learning an editor - OK. Learning both at the same time - Not OK. I don't think light table was around at the time.

The first programming course we expose students to at Edinburgh has them doing Haskell in Emacs on Scientific Linux. We like steep learning curves, it seems.

Re: Leaving Go

#213

Post by rio4223 »

Very well put. I tried Go now for a while and I was wondering why it doesn't appeal to me like for some of my friends. By reading through your response I found the reason for my gut feeling. I guess I belong into your first categorie ;).

Re: Leaving Go

#214

Post by pron »

Locke1689 wrote: post #132
pron wrote: post #88

Earlier quoted context omitted.

> I'm not sure what the cause is, but it definitely gnaws at me. Here's my hypothesis: programming language are made for people to use, and people spending time thinking about designing Watson, don't want to spend it thinking about expressing their program using lambda calculus. The only group for whom the stuff they develop coincides with language concepts are those writing compilers. So they get confused because th…

Or, in other words, advanced languages have some cognitive overhead that people working on extraordinarily complex applications can't spare? Maybe. Then again, I've been using C++ again recently and I feel like the cognitive overhead there is so huge that I can barely understand my simple programs. Nonetheless, Microsoft pretty much runs on C++ (and C#).

It's not so much that they can't but that they won't. And the same people don't use C++'s confusing features (crazy template stuff) either. But the problem isn't just the cognitive overhead inherent to the language, but that of the switching cost. As I said in another comment, while Haskell certainly has some advantages, they don't easily overcome the switching cost. People writing compilers happily pay the cognitive price for the switch because that's their core business, while those doing CRUD apps can certainly afford the price.

Re: Leaving Go

#215

Post by StefanKarpinski »

kybernetikos wrote: post #183
coherentpony wrote: post #11

Earlier quoted context omitted.

>The thing is that GO was designed to replace c++ thing that absolutely failed. I was so excited for GO to become a nice replacement to C++. GO has awesome build times. C++ has awful build times. This is partly due to all the extra work the C preprocessor has to do make sure all the headers are present. The big lose for me is the fact that GO has absolutely no operator overloading. This is one of the biggest wins in…

> Overloading operators makes code a lot more readable and user friendly, Completely true for scientific computing, but I've been subjected to libraries written in scala recently and operator overloading there has lead to some very difficult to read and use libraries.

The key to preventing overloading of definitions from being a complete disaster is to be very careful not to overload meanings. I.e. if you're going to have lots of methods for your `frob` function, you had better be crystal clear what it means to `frob` something and only add methods that fit that definition. Scala and C++ libraries tend to like to just pick a random operator and use it to mean some arbitrary made up thing because they feel like it, ignoring the meaning of the operator. The classic example in C++ is using << for stream output. That's the left shift operator for Pete's sake! Why would that be what you use print stuff? Because you liked the look of it? It's not terribly surprising that this a complete usability disaster.

Re: Leaving Go

#216

Post by pnathan »

Locke1689 wrote: post #208
pnathan wrote: post #99

Earlier quoted context omitted.

You're arguing from perfection. The reality is that most companies choose "fast+cheap" and usually incur significant technical debt which is paid off through throwing bodies at the problem. It is usually considered better to hire 3 people who are mediocre than 1 person who is very skilled. This is extremely well addressed in the software engineering literature going back to the late 60s. It's also the case that softw…

I don't buy this either. If this were true you'd still see, for lack of a better term, the "redis" of Haskell. You can't argue that antirez skimped on development or that he isn't talented enough. Where is the redis of Haskell? The ffmpeg of ML? There's something else at play here.

I think the simple answer is that a lot of problems people consider useful are intellectually not terribly interesting. Among other things, if it's been done before, the cool factor drops off a good deal.

e.g., I run a tutorial site for common lisp. One request has been for 'example of web framework'. At some point, I'll do it (it's useful), but my heart at the moment is in implementing an extensible indexing system for n-dimensional tuples. It's a good deal more esoteric and a lot more fun than screwing with http/html.

Re: Leaving Go

#217

Post by dangirsh »

pron wrote: post #62
pnathan wrote: post #46

Earlier quoted context omitted.

> C# developers get shit done. Yes, and that says a lot about the final quality too, no? We could say the same about Perl/PHP/Java/C++ and then we're sitting in the same horrible morass we live in today, because people settle for minimally bad code produced as fast as possible. Good, cheap, fast. Pick 2. Almost invariably: Cheap+fast are the picked results.

> and then we're sitting in the same horrible morass we live in today But you see, this is the claim that requires substantial evidence. Let's assume we're in a mess. If Haskell is one way out of it, as some people claim, why won't they show us the way? They've had more than 20 years to do it. There are enough Haskell developers out there to give us this pesky evidence we need. And yet we've seen absolutely none. The…

Show me a BASIC program as impressive as any of:

- Elm's Time Travelling Debugger: http://debug.elm-lang.org/

- Pandoc: https://github.com/jgm/pandoc

- XMonad: http://xmonad.org/

- (GHC, should really count)

Re: Leaving Go

#218

Post by eridius »

burntsushi wrote: post #172
eridius wrote: post #77

Earlier quoted context omitted.

A generic abs? Not particularly useful, you're right. But he was using that as a trivial example. Generics are incredibly useful in a lot of contexts. One context that the author touched on briefly is new container types. In Go, if I have a Slice, the type of element the slice contains is specified. But if I have a user-defined container, either the container has to be specialized for a single type (which makes it la…

Trivial examples are terrible as evidence to support a point. Trivial examples are generally good for pedagogical purposes, which doesn't really fit with the OP. For example, the OP mentioned that using a stack in Go requires casting from `interface{}`. But this is patently ridiculous. Most people who need a stack in Go just use a slice: https://code.google.com/p/go-wiki/wiki/SliceTricks --- Is this a bit messier and…

It's more than just feeling pain when writing code. Using interface{} has a runtime cost. Both because of the vtable and because it requires heap-allocating something that could otherwise be inline.

Re: Leaving Go

#219

Post by grayclhn »

khyryk wrote: post #189
grayclhn wrote: post #49

Earlier quoted context omitted.

I do, and I don't even know Haskell: (b * b) - (4 * a * c) edit: I don't know go, but I assume the go example is intentionally unreadable. But complaining about infix multiplication and subtraction is... curious.

It really does get that ugly. Check out http://golang.org/pkg/math/big/ .

Yikes.

Re: Leaving Go

#220

Post by burntsushi »

eridius wrote: post #218
burntsushi wrote: post #172

Earlier quoted context omitted.

Trivial examples are terrible as evidence to support a point. Trivial examples are generally good for pedagogical purposes, which doesn't really fit with the OP. For example, the OP mentioned that using a stack in Go requires casting from `interface{}`. But this is patently ridiculous. Most people who need a stack in Go just use a slice: https://code.google.com/p/go-wiki/wiki/SliceTricks --- Is this a bit messier and…

It's more than just feeling pain when writing code. Using interface{} has a runtime cost. Both because of the vtable and because it requires heap-allocating something that could otherwise be inline.

Yes, that's true. The "pain" I had in mind wasn't in using `interface{}`, but in writing non-generic code. This doesn't result in a performance loss, but will result in some code duplication. (Or alternatively, extra complexity from using some sort of code generator.)

But, to be fair, in the Go world, both mechanisms are used. It depends on which costs are important.

Post reply on HN