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

A year with Go

vagabond.github.io

Post reply on HN
Print view View original

31–40 of 235 posts

Re: A year with Go

#31

Post by nickysielicki »

> "I just don’t understand the point of Go. If I wanted a systems language, I’d use C/D/Rust, if I wanted a language built around concurrency I’d use Erlang or Haskell."

Agreed. C and Rust are systems langauges, Go is not particlarly great in that category. That is okay.

I will say, I hope you have fun getting an average CS graduate to properly write and maintain a Haskell or Erlang program with concurrency. Go is stupid easy to pick up for anyone who has worked with C/C++/C#/Java/Python/Ruby, which, by no exaggeration, probably encompasses every programmer alive.

Meanwhile, Haskell and Erlang look like gibberish to most programmers. And I'll admit, that's a lacking argument. Functional languages cannot be said to be bad just because most people don't understand the functional paradigm.

But the fact remains, an average programmer can sit down today with no knowledge of Go, and by the end of the day create a concurrent program using Go. And given the lack of flair in go, it's the langauge that lends itself to being maintainable. You won't see anything like in python or perl where you're almost expected to abuse the langauge internals (see this awesome example in python [0]). That's completely by design. [1][2] (scroll up to see the quote by Rob Pike)

If you have a team of a dozen guys working on a project with thousands of lines, your priority is not just performance (Go is quick enough [3]). It's probably not elegance either.

It's software that documents itself.

I used to work as a systems administrator for my schools engineering department. We would deal with fixing perl scripts dating back to the 90's. As students came and went, the result was hack jobs on top of hack jobs by students who are now in their 30's. I hated it. I would commonly have to rewrite scripts because over the years the basic flow of the program became completely asinine.

That's exactly where go does well. Go is a langauge for people who don't want to have to deal with abuses of the language that their coworkers put in place. Go is a language that understands that for programmers, maintaining code means fixing bugs and fixing bugs tends to boil down to hacky solutions. Go ensures that those quick fixes aren't hacks.

> "The only place I can see Go shining is for stuff like portable command line utilities where you want to ship a static binary that Just Works(tm). For interactive tasks I think it would be fine, I just don’t think it is particularly well suited to long-running servery things."

I really don't understand why he feels that way. I don't see the distinction.

> "It also probably looks attractive to Ruby/Python/Java developers, which is where I think a lot of Go programmers come from. Speaking of Java, I wouldn’t be surprised to see Go end up as the ‘new Java’ given the easier deploy story and the similar sort of vibe I get from the language. If you’re just looking for a ‘better’ Ruby/Python/Java, Go might be for you, but I would encourage you to look further afield."

This reminds me of The Story of Mel [4].

If you're someone who enjoys programming and are writing the code for fun, I agree. Find the most unique language and do it in the most elegant way. Programming is almost an art, and if you're trying to be artistic, unique langauges are great for it.

But not all software is artistic.

> "Good languages help evolve your approach to programming; LISP shows you the idea of code as data, C teaches you about working with the machine at a lower level, Ruby teaches you about message passing & lambdas, Erlang teaches you about concurrency and fault tolerance, Haskell teaches you about real type systems and purity, Rust presumably teaches you about sharing memory in a concurrent environment. I just don’t think I got much from learning Go."

I don't think that all langauges need to be learning experiences. Sometimes you just need to get shit done.

[0]: https://benkurtovic.com/2014/06/01/obfuscating-hello-world.h...

[1]: https://talks.golang.org/2012/splash.article

[2]: http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-in...

[3]: https://benchmarksgame.alioth.debian.org/u64q/go.html

[4]: http://www.catb.org/jargon/html/story-of-mel.html

Re: A year with Go

#32

Post by edgyswingset »

eloff wrote: post #7
smegel wrote: post #3

> if I wanted a language built around concurrency I’d use Erlang or Haskell. And if you wanted a concurrent language that wasn't a functional language what would you use?

Or just a practical concurrent language with strong libraries that lets you be productive quickly. I'm aware of many of the theoretical benefits of Erlang and Haskell over Go. But Go is still a much better choice for getting things done.

C# has had excellent concurrency support for quite some time, and is most definitely a utilitarian language.

Of course, the elephant in the room is needing a windows-based infrastructure ... but if that's not a huge barrier, it's not an unreasonable choice.

Re: A year with Go

#33

Post by baby »

4ad wrote: post #23

> I also, apparently, don’t understand Go’s pointers (C pointers I understand fine). I’ve literally had cases where just dropping a * in front of something has made it magically work (but it compiled without one). Why the heck is Go making me care about pointers at all if it is a GC’d language? Well, sorry, but if that's your level of understanding after one year of Go, I'm furious I wasted time to read your article…

As I understand it, GO makes it so you can use both a pointer or the object itself to access it methods.

And when you define an object method (or I don't know how it's called when you do this:)

func (*string) uppercase(){

    // make uppercase
}

Then by saying you use a pointer means you will modify the value when you do this: mystring.uppercase()

So it's not really pointers, it's more an idea of pointers.

Re: A year with Go

#34

Post by matthewmacleod »

mikeokner wrote: post #11

I think the author gets closest to the mark in the Conclusion, but still falls short. Go is very attractive as an "upgrade" from Ruby/Python or Java. It's a good replacement for the interpreted languages when speed/performance matters and it makes the async paradigm feel much more accessible. And compared to Java, the fact that Go compiles to a native binary is a huge benefit. It's not a replacement for C or a good "…

