Live data from Hacker News

Leaving Go

jozefg.bitbucket.org

71–80 of 220 posts

Re: Leaving Go

#71
post #18

It's ironic that the "better" the language (for some hazy definition of "better") the less actual work seems to get done with it. So Go can be pretty annoying at times, and so can Java (I've said before that I find the two almost identical, but that's beside the point now); and C is horrible and completely unsafe and downright dangerous. Yet more useful working code has probably been written in Java and C than all ot…

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.

> I'm not sure what the cause is, but it definitely gnaws at me.

My theory is that it is because that is what we teach. If you go to school you learn Java (which is basically C#) and if you learn a language on your own most people recommend Java/C# because it will get you a job.

By extension we end up with the vast majority of coders knowing Java/C#, thus most code gets written that way.

Re: Leaving Go

#72

>Ok, it’s only a few characters, big deal. Now what does this do? >b.Mul(b).Sub(big.NewInt(4).Mul(a).Mul(c)) >Or in Haskell >b * b - 4 * a * c umm.. correct me if I'm wrong, since I'm not well versed in either Haskell or Go, but doesnt the Golang version read better in terms of scoping. I mean just by reading the Go version, I know what it will evaluate to, but in the Haskell version I dont know the precedence order…

BIDMAS is worth memorising - http://en.wikipedia.org/wiki/Order_of_operations

Re: Leaving Go

#73
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?

Re: Leaving Go

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

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 exist. mathematical proofs relating to correctness? they exist, in abundance. data structures arcane and common? they exist. regex libs? they exist. Sophisticated programs running sophisticated systems? They exist, and you won't hear about them except as a rumor on message boards...

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

Re: Leaving Go

#75
post #37
post #29

Earlier quoted context omitted.

> Systems C programmers I don't know many (TBH none) c programmers that likes or actually uses go. The thing is that as for c++ if you are still writing in c is just for few reasons: portability (in terms of embedding your library) and speed. Especially the former seems very important. EDIT: I know => I know personally or I follow.

Does Ken count as a Systems C programmer? Most of the systems C programmers I know, who admittedly work on large distributed systems, like Go.

Edited, I meant: who I know or I follow.

Re: Leaving Go

#76
post #46

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.

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

It's interesting. There's so much more C# code out there, but I wonder about the lifetime of that code, and when it will be swept under the rug (i.e. if javascript eats the enterprise).

Haskell seems to disseminate ideas rather than code. It even disseminated LINQ into C#.

Perhaps this makes the lack of volume of production Haskell code less stinging because it has contributed to languages in other ways?

There's kind of an upside to this as well, because Haskell isn't entrenched in industry, it's still free to make changes and grow the language (i.e. Applicative becomes superclass of Monad), although this gap may be starting to slowly close with the recent popularity.

Re: Leaving Go

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

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 largely useless, at least as reusable code), or it has to take interface{}, which really sucks. No more homogenous container, no more static type information when working with this container, etc.

Re: Leaving Go

#78
> I wanted a fast, compiled replacement for stuff I write in C right now. But Go is not that language.

You should look into Rust. It sounds like it might be more like what you're looking for.

Re: Leaving Go

#79

>Ok, it’s only a few characters, big deal. Now what does this do? >b.Mul(b).Sub(big.NewInt(4).Mul(a).Mul(c)) >Or in Haskell >b * b - 4 * a * c umm.. correct me if I'm wrong, since I'm not well versed in either Haskell or Go, but doesnt the Golang version read better in terms of scoping. I mean just by reading the Go version, I know what it will evaluate to, but in the Haskell version I dont know the precedence order…

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.

No, that's pretty much what the Go would look like, for any non-standard numeric type. (Though it does need to be a non-standard type, like a "bigint"... a merely type-wrapped standard type ("type Feet uint32") can still have arithmetic done to it.)In fact the default go fmt rules won't even let you put whitespace in there.

However, my general call on that is that if you need your language to provide overloaded arithmetic operators, stick to languages that actually want to give that to you. It comes up a lot in language discussions because it's such an easy example to type out in a couple of lines, but in practice I don't think you see a lot of need for exotic int types being used pervasively throughout your code. Don't use Go for that. Don't use any language that doesn't do operator overloading. But this is far less a common use case than seems to be supposed... a variant of the "look under the streetlight" fallacy, I think.

Go's really for heterogeneous concurrent business- or server-like programming. It isn't a language for mathematics, and the burst of libraries I've seen in the last couple of weeks that seem to be focused on that is bizarre to me. Go isn't good at that, isn't meant for that, and probably never will be. Go's nice for the very large niche that "business- and server-like programming" is but it's not so fantastically wonderful in every way that I'd want to work too hard to make it work in a niche it's not really suited for.

Re: Leaving Go

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

> 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.
Post reply on HN