Live data from Hacker News

Leaving Go

jozefg.bitbucket.org

141–150 of 220 posts

Re: Leaving Go

#141
post #131

Earlier quoted context omitted.

When X is Python, and "time X" is too slow.

Or "likelihood that program runs correctly if compiles correctly X" is too low, or "ability to write concurrent code in straight-line fashion rather than with callbacks X" is "too low".

Not sure I follow.

When single threaded top-down Python is too slow for a particular task, of late I find it easier/cleaner/faster to use Go routines than multiprocessing / threading in Python, because of the way concurrency was designed in Go, but added to Python.

> "ability to write concurrent code in straight-line fashion rather than with callbacks X"

Same concept or different point?

Re: Leaving Go

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

I can imagine generics being useful if you create large amounts of context-aware types, like was discussed in an HN post a week or so back.

Re: Leaving Go

#143

As someone who writes both Lisp and Go (and enjoys both), I find it odd that this article uses Lisp and Haskell as points of comparison. > programming in Go isn’t “fun” in the same way that Python, Haskell, or Lisp is. Yes, writing Lisp is much more "fun" than writing Go for me. But writing Go is much more productive and maintainable (both for solo projects and for larger groups). In fact, this is almost an intention…

Yes, Go is boring, but it's interesting that the people who hate on Go for being boring are not the same people who hate on Java for being boring (though Java 8 is much improved).

People don't hate Java for being boring, per se. They hate it for being inflexible, verbose and having a bureaucratic culture.

Re: Leaving Go

#144
A 16 year old kid decides that Go isn't suitable for writing an embodiment of Principia Mathematica. Surprise: Haskell is a better Haskell than Go.

Go is a something like C, but with a few more features plus GC and come neat concurrency facilities. Why would anyone expect that to be anything like Haskell, or even to have a type system even approaching that kind of power?

Re: Leaving Go

#145
post #117

Earlier quoted context omitted.

I think tptacek may have implying that, like all the REPLs for C, the REPLs for Go are more curiosities than anything anyone would want to use.

REPLs are for toying around and learning. The Go playground provides an alternative that seems to satisfy these needs for most people. If people really missed a Go REPL then the existing ones would not be "curiosities".

People use REPLs for more than "toying around and learning." They can be very useful both for exploratory programming (which is different from toying around in that you're actually trying to accomplish something) and debugging. It seems more likely to me that Go doesn't have a good REPL because Go just isn't very amenable to general-purpose REPLs, which is the same reason C REPLs tend to be more trouble than they're worth.

Re: Leaving Go

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

> languages used in industry have had them for decades If languages used in industry have had something for decades it does not automatically mean that it's a good idea. Go reconsiders a couple of things that once were thought to be good ideas like class inheritance, exceptions, generics and questions their net benefits.

Yeah, and notably, you never hear grumbling about class inheritance, sometimes hear grumbling about exceptions, and constantly hear grumbling about generics. It seems like the amount of grumbling probably tracks the actual net benefits.

Re: Leaving Go

#147
post #74
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…

"is there going to be a big marketing campaign to make me and my manager feel comfortable"... I doubt it.

And this is why better languages fail: because language weenies have atypical minds, and can't comprehend why something marketed inappropriately to the mainstream never catches on as something mainstream.

This is also precisely why Java succeeded. This is also why LightTable finally got across what Smalltalkers had been raving about. It's really not only about who has the best tech or the best message. It's who has the best tech that can make itself understood.

Re: Leaving Go

#148

Earlier quoted context omitted.

As someone who thinks that more advanced type systems and proof-carrying-code are some of the biggest advances in theoretical computer science and practical programming in the last few decades, but also is a C# compiler developer, I have also noticed this. Haskell is really interesting, but C# developers get shit done. I'm not sure what the cause is, but it definitely gnaws at me.

It's not a good thing - for production software - for a language to be too much fun to use. It means that developers spend all their time using the language and not enough time solving problems . The suckiness of Java/C# tends to encourage people to solve their problem and move on quickly to the next problem, because it's honestly not much fun trying to extend the language or build abstractions. Haskell & Lisp progra…

Then I guess that Emacs users never get any work done? ;) (I wouldn't know, but I would be surprised if that was the case)

Re: Leaving Go

#149
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 you'll wish you had a generic red-black tree or linked list in your life: many, many times.

The number of times you'll need a generic map or fold algorithm to operate on those structures: many, many times.

Re: Leaving Go

#150
post #117

Earlier quoted context omitted.

I think tptacek may have implying that, like all the REPLs for C, the REPLs for Go are more curiosities than anything anyone would want to use.

REPLs are for toying around and learning. The Go playground provides an alternative that seems to satisfy these needs for most people. If people really missed a Go REPL then the existing ones would not be "curiosities".

Another possible explanation is that people who care about REPLs just use languages with good REPLs.
Post reply on HN