In some ways, this is correct. Go is much more simple and consistent than Ruby or Java, has a better deployment story, and better tooling in some ways.

As a language, it's much less enjoyable to write. Yes, the concurrency primitives are much better, and that's a good programming tool. But to a developer coming from Ruby, code is often needlessly repetitive and obtuse to write. It ends up being overly verbose, full of copypasta, and much less expressive.

It's got it's niche – I've found it useful for writing small command-line utilities, and it's been surprisingly helpful at putting together a good deploy story for some work I've done on the Raspberry Pi (with the benefit of being well-structured and reasonably performant).

But I wouldn't like to use if full-time – mostly because it's just so weirdly irritating to write.

Re: A year with Go

#35

Post by sanderjd »

eloff wrote: post #7
smegel wrote: post #3

> if I wanted a language built around concurrency I’d use Erlang or Haskell. And if you wanted a concurrent language that wasn't a functional language what would you use?

Or just a practical concurrent language with strong libraries that lets you be productive quickly. I'm aware of many of the theoretical benefits of Erlang and Haskell over Go. But Go is still a much better choice for getting things done.

This is what I think (hope?) Elixir could be: a bit more practical (familiar? convenient?) language with the same concurrency support as Erlang. Maybe after another couple years of maturing libraries.

Re: A year with Go

#36

Post by skymt »

dvt wrote: post #12

Funny how HN was on the Go bandwagon just a few years ago, and now an article like this is almost unanimously upvoted (without much contrarian discussion(!)). I contributed to Go in the early phases and I really enjoyed using it and learning it, but I found myself going to either Java if I wanted to write something for production or Node if I wanted to write something as a prototype. Unfortunately, I haven't used it…

It's typically not a good idea to choose technology based on fashion. If you like what Go has to offer, it's there for you to use, and don't let the hype backlash get you down. Maybe start with a small personal project, if you don't want to commit to working with it "in production."

Re: A year with Go

#37

Post by vezzy-fnord »

dvt wrote: post #12

Funny how HN was on the Go bandwagon just a few years ago, and now an article like this is almost unanimously upvoted (without much contrarian discussion(!)). I contributed to Go in the early phases and I really enjoyed using it and learning it, but I found myself going to either Java if I wanted to write something for production or Node if I wanted to write something as a prototype. Unfortunately, I haven't used it…

Go has always had quite a mixed reception on HN, even if articles about it ostensibly are part of a voting trend.

Generally, trying to approach Go from any perspective related to PL theory is bound to be fruitless, primarily because the context of Go is that of Rob Pike's gradually evolving research languages, which have always been imperative, based on a few primitive constructs and having some form of CSP-like concurrency model built in. Much of it overlaps with principles explored in Plan 9 and Inferno, where holistic systems thinking has been the norm, and so Go makes sense as a language built by systems hackers used to dealing with infrastructure, rather than being conjured from the academic PL scene.

Much as Alef superseded Newsqueak, so Go has superseded Limbo.

Re: A year with Go

#38

Post by meowface »

nickysielicki wrote: post #31

> "I just don’t understand the point of Go. If I wanted a systems language, I’d use C/D/Rust, if I wanted a language built around concurrency I’d use Erlang or Haskell." Agreed. C and Rust are systems langauges, Go is not particlarly great in that category. That is okay. I will say, I hope you have fun getting an average CS graduate to properly write and maintain a Haskell or Erlang program with concurrency. Go is st…

> You won't see anything like in python or perl where you're almost expected to abuse the langauge internals (see this awesome example in python [0]).

You linked to someone intentionally trying to obfuscate Python as much as they can. Programmers are certainly not "almost expected to abuse the language internals". All dynamic languages provide various means for code obfuscation... it doesn't mean the language encourages obfuscated code. With the notable exception of Perl.

Re: A year with Go

#39

Post by meowface »

matthewmacleod wrote: post #34
mikeokner wrote: post #11

I think the author gets closest to the mark in the Conclusion, but still falls short. Go is very attractive as an "upgrade" from Ruby/Python or Java. It's a good replacement for the interpreted languages when speed/performance matters and it makes the async paradigm feel much more accessible. And compared to Java, the fact that Go compiles to a native binary is a huge benefit. It's not a replacement for C or a good "…

In some ways, this is correct. Go is much more simple and consistent than Ruby or Java, has a better deployment story, and better tooling in some ways. As a language, it's much less enjoyable to write. Yes, the concurrency primitives are much better, and that's a good programming tool. But to a developer coming from Ruby, code is often needlessly repetitive and obtuse to write. It ends up being overly verbose, full o…

I wish there was a language somewhere in between Ruby/Python, Elixir, and Go.

Re: A year with Go

#40

Post by RyanZAG »

smegel wrote: post #3

> if I wanted a language built around concurrency I’d use Erlang or Haskell. And if you wanted a concurrent language that wasn't a functional language what would you use?

Probably Java (or other JVM lang) running something like Disruptor for high performance, or actor based libraries like Akka for general use case. No numbers, but considering how it's used in nearly all the bigger tech and finance companies, I'm guessing it probably has more use as a highly concurrent platform than anything else discussed here.
Post reply on HN