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

Why We Use Go

bravenewgeek.com

Post reply on HN
Print view View original

21–30 of 49 posts

Re: Why We Use Go

#21

Post by IndianAstronaut »

Dewie3 wrote: post #4
scrollaway wrote: post #2

> Previously, we worked almost exclusively with Python, and after a certain point, it becomes a nightmare. You can bend Python to your will. You can hack it, you can monkey patch it, and you can write remarkably expressive, terse code. It’s also remarkably difficult to maintain and slow. Performance aside which is a weak point of python, the language is certainly not inherently unmaintainable. My most maintainable an…

> My most maintainable and enjoyable projects are all in Python, you just have to not do stupid things which would make any project unmaintainable (like say no to spaghetti inheritance). That's what they all say though. Low level, high level, static or dynamically typed -- it's not a problem as long as you don't do stupid stuff.

> it's not a problem as long as you don't do stupid stuff

Easier said than done on large codebases with wide variety of contributors.

Re: Why We Use Go

#22

Post by learc83 »

I feel about the same way the author does.

I've written one largish (large for a 3 man team) production codebase in go (as well as numerous side projects). At first I loved it--it was simple, and I really loved the fact that it compiles to a native binary. I also really liked gofmt. But looking back through what the code has evolved into 2 years later, a huge portion of it is essentially copy and paste code to work around the lack of generics. Another large portion is copy and paste error handling.

I was essentially using go to fill several niches. I wanted a higher level language to handle business logic, but I also needed to work with serial ports, and I wanted something that would run fast with a small memory footprint.

Go seemed to fit the bill perfectly, but eventually go started to feel like jack of all trades master of non type of thing. Since I had to eventually rewrite my serial port code in C anyway, I think I would have been better choosing a language with more modern features for the rest of the project.

Maybe it's because I've been using F# (and C# to a lesser extent) lately, but I just don't think I want to go back.

Re: Why We Use Go

#23

Post by Manishearth »

This is a nice take on the language; and doesn't descend into the regular lampooning ("lol no generics") that's found on languagey posts. Kudos!

> The attitude of the decision making around the language is unfortunate, and I think Go could really take a page from Rust’s book with respect to its governance model.

(I wrote part of Rust's current governance model and was a part of polishing it up; though I wasn't so involved when Rust initially started using a consensus based model. I've also tried Go, and written about it [1])

... I don't know if this would work out so well. One of Go's strengths (also weaknesses, but it is a strength) is that the language designers can afford to just make hard decisions for everyone. This is where the simplicity comes from, IMO. Rust is complicated because it tries to cater to a wide range of needs. Go makes decisions even if they cut out use cases, and the language stays simple. Both approaches are valid; but IMO switching approaches would make Go lose one of its best plus points.

[1]: http://www.polyglotweekly.com/2015/04/24/thoughts-of-a-rusta...

Re: Why We Use Go

#24

Post by viraptor »

welder wrote: post #16

> Dynamic typing allows you to quickly build and iterate but lacks the static-analysis tooling needed for larger codebases Large codebases, ewww. Instead separate things into smaller projects, each easily maintainable on it's own.

Openstack is a very good example of a very large python codebase split into smaller projects. But it's still a large codebase. It's still hard to work with different components and the only thing that happens to hold it together are loads and loads of tests and lints which try to come close to what static analysis could provide.

Re: Why We Use Go

#25

Post by Manishearth »

mahmoudimus wrote: post #14

OP makes some reasonable arguments about the practical uses of Golang, but anecdotally and seriously evaluating it for a complex backend service, I felt that I had to write a non-trivial amount of "simple" code that felt like a mix of copy & paste procedural code with some very shallow object oriented programming. I attempted to write the same service in Kotlin ( http://kotlinlang.org ), which felt mature and easy to…

I think "To each to their own" is exactly the OPs point -- Go worked for them, but that doesn't say much about whether or not it will work for you (and vice versa). So you're probably not missing anything :)

Re: Why We Use Go

#27

Post by bsdetector »

Manishearth wrote: post #23

This is a nice take on the language; and doesn't descend into the regular lampooning ("lol no generics") that's found on languagey posts. Kudos! > The attitude of the decision making around the language is unfortunate, and I think Go could really take a page from Rust’s book with respect to its governance model. (I wrote part of Rust's current governance model and was a part of polishing it up; though I wasn't so inv…

What they are getting at is that the Go designers are stubborn and the Rust designers are open-minded... but they don't want to just come out and say that.

For instance both had green threads. Rust designers ran into all the problems with them like interop with anything else and interrupts and fairness, so like everybody else that did M:N threading they threw up their hands and said "well it looked like a good idea at first" and removed it. Go designers literally called it a "rabbit hole" and followed it down to whatever crazy lands it lead to, because they promised people green threads so they had to keep it.

Re: Why We Use Go

#28

Post by Manishearth »

bsdetector wrote: post #27
Manishearth wrote: post #23

This is a nice take on the language; and doesn't descend into the regular lampooning ("lol no generics") that's found on languagey posts. Kudos! > The attitude of the decision making around the language is unfortunate, and I think Go could really take a page from Rust’s book with respect to its governance model. (I wrote part of Rust's current governance model and was a part of polishing it up; though I wasn't so inv…

What they are getting at is that the Go designers are stubborn and the Rust designers are open-minded... but they don't want to just come out and say that. For instance both had green threads. Rust designers ran into all the problems with them like interop with anything else and interrupts and fairness, so like everybody else that did M:N threading they threw up their hands and said "well it looked like a good idea a…

True. For the record I like the Rust model a lot more (obviously, as a contributor, I should); but what I'm saying is that there's a tradeoff and both have their good parts. The moment you're open to some community decision making, you're expected to be open to all of it -- Go doesn't get much flak from the community for unilateral decisionmaking. I bet it would if it started to allow some community consensus on some decisions. And like I said, the "let the community decide everything" model probably wouldn't work for Go, so unilateral it is :)

Re: Why We Use Go

#29

Post by bottled_poe »

scrollaway wrote: post #2

> Previously, we worked almost exclusively with Python, and after a certain point, it becomes a nightmare. You can bend Python to your will. You can hack it, you can monkey patch it, and you can write remarkably expressive, terse code. It’s also remarkably difficult to maintain and slow. Performance aside which is a weak point of python, the language is certainly not inherently unmaintainable. My most maintainable an…

Agreed. If you don't carefully control the design of your system, how can you expect to control the code base? I'd say something about waterfalls... but I feel I'd be downvoted into the abyss.

Re: Why We Use Go

#30

Post by dasil003 »

scrollaway wrote: post #2

> Previously, we worked almost exclusively with Python, and after a certain point, it becomes a nightmare. You can bend Python to your will. You can hack it, you can monkey patch it, and you can write remarkably expressive, terse code. It’s also remarkably difficult to maintain and slow. Performance aside which is a weak point of python, the language is certainly not inherently unmaintainable. My most maintainable an…

I primarily use ruby, and I agree it doesn't have to be unmaintainable, but I also think that static typing will eventually win because it's easier to make type systems more powerful and expressive than it is to make programmers smarter or able to fit a larger system in their heads.

One reason dynamic typing has so much mindshare is because the comparison was always against Java which not only has some of the most boilerplate, but can't even prevent a null pointer exception. So in effect Java is 50% safer at 5x the cost of well designed Python program. However a language like Haskell actually brings real value from the type system (among other things), so you get more like 5x the maintainability at 50% the cost.

Obviously those are just made up numbers, and we can debate the particulars of Haskell vs other modern type systems, but it seems clear to me that is the richest soil for future gains in software maintainability and correctness.

Post reply on HN