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

21–30 of 220 posts

Re: Leaving Go

#21

Post by DAddYE »

chimeracoder wrote: post #5

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

Not sure about this statement. As the OP said in order to trick the anti-features of go you need to come up with super verbose syntax. Which is easy that's true but when the project tends to be quite big the mission becomes hard.

Also the "go get" thing is neat for small projects but for larger project IMHO is just broken. Godeps or few sh scripts can alleviate this but definitely is something needed to be addressed.

Re: Leaving Go

#22

Post by Dewie »

pron wrote: 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…

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 a base language. People seem to balk less at the idea of DSLs compared to the idea of powerful languages.

Re: Leaving Go

#23

Post by Pxtl »

chimeracoder wrote: post #5

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

I heard ASP.Net WebForms get this defense, that no other platform could handle the "enterprise" needs for maintainability and every other platform was just building a pile of cowboy spaghetti code.

Turns out it just sucked.

Re: Leaving Go

#24

Post by tptacek »

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 program correct, Golang is also not a good choice.

What's worse, those two approaches to solving programming problems are compatible with each other. Lots of sharp programmers deeply appreciate both of them, and are used to languages that gracefully provide both of those facilities. If that describes you, Golang is a terrible choice; it will feel like writing 1990s Java (even though it really isn't).

There are two kinds of programmers for whom Golang will really resonate:

Python and Ruby developers who wish they could trade a bit of flexibility, ambiguousness, or dynamicism for better performance or safer code seem to like Golang a lot. Naive Golang code will outperform either Python or Ruby. Golang's approach to concurrency, while not revolutionary, is very well executed; Python and Ruby developers who want to write highly concurrent programs, particularly if they're used to the evented model, will find Golang not only faster but also probably easier to build programs in.

Systems C programmers (not C++ programmers; if you're a C++ programmer in 2014, chances are you appreciate a lot of the knobs and dials Golang has deliberately jettisoned) might appreciate Golang for writing a lot like C, while providing 80% of the simplicity and flexibility value of Python. In particular, if you're the kind of programmer that starts projects in Python and then routinely "drops down" to C for the high-performance bits, Golang is kind of a dream. Golang's tooling is also optimized in such a way that C programmers will deeply appreciate it, without getting frustrated by the tools Golang misses that are common to other languages (particularly, REPLs).

At the end of the day, Golang is overwhelmingly about pragmatism and refinement. If you're of the belief that programming is stuck in a rut of constructs from the 1980s and 1990s, and that what is needed is better languages that more carefully describe and address the problems of correct and expressive programming, Golang will drive you nuts. If you're the kind of person who sees programming languages as mere tools --- and I think that's a totally legitimate perspective, personally --- you might find Golang very pleasant to use. I don't know that Golang is a great language, but it is an extremely well-designed tool.

Re: Leaving Go

#25

Post by DAddYE »

Kiro wrote: post #19

What is the definition of fun when it comes to a programming language?

It's subjective, for me is DRY (don't repeat yourself) and achieve a "big" result with a small (but readable) effort.

Re: Leaving Go

#26

Post by patrickmay »

pron wrote: 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…

> Yet more useful working code has probably been written in Java and C than all other languages combined since the invention of the computer

Wikipedia claims that there are over 200 billion (with a 'B') lines of COBOL in production. That further supports your point, of course.

Re: Leaving Go

#27

Post by Pxtl »

chimeracoder wrote: post #13
masklinn wrote: post #10

Earlier quoted context omitted.

> CLOS is actually very similar in some ways to Go's structs. You've completely missed the article's point: users were able to create CLOS before it got integrated in the language.

Yes, my point is that Go intentionally makes it hard for users to extend the language, while simultaneously learning from the successes and failures of other languages, and Yes, my point is that Go intentionally makes it hard for users to extend the language, while simultaneously learning from the successes and failures of other languages, and incorporating the results of that into Go. The fact that users are able to…

I think the problem with Lisp is that it grew organically from a large community across multiple languages and 50 years of life. Not that the language was excessively expressive.

Go, on the other hand, was designed and implemented from a single vendor in a handful of years. That makes it far easier to provide a single, coherent platform. Once you provide a coherent, complete platform you don't need your users to solve every edge-case by implementing their own language features.

Any language that doesn't provide some kind of code-that-writes-code workflow will eventually leave its developers dealing with frustrating boilerplate.

Re: Leaving Go

#28

Post by one-more-minute »

zoowar wrote: post #14
vfclists wrote: post #4

Try Nimrod. Or Julia. I haven't tried them yet, but it looks like their fun.

Julia is not fun. We expect it to be fun, like python, but it's not.

That's not really a fair statement – plenty of people (me included) find Julia to be a lot of fun. I'd be interested to hear why you think that, though.

If the OP is looking for a C++ alternative and knows Haskell, Rust is also an interesting alternative, although it's at a very early stage of development.

Re: Leaving Go

#29

Post by DAddYE »

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…

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

Re: Leaving Go

#30

Post by sandGorgon »

>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 just by reading.

Post reply on HN