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

11–20 of 49 posts

Re: Why We Use Go

#11

Post by scrollaway »

Dewie3 wrote: post #5
scrollaway wrote: post #3

> It’s not all that different from your users requesting features after you release a product and telling those users they aren’t smart enough to use them. Wanted to address this point separately. This sort of design is something you will find very often in well-designed video games: authors saying no to good features because they'll be misused and/or, on a grander scale, hurt the product. I've enjoyed the little I p…

Games seem to have a shorter lifespan[1] than PLs. Certainly from an economical perspective. Does the design have to be perfect? No -- just make a good enough game and then make a sequel that incorporates slightly other ideas (and that is always inferior to the original, apparently... or was that for movies). [1] Surviror bias note: we might mostly tend to compare newfangled languages to well-established languages, i…

Games have shorter lifespans because they are consumable: you play them and throw them away. It gets slightly more comparable when there are games on which you can build a business/career (esports-types, MMOs etc). In fact, if you look broadly at the numbers from the last decades, popular games of that type last for roughly 1.5 gamer generations (~10-12 years), and popular programming languages last for roughly 1.5 software engineer careers (~25-30 years). There are of course very long runners in both categories.

Re: Why We Use Go

#12

Post by coolsunglasses »

scrollaway wrote: post #10
Dewie3 wrote: post #4

Earlier quoted context omitted.

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

There is no language which is going to prevent you from shooting yourself in the foot. At best they will make sure the bullet is not also poisoned. However, there are a lot of languages which encourage bad patterns (like mixing app and view logic, or implicitly convert arrays into numbers when comparing them to strings or something, he said, referring to no language in particular). Python is not one of those language…

>There is no language which is going to prevent you from shooting yourself in the foot.

How many guns and how big are the guns that are pointed at my foot? Is it an ion cannon or an airsoft gun?

Most can agree one can be a happy user of $XLANG, but there are gradations of advantage depending on what you're working on.

Plenty of people out there that are happiest working in C, but I don't think many would say it's the safest or most productive language to work in.

Also worth thinking about how easy it is to extract meaning from software just by reading it. Explicit datatypes, specifications, grammars, etc. can all help with that. Even better is tools that can make sure your program faithfully represents an implementation of those specifications and act as a denser mental encoding of code than code itself is capable of being.

Re: Why We Use Go

#13

Post by [deleted] »

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.

[deleted]

Re: Why We Use Go

#14

Post by mahmoudimus »

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 understand. JetBrains did a great job also making it "boring." It felt like it was a boring attempt at making Java programming enjoyable. Along with 100% interoperable with Java libraries, alongside incredible tooling, made writing reasonably boring but functioning code very enjoyable.

To each their own, but I'm having a hard time justifying why I'd use something like Go over something like Kotlin. Maybe I'm missing something?

Re: Why We Use Go

#15

Post by fallat »

Is it just me or has this same article or title come up like 2-3 other times? The only thing remotely interesting in this particular article is the graph with productivity vs code-base size...mostly because when you give it some thought, is actually wrong. An expert programmer will be as efficient as any other expert programmer. The code-base will still grow and they will still remain productive. This guy is talking about what happens in this era, how that's our "average". If we up the average so everyone is proficient with language X, we wouldn't see this issue.

Re: Why We Use Go

#16

Post by welder »

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

Re: Why We Use Go

#17

Post by Manishearth »

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.

That's still a large codebase, now you need to jump back and forth between API docs to be sure you're giving it the correct type.

Re: Why We Use Go

#18

Post by bliti »

Here is why I use it (personal opinion):

- Its simple. Stupid simple. I can focus on writing code that is simple to grasp while following conventions.

- Its fast. Sure, its not the fastest language out there, but its hard to argue with its performance.

- Its feels like a lower level Python. Sometimes I think that's the main goal of the project.

- It comes from a respectable source. This means that it will probably exist in the next ten years.

- Setting it up is simple. No need to deal with runtimes like Java.

- Others who write Go seems to stick to the conventions. I rarely find the kind of surprises that you would find in C++ code. Since Go is simple to understand, people can write code that feels more "common". C++, well, its not fully understood by many (including me).

One point is that I don't use it to serve HTML or anything like that. Only to do systems programming. Servers talking to each other and/or responding to RPC or rest calls. Don't really serve anything other than files/json/xml.

Re: Why We Use Go

#19

Post by jhferris3 »

fallat wrote: post #15

Is it just me or has this same article or title come up like 2-3 other times? The only thing remotely interesting in this particular article is the graph with productivity vs code-base size...mostly because when you give it some thought, is actually wrong. An expert programmer will be as efficient as any other expert programmer. The code-base will still grow and they will still remain productive. This guy is talking…

The mythical expert programmer...

Everyone has a cognitive limit on what they can keep track of/in working memory. Once your codebase exceeds that limit (in # of files, lines of codes, types, interfaces, etc.) you lose productivity. 10k lines of python is a lot harder to grasp than 10k lines of go.

And that's not even considering the ramp up time for someone new to the code to jump in, which is even worse in most dynamic language codebases.

Re: Why We Use Go

#20

Post by chadaustin »

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 find this particular argument rather frustrating.

"Dynamic languages are fine as long as you don't do stupid things." One of the huge benefits of static types is that you can extricate yourself from those situations because the compiler can help guide you through large scale refactorings safely.

It's not even that the team is bad or that the authors of the code were ignorant - it may just be that the software has evolved to where the initial code no longer fits the problem exactly.

"Don't be stupid" is completely unactionable advice.

Post reply on HN