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

91–100 of 220 posts

Re: Leaving Go

#91

Post by pron »

pnathan wrote: post #74
pron wrote: post #62

Earlier quoted context omitted.

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

I don't even understand your question. My internet is filled with half-baked webapps with bad errors and riddled with stupid security vulnerabilities, many of which can be defined to not occur in an adequately designed tech stack. Desktop programs work through dint of manpower, crufty testing environments, and users-as-QA. What exactly are you looking for? Web app frameworks? they exist. database connectors? they exi…

> Sophisticated programs running sophisticated systems? They exist

Not really. Well, far less than in all those horrible, unusable languages. All I'm saying is, if Haskell makes writing correct code so easy, where is it? There should be tons of it now. It should be practically everywhere. In fact, it should be financially stupid to do anything in any language other than Haskell. So where are all the companies making a fortune by betting on Haskell?

Re: Leaving Go

#92

Post by stiff »

tptacek wrote: post #24

If you're looking for a language that will enable "bottom-up development", where you gradually define, in Paul Graham On Lisp style, a language optimized for your problem domain, Golang is not the language for you. Similarly, if you're looking for a language that will read and write like a specification for your problem domain, so that writing your program has the side effect of doing half the work of proving your pr…

There is something to your description. I use Go sometimes, for pragmatic reasons, when I need more performance than I can get from Python or Ruby, but boy is it a ugly language!

There are just tens of little ugly things Go does and the result is, well, even uglier. Writing four functions for every collection to be sorted, writing x = append(x, foo) everywhere, shitty namespacing that prevents you from writing list := list.New() and so on and so forth. Even C is more elegant, and I would probably prefer to use C, if only C came with a library manager like rubygems or go get and a decent repository of libraries. I would even prefer Java if it produced native binaries and had an integrated library manager.

Re: Leaving Go

#93

Post by mseepgood »

tptacek wrote: post #80
mseepgood wrote: post #32

Earlier quoted context omitted.

> the tools Golang misses that are common to other languages (particularly, REPLs A quick search for Go REPLs gave me many results, e.g. https://github.com/rocky/go-fish "Yet another Go REPL"

There are C REPLs too.

I know, I didn't say otherwise.

Re: Leaving Go

#94

Post by bsg75 »

tptacek wrote: post #89
m0th87 wrote: post #52

Earlier quoted context omitted.

You're right, Golang is all about pragmatism, and a very pragmatic thing for language designers to do is to listen to the marketplace on how the language should evolve. Lack of polymorphism must be the most common critique of Golang. It seems pretty practical to add it, as it would greatly reduce the amount of boilerplate. And it's not as if polymorphism is stuck in the ivory tower - languages used in industry have h…

When I wrote that paragraph, I definitely did not think of "pragmatism" as "doing whatever people wanted them to do". Golang is also not Perl. If you're looking for Perl, Golang will disappoint you.

If you are looking for X, Y will disappoint you.

-or-

If you are looking for X, use X.

Re: Leaving Go

#95

Post by bookwormAT »

piokuc wrote: post #36

I think people gave Go a lot of credit just because it was designed at Google. People have high respect for Google engineers and so they assume what Googlers have designed must be flawless. So they take for granted ideas like lack of exceptions or lack of operators' overloading being a good thing, even though I'm quite sure they would be quick to criticize such BS if that was a feature in a language not coming from G…

I think people gave Go a lot of attention because it was designed by Rob Pike and Ken Thompson.

Re: Leaving Go

#96

Post by Donch »

jerf wrote: post #86
bunkat wrote: post #56

Earlier quoted context omitted.

This code doesn't actually compile. You can't assign v to x.(type) like that.

Are you sure? http://play.golang.org/p/dJC328-rh8 I did have to put "return x" as the last statement, though, not return v. And I'm not sure I'm happy about an "abs" that happily returns a string if fed a string, but, well, that's Go. Relevant bit of the spec: http://golang.org/ref/spec#Type_switches

It's horrible method with a horrible signature, that I didn't test :-)

But the short variable declaration in the type switch does indeed save the casts the OP was complaining about.

Even more correct and horrible: http://play.golang.org/p/ZMQKQhuUQT

Re: Leaving Go

#97

Post by grey-area »

m0th87 wrote: post #52
tptacek wrote: post #24

If you're looking for a language that will enable "bottom-up development", where you gradually define, in Paul Graham On Lisp style, a language optimized for your problem domain, Golang is not the language for you. Similarly, if you're looking for a language that will read and write like a specification for your problem domain, so that writing your program has the side effect of doing half the work of proving your pr…

You're right, Golang is all about pragmatism, and a very pragmatic thing for language designers to do is to listen to the marketplace on how the language should evolve. Lack of polymorphism must be the most common critique of Golang. It seems pretty practical to add it, as it would greatly reduce the amount of boilerplate. And it's not as if polymorphism is stuck in the ivory tower - languages used in industry have h…

They probably will add generics at some point in the future. In the meantime, lots of people are using and enjoying the language as it is.

If you want to write generic methods using your own types, you can define an interface to operate on, and then create types which conform (or wrap more basic types to conform) - as this article demonstrates after it sets up a straw man to criticise golang with. I quite like that approach, though it does depend what sort of libraries you're writing, and what sort of types you're operating on - a maths library might be painful for example but if you're operating on your own types anyway, using interfaces is no great burden.

Re: Leaving Go

#98

Post by deadghost »

astine wrote: post #66
Dewie wrote: post #22

Earlier quoted context omitted.

Maybe it turns out that the sociological side of programming trumps the technical side; that languages that forces or fosters a common vocabulary will always "win" over languages where you have so much power that you can easily diverge from the mainstream dialect, and there is not much culture of restraining this freedom. On the other hand, these dialects are embedded DSLs; specialized languages created and hosted by…

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.

Re: Leaving Go

#99

Post by pnathan »

pron wrote: post #91
pnathan wrote: post #74

Earlier quoted context omitted.

I don't even understand your question. My internet is filled with half-baked webapps with bad errors and riddled with stupid security vulnerabilities, many of which can be defined to not occur in an adequately designed tech stack. Desktop programs work through dint of manpower, crufty testing environments, and users-as-QA. What exactly are you looking for? Web app frameworks? they exist. database connectors? they exi…

> Sophisticated programs running sophisticated systems? They exist Not really. Well, far less than in all those horrible, unusable languages. All I'm saying is, if Haskell makes writing correct code so easy, where is it? There should be tons of it now. It should be practically everywhere. In fact, it should be financially stupid to do anything in any language other than Haskell. So where are all the companies making…

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 software engineering is very conservative: "Don't change ANYTHING" is the default state of the industry with regards to practices.

Re: Leaving Go

#100

Post by cgh »

azth wrote: post #73
personZ wrote: post #60

These sorts of posts are profoundly boring. I know people will up arrow it -- some sort of spiteful "Down with Go!" contrarian thing, when they aren't talking up rust -- but it isn't because the content is interesting or illuminating, but rather as some sort of activist thing. This particular piece (by a high school student, as an aside) starts off trying to create a surrogate for generics in Go. Don't . Here's the t…

> The number of times I've needed a generic abs in my life -- zero. What about a generic max() or min() function?

Or a generic list, vector, map...
Post reply on HN