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

321–330 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#321

Post by zozbot234 »

busterarm wrote: post #283
conradludgate wrote: post #265

Earlier quoted context omitted.

I'm interested if you could elaborate on that? My company deploys many Rust (web) applications to production and I've not experienced these issues with cargo

It's either a problem that you have or you don't, but also one that you have to have a specific mindset to even recognize. To start off with, please read this: https://lwn.net/Articles/889924/ As you start having to worry about deploying to 10^5 scale machines you want your mindset to be more like the longtime kernel development folks. You want minimal dependencies. You want to build with minimal pulls to the interne…

You can use cargo vendor to import specific versions of your dependencies into your project for easy auditing, or cargo fetch to simply be more explicit about when to download from remote repositories (when combined with the --offline flag). The typical Rust "dependency" is small; it's more like a single .c or .cxx file than a conventional "library", except that it also plays nice with generic code unlike these languages.

Re: Lies we tell ourselves to keep using Golang

#322

Post by sophacles »

bayesian_horse wrote: post #233
mcluck wrote: post #105

I'm honestly surprised at the response to this article. I'm not involved in the Rust or Go spaces enough to have any strong opinions. This article was, yes, a little aggressive in tone but presented very honest and accurate information about a language that the author clearly has experience in. It seems like a lot of the people complaining in the comments didn't actually read the article. The author even explains how…

Many people say Go is a better language to scale a codebase than Python, mainly because of typing, but I really doubt it. I can't tell for sure, because I haven't done a lot of Go coding. But to me the stated problems and the general lower-level nature suggest a productivity loss compared to Python, on average.

I've written lots of python. Biggest codebase had ~100Ksloc of it.

I currently have a ~80Ksloc codebase in Go.

I like python. I dislike go.

I still hold the position that scaling a codebase is easier in go than in python.

* Goroutines + channels are generally easier for someone besides the author to reason about than their python equivalents, leading to a more consistency and better boundary definition.

* Python has a lot of magic in it - and that stuff is really cool, powerful and fun - but.. it also makes it incredibly easy to write stuff that works well together until it breaks in some wierd corner of a seemingly unrelated object somewhere.

* As python codebases grow, duck-typing becomes much less pleasant - you start seeing a bunch of `if isinstance(...)` in the code and eventually someone will come along and start implementing parts of a type system on top of the python code that exists (see also the previous point).

Those are the primary reasons for me, but there's also just a certain lack of friction in the go codebase (compared to python anyway) that I can't really describe well.

Re: Lies we tell ourselves to keep using Golang

#323

Post by thatswrong0 »

ploxiln wrote: post #261
mcluck wrote: post #105

I'm honestly surprised at the response to this article. I'm not involved in the Rust or Go spaces enough to have any strong opinions. This article was, yes, a little aggressive in tone but presented very honest and accurate information about a language that the author clearly has experience in. It seems like a lot of the people complaining in the comments didn't actually read the article. The author even explains how…

Let's not pretend that some flagging of this article represents all or most developers who use Go, and also not pretend that this post represents all or most developers who use Rust. What kinda gets me from this genre of post, is that it sounds like writing good software in any language besides Rust is impossible, or even impractical. Like 10 years ago it was impractical for anyone to enjoy writing good software. (Or…

I didn't get that desire for purity that you gleaned from it.

The fact is that (as the author pointed out) Golang is missing basic language features that other languages have adopted since the creation of C that eliminate whole classes of errors, and it's pretty easy to accidentally do the wrong thing as a result.

