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

Lies we tell ourselves to keep using Golang

fasterthanli.me

Post reply on HN
Print view View original

61–70 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#61

Post by cglan »

I just don't see the issue with Go. After dealing with inscrutable errors in some python code that interfaces with OpenSSL. Or dealing with impossible to trace errors in Spring Boot. Or Javascript? An absolute nightmare from start to finish. There's something extremely nice to get an error, place a breakpoint and trace exactly (even if it's a third party library) that error is happening.

I will take all the footguns in the world for that ability. Plus in general the tooling is just amazing. I know there is other Unix tooling out there but I'm sorry, they kinda suck and are terrible to use. They're for the type of person who can use vim with their eyes closed and unfortunately that's not me.

The other footguns he mentioned? Valid. A linter will catch a chunk of them though. I just generally don't think they matter half the time. I think of it like the iPhone. It's a pleasure to use like 80% of the time maybe 85% and 10% it feels hacky and terrible to get something working and 5% you just can't or shouldn't do it.

So for the 80% use case (backend crud apps or backend web apis) I'd take Go every time. Plus it compiles almost instantly versus multi minute turnaround times in a lot of other languages.

Re: Lies we tell ourselves to keep using Golang

#62

Post by josephcsible »

innagadadavida wrote: post #42
kitd wrote: post #12

The author obviously doesn't like Go. Ok, he can have his own opinions. I've been coding professionally since 1987, using everything from mainframe assembler, Fortran, C, VB, Java, C++, to most recently Go. IMHO, the language itself plays a smaller role in its usefulness than most think. As important is the tooling, stdlib, ecosystem, community and "StackOverflow"-ability. Go has a few warts, like every language, but…

A couple of things to add to this: the language spec is like a page long and very readable. Also the entire compiler toolchain and everything is written in Go and doesn’t depend llvm etc. This doesn’t help the developer but is a pretty unique aspect of Go.

If a language spec is only a page long, it's leaving a bunch of important things unspecified.

Re: Lies we tell ourselves to keep using Golang

#63

Post by delta64 »

SeanLuke wrote: post #27

I don't know nothin' about Go. But this complaint really surprised me: > Go not letting you do operator overloading, harking back to the Java days where a == b isn't the same as a.equals(b) Does this guy really not understand that in a mutable language, (eq ...) is not the same as (equalp ...) and should never be confused with it? Also: operator overloading is the spawn of Satan.

The author definitely understands that. The point is: when you don't have operator overloading you get stuff like that which does demonstrably confuse many people

In languages with operator overloading this just isn't a concern at all because == does the obvious thing

Re: Lies we tell ourselves to keep using Golang

#64

Post by unethical_ban »

One more thing to note (on this post that is already on page 2 of HN after 47 minutes):

To me, as a scripter-ops kind of person, Go is useful as a Python variant. You get types, you get a huge standard library, and much of ops is network-based communication and glue code. The last job I had, I was tasked with rewriting a moderate Python lambda into golang as a POC for ease of use, and performance.

I relearned the basics of go in about two days, used google and docs copiously, but otherwise did not change the structure of the program.

The execution time was cut in half! It's an easy language to get using quickly and serves that purpose well. I wonder if the author could acknowledge the comparison to Python.

Re: Lies we tell ourselves to keep using Golang

#65

Post by 14113 »

kitd wrote: post #12

The author obviously doesn't like Go. Ok, he can have his own opinions. I've been coding professionally since 1987, using everything from mainframe assembler, Fortran, C, VB, Java, C++, to most recently Go. IMHO, the language itself plays a smaller role in its usefulness than most think. As important is the tooling, stdlib, ecosystem, community and "StackOverflow"-ability. Go has a few warts, like every language, but…

From the article: "[...] as developers get more and more senior, they tend to ignore more and more problems, because they've gotten so used to it. That's the way it's always been done, and they've learned to live with them, so they've stopped questioning it any more."

Re: Lies we tell ourselves to keep using Golang

#66

Post by prophesi »

I use Go for simple CLI apps and it's pretty dang good for that. They're used by coworkers, contractors, and clients so the fact I can just send over an executable for any OS is really nice.

I wouldn't use it for anything too complex, or requiring a GUI. Mainly because I'd be much better off using the languages in my day job that I'm more familiar with.

Re: Lies we tell ourselves to keep using Golang

#67

Post by [deleted] »

wara23arish wrote: post #17

Im a go noobie so I had a question about the following. > Go's lack of support for immutable data — the only way to prevent something from being mutated is to only hand out copies of it, and to be very careful to not mutate it in the code that actually has access to the inner bits. I thought everything was handed out as copies in go by default unless a pointer was being passed. So this would make it “easy” to tell wh…

[deleted]

Re: Lies we tell ourselves to keep using Golang

#68

Post by wara23arish »

ainar-g wrote: post #39
wara23arish wrote: post #17

Im a go noobie so I had a question about the following. > Go's lack of support for immutable data — the only way to prevent something from being mutated is to only hand out copies of it, and to be very careful to not mutate it in the code that actually has access to the inner bits. I thought everything was handed out as copies in go by default unless a pointer was being passed. So this would make it “easy” to tell wh…

They mention it elsewhere in the post, but there are a few types that are essentially pointers but don't look like pointers. Slices, maps, interfaces, and channels (and also functions, but that isn't that important here). So you cannot just think that anything that doesn't have an asterisk is a copy. Besides that, there is also the fact that slices share underlying array storage, and `append` doesn't make a copy unle…

I see! Thank you for the example that was helpful.

I read through the example regarding the struct containing the map. I recently ran into that when working on something.

slightly meta: So how can one evaluate whether that is a good decision or bad?

Does forcing the programmer to use make explicitly for maps help prevent errors or is it tedious and better off having the zero value of map not cause errors?

Re: Lies we tell ourselves to keep using Golang

#69

Post by tomlin »

streblo wrote: post #56

I didn't care in the last post and I don't care about this one either. I care about my productivity, I care about my team's productivity, and I care about getting stuff shipped. Those are the things I care about, and go works great for that. If you care about those things too, and you're using go, you shouldn't stop using go. My whole career people have been telling me to stop using languages or tools I've been produ…

I think your POV works in your very specific world view. As a head of an agency, hiring a developer that knows mainline languages serves a lot of good in hiring, keeping teams happy, and low turnover. We've all seen the agencies that hop on a new, hip language - only to go up in flames 6 months later because they couldn't find talent for their narrow viewpoint.

This isn't an argument against Go, moreso that your perspective is objectively elitist.

Re: Lies we tell ourselves to keep using Golang

#70

Post by penlightment »

It's the matter of one's opinion, I personally love it. The design has +n years of experience behind it and stands on shoulder of some serious people (yea you already know who they are).

Every language has its own gotchas, and if you are not satisfied with it, coding some Java might help you gain a little perspective.

Post reply on HN