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

51–60 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#51

Post by randomdata »

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.

> Also the entire compiler toolchain and everything is written in Go and doesn’t depend llvm etc.

Depends on which implementation you're talking about. One of the stated goals of the Go project is that there must not be just one implementation. gc does not, but tinygo depends on llvm. gccgo depends on gcc.

Re: Lies we tell ourselves to keep using Golang

#52

Post by georgia_peach »

I believe he wrote a binary diff/patch system in it. If I had to do such a thing in Go, I would also hate Go.

He should just own up to trying to shove the square peg into the round hole and move on with his life, rather than blame the peg. There is no shame in it. At one point or another, we've all done it.

Re: Lies we tell ourselves to keep using Golang

#53

Post by steaminghams »

I generally like go and also see its problems as the author does.

However, with respect to the points about Go as a prototyping/starter language, there is not better language to start writing a project with in my opinion. Lots of languages have big communities of packages of various levels of maintenance but almost no other language has a standard library that is as usable as Go with the same guarantees between versions. I think its the biggest downfall of all these new languages like Rust/Zig/Hare etc, they all go for these minuscule standard libraries. I have no wish to start a project with any of them as all of them would involve I hunt down the 'best' http library and the 'best' async library and weigh their upsides and downsides, so I just reach for go and crack out the code I need to get it done, nothing else lets me do that half as easily, maintenance may be harder but at least I'm probably going to spend less time maintaining the list of packages that are still usable.

Re: Lies we tell ourselves to keep using Golang

#54

Post by kevinmgranger »

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…

The problem is that you can still mutate a copy. But does the person mutating the copy realize it's a copy, and that it won't propagate?

It's also hard to keep a mental model of which builtin primitives are values (copy semantics) and which are references (reference semantics).

Arrays are values. Slices are references, but might be a reference to some dynamically allocated slice or an array. Appending to a slice makes a copy _of the slice_, but which might modify the array it came from. It's not possible to tell from the type if it references an array or not.

Maps have reference semantics too. Why is it that maps and slices are the only references that don't have a pointer star to denote that?

Re: Lies we tell ourselves to keep using Golang

#56

Post by streblo »

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 productive with. I've built successful companies where everything was written in python, the whole time people on HN telling me how I was using a lowly language because of things like whitespace significance or strings that were not unicode by default.

If you care about other stuff, fine. If you don't think go works for you, don't use go. Just stop telling people who are using go (and other productive languages) to stop using them because of obscure language design issues or obscure API choices that people rarely encounter day to day. That isn't what matters to most people, and it's actually bad advice.

The problem is that there are a ton of less experienced people reading stuff on HN (just as I once was) who will take this to heart but have nothing actionable to gain from it, except to think they're a bad developer using a bad language. They aren't, and they're not.

Re: Lies we tell ourselves to keep using Golang

#57

Post by fasterthanlime »

paskozdilar wrote: post #32
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…

For me, the goroutines + channels + select is what makes Go leagues above any other popular language. As far as I know, no other popular language allows you to read from multiple queues at the same time, which is an extremely useful pattern in concurrent programming. The only way to "select" from multiple sources in other languages is to use some kind of poll/select syscall on file descriptors - and even that is very…

> As far as I know, no other popular language allows you to read from multiple queues at the same time

Off the top of my head, that's certainly possible in Rust, C++ and Java - probably many others I just don't know about.

That particular bit of concurrency goodness comes from the 70s, so you can be sure other languages picked it up.

Re: Lies we tell ourselves to keep using Golang

#58

Post by foldr »

fasterthanlime wrote: post #50
foldr wrote: post #9

> Go's confusion between "type aliases" and "newtypes". The only way to make a newtype in go is to make a separate package with an opaque type and use interfaces for indirection, which is costly and awkward. It's very unclear what this is supposed to mean. 'type Foo int' in Go creates a new 'Foo' type that can't be used as an int without casting (a̶l̶t̶h̶o̶u̶g̶h̶ ̶y̶o̶u̶ ̶c̶a̶n̶ ̶a̶s̶s̶i̶g̶n̶ ̶a̶n̶ ̶i̶n̶t̶ ̶t̶o̶ ̶i̶t…

I moved some words around to make the nit less confused - thanks for the feedback!

Still not seeing it. You don't have to use interfaces to make an opaque type. A package boundary is sufficient.

Not sure why you would want a fully opaque type internally to a package anyway. A regular `type Foo Bar` declaration is sufficient to give you a `Foo` that can't be accidentally interchanged with a `Bar`.

Re: Lies we tell ourselves to keep using Golang

#59

Post by tristor »

I use Go. I love Go. The reason why is pretty simple for me: It gets things done in a way that feels comfortable and has strong tooling. I am well aware it has shortcomings. I occasionally even run into them. However, as someone who doesn't particularly /like/ writing code, and instead sees it as the inevitable requirement of creating things that do something for me, I really appreciate that Go for the most part doesn't get in my way so I can make things that do something and move on.

I generally heavily preference scripting/interpreted languages over compiled languages, because compiled languages have a bevy of stuff that qualifies as "getting in my way". Go is refreshingly not like that, and therefore is the primary compiled language I use these days, and largely the primary language I use at all. Then again, I'm not an SWE. I'm a SysOps/SRE turned PM-T. So it's unlikely I would ever dig deeply enough to care about the particulars of a language's design other than knowing which problems it is best at and which problems a better choice can be made to solve.

Both this article and his previous article, I've read thoroughly. I understand and appreciate the criticism. But fundamentally there's seems to be an implicit assumption within both articles that other developers who use Go don't already know (most of) these things. Anyone who uses Go long enough will eventually run into some of its shortcomings. I'm not sure exactly why it rubs me the wrong way, but it feels like there's something subtlety insulting in the way the author presents his arguments. Like if we weren't all stupid rubes we'd just use whatever his preferred language is (Rust, presumably?).

The way people get zealoted about languages these days (especially some pretty terrible ones for getting things done) tempts me to just go back to writing Perl. In all the languages I've used over the years, I've probably got more raw work done in Perl than anything else, and it's still near and dear to my heart, despite being objectively a badly designed language.

Re: Lies we tell ourselves to keep using Golang

#60

Post by photochemsyn »

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…

Having followed language wars for a while as a relative newcomer to programming (longtime lab rat type), my present conclusion is that languages are just tools, comparable in my experience to different laboratory techniques and instrumentation. Different tools are appropriate for different purposes. Some are a lot less convenient than others to set up and use. Some are so obscure that nobody really supports them anymore, and if you want to use them you'll have little help with troubleshooting. Some are popular fads that come and go, as people realize there are better options available for particular jobs.

Once you learn how to use one set of tooling well, it's not so hard to jump over to another one if you get a job in a lab that relies heavily on it. Same with languages.

Fanatical adherents of one option or another often have some ulterior motive ... like the lab who spent $2 million on that high-field NMR spectroscopy machine and is always trying to get people to use it so they can can get some co-author publications. Often the most vitriolic fights are over some technical detail or other that doesn't apply to the vast majority of use cases.

Conclusion: meh. Of course Python and C++ are the superior options, however. Plus C for things like writing low-level code for firmware etc. The fact that these are the only languages I have any experience with is entirely incidental to the truth of this claim.

Post reply on HN