Nil pointer exceptions, for example, don't have to exist anymore.. and yet they do in Go because they couldn't be bothered to add sum types. Its type system is barely a step above a dynamic language. You have to write the same imperative looping code over and over because Rob Pike would rather just use a for loop than something mildly expressive like map or filter (https://github.com/robpike/filter). Every function that does meaningful work is littered with if err != nil { return err }. Etc.

It is easy to write code in Go, but IMO it's not easy to write and maintain a production grade system with any amount of complexity in Go because you _have_ to be careful, you can't encode invariants explicitly and let the compiler find problems for you, and you have to repeat yourself so often.

Re: Lies we tell ourselves to keep using Golang

#325

Post by conradludgate »

busterarm wrote: post #283
conradludgate wrote: post #265

Earlier quoted context omitted.

I'm interested if you could elaborate on that? My company deploys many Rust (web) applications to production and I've not experienced these issues with cargo

It's either a problem that you have or you don't, but also one that you have to have a specific mindset to even recognize. To start off with, please read this: https://lwn.net/Articles/889924/ As you start having to worry about deploying to 10^5 scale machines you want your mindset to be more like the longtime kernel development folks. You want minimal dependencies. You want to build with minimal pulls to the interne…

I agree that Rust does suffer a similar problem to NPM where there are many small packages that people will use together.

I do wonder what the solution is though because Go has the same problem as far as I can tell. It has a bigger stdlib so there's less need to reach out. But when you do, you're in the same state with lots of tiny packages that do 1 thing well.

I don't have much experience outside of Go/Rust/Node so I can point to maybe a few languages which I can see being the opposite:

C++ has a large stdlib, and boost. With C++ managing dependencies is your problem so I guess it's easier to have few megapackages.

Python feels the same for mathematical computing. Numpy, TF, Pandas are all huge. Conda is an event bigger bundle, again I think because using the standard pip tools is rather cumbersome and usually not what people want to do

So as far as I can see, it's either easy to share code for others to use, in which case you get dependency hell, or you make it hard to share dependencies, but you have larger more refined ones as a result.

Hard to say what's better

Re: Lies we tell ourselves to keep using Golang

#326

Post by myrrlyn »

unethical_ban wrote: post #37

> Why does the Go compiler suddenly care if we provide explicit values now? If the language was self-consistent, it would let me omit both parameters, and just default to zero. Without analyzing the rest of the post (which I read without having the skill to fully comprehend), this stuck out to me. Perhaps the language behaves one way and not another by design? It's abstraction. By using a Struct, I'm telling the func…

why isn't it inconsistent to allow creation of a record with missing components but to deny creation of a stack frame with missing components

Re: Lies we tell ourselves to keep using Golang

#327

Post by steveklabnik »

busterarm wrote: post #296
whimsicalism wrote: post #289

Earlier quoted context omitted.

I find it difficult to see a standard where Rust is not ready for "serious work" but Haskell is.

I can install a working Haskell toolchain with my package manager instead of the farcical `curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh`. If you're an automation-oriented kind of person like it's my job to be, setting up repeatable toolchians based around the above is a total crock of shit.

Which package manager do you use that doesn't have rustc and cargo packaged yet?

Re: Lies we tell ourselves to keep using Golang

#328

Post by altairprime »

dang wrote: post #284
pg_1234 wrote: post #282

Earlier quoted context omitted.

As someone coding in Go (and having doubts about the language) I find articles like this professionally valuable. They don't have to be correct, they just need to provoke meaningful discourse, which for me means crowdsourcing the insights of hundreds of fellow devs.

Yes. The problem here is that there was a big one of those just yesterday. HN does poorly with repetition, and throwing in the indignation aspect and the meta aspect (can you believe what an HN commenter said yesterday? the nerve!) guarantees that the thread will get high and go crazy. None of that is intentional, but it's a well-known failure mode, so the flags in this case were helpful. We've taken the [flagged] st…

Is there anything that can be done the next time the old 2020 post goes FP, to direct people to consider the 2022 followup as well? Or is that burden of “seriously, stop rehashing 2020 content instead of keeping up with the discussion” exclusively the author’s to bear?

Given the options I know of today for authors, if they’re still reading comments here, I’d recommend they replace the 2020 post with a redirect to the 2022 post, and include the 2020 post at the end of it fully intact. At least that would ensure the flamewars cycle on the complete conversation and not just half of it.

Re: Lies we tell ourselves to keep using Golang

#329

Post by fasterthanlime »

dang wrote: post #284
pg_1234 wrote: post #282

Earlier quoted context omitted.

As someone coding in Go (and having doubts about the language) I find articles like this professionally valuable. They don't have to be correct, they just need to provoke meaningful discourse, which for me means crowdsourcing the insights of hundreds of fellow devs.

Yes. The problem here is that there was a big one of those just yesterday. HN does poorly with repetition, and throwing in the indignation aspect and the meta aspect (can you believe what an HN commenter said yesterday? the nerve!) guarantees that the thread will get high and go crazy. None of that is intentional, but it's a well-known failure mode, so the flags in this case were helpful. We've taken the [flagged] st…

> We've taken the [flagged] stigma off the title above, so as not to rub salt in any wounds.

Sending it to page 2 when it's only 3 hours old and has more upvotes than almost everything on page 1 /and/ removing the [flagged] marker feels weirder to me than not doing anything, but eh.

Re: Lies we tell ourselves to keep using Golang

#330

Post by zanellato19 »

bombcar wrote: post #144
nightski wrote: post #99

Earlier quoted context omitted.

I mean, this is Hacker News. Not corporate programmer news. Building a successful company has very little to do with tech choices. But that doesn't mean we shouldn't discuss these things as tinkerers and hackers.

> Building a successful company has very little to do with tech choices. This is what Hacker News doesn't want to hear, and so needs to hear. Like obsessing over the school supply list at the beginning of the year and getting everything perfect; it's not the whole of success, nor is it even really a huge part. But it can be fun.

So many companies succeed _despite_ their tech choices and so many fail also despite their tech choices.

In the end, even at mostly software companies, if you don't have a good sales model, a good sales team, a good marketing team, its likely you will out of business soon.

Post reply on HN