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

Why I Don't Like Golang (2016)

teamten.com

Post reply on HN
Print view View original

161–170 of 237 posts

Re: Why I Don't Like Golang (2016)

#161

Post by philliphaydon »

makeitdouble wrote: post #154
philliphaydon wrote: post #81

Earlier quoted context omitted.

“I’ll pay $1000’s to get all setup and running with everything I need, including a bunch of stuff I don’t need, but not the last $90 for some productive software to make more money” Yeah ok.

Is this a JetBrains commercial account ? Am I at fault for not liking their product that much, and thus not paying them their apparently deserved yearly subscription ? This feels pretty weird to be faulted for using other companies' products. And no, switching to Jetbrains' doesn't make me more money. Could be the reverse from my past trials.

It's not about liking or not liking a product. You're complaining about pay for a product. If you like a product and its helpful why are you against paying for it?

Re: Why I Don't Like Golang (2016)

#162

Post by Beltalowda »

V-2 wrote: post #155
Beltalowda wrote: post #149

Earlier quoted context omitted.

Bit of an odd use of an anonymous function IMO. Normally I'd write that as: foo := "that" if bar { foo = "that" } Unless the assignment of "foo" is expensive, then you'd assign it in an else. If you really want to, you can do it in a single line too: foo := map[bool]string{true: "this", false: "that"}[bar]

These are rather nasty workarounds, to be honest. Instantiating a map out of the blue is clever, but not very readable (not to mention potential performance concerns eg. if it's code executing in a large loop), and something I'd definitely call out in code review. Note that computing "this" and "that" could by itself be costly, and one of these values is guaranteeed to get discarded.

I've used the map thing a few times, but sparingly. Mostly for things like setting something based on the value of a boolean commandline flag and the like where the performance impact doesn't matter and keeping it on one line offsets the "ugliness" of the construct. You should indeed avoid it for most other things.

Re: Why I Don't Like Golang (2016)

#163

Post by thegeekpirate »

Beltalowda wrote: post #149
thegeekpirate wrote: post #134

Earlier quoted context omitted.

For comparison, in Go it would be: foo := func() string { if bar { return "this" } return "that" }()

Bit of an odd use of an anonymous function IMO. Normally I'd write that as: foo := "that" if bar { foo = "that" } Unless the assignment of "foo" is expensive, then you'd assign it in an else. If you really want to, you can do it in a single line too: foo := map[bool]string{true: "this", false: "that"}[bar]

I was simply giving an example of only using a single assignment, as the parent stated:

> and you don't need two separate assignments.

Although I do use it far more often nowadays than a decade ago. I've even mentioned it before https://news.ycombinator.com/item?id=30384835.

Re: Why I Don't Like Golang (2016)

#164

Post by the_gipsy »

pjmlp wrote: post #160
xigoi wrote: post #146

Earlier quoted context omitted.

Do you have any other workflow that allows so much programmability and composability while being lightweight and cross-platform?

You mean the "cross platform" as long it is UNIX?

Enjoy duplicating your workflows anyway for CI. Or do you make a release by clicking the play button in your IDE?

Re: Why I Don't Like Golang (2016)

#165

Post by throwaddzuzxd »

srer wrote: post #115
LVB wrote: post #33

>The tried and true approach of providing a compare method works great and has none of these drawbacks. Agreed! https://pkg.go.dev/sort#Slice is wonderful. (Added a bit after this article was written, I think.)

Lets see what the Go doc example looks like: sort.Slice(people, func(i, j int) bool { return people[i].Name In Python one might write: people.sort(key=lambda person: person.name) Or in Rust: people.sort_by_key(|person| person.name); // sort_by is also an option... I think it's worth calling out exactly what is happening in the Go example: - We create a closure that captures the people slice - We pass the people slice…

It's worth noting though that Go's way is just 40 characters more than Python with an inline comparison function and Go's verbosity.

If I need to reverse the order, it looks easier to do with Go (just reverse the operator) than with Python and Rust way (I guess both have something like an "order" additional parameter).

Rust and Python both feel more elegant but I actually like Go's way.

Re: Why I Don't Like Golang (2016)

#166

Post by sangnoir »

sriram_malhar wrote: post #18
xigoi wrote: post #9

Earlier quoted context omitted.

Professional developers in the USA usually make 6 figures.

Musicians and carpenters make far less than programmers, but they still buy their tools. Software people are too entitled. Even if you are not professional, you can still afford 54c a day ($200 a year). Even a programmer in India can.

How much would a carpenter pay for a fancy bench top for their workshop? I'm guessing not a lot, since they can make one themselves.

Programmers are toolmakers, and are therefore harsh critics of tools they use; just like a carpenter will tell you everything that's wrong with the design, and choice of wood that went into a pricey, but ultimately-affordable-to-a-carpenter bench top. Having access to cheaper, good-enough alternatives is part of it.

Re: Why I Don't Like Golang (2016)

#167

Post by Zababa »

taki_mekhalfa wrote: post #111
gorgoiler wrote: post #97

I’d like to get into go but in the past I’ve always been burned by not being able to quickly refactor my code. If I want to change the contract of get_kittens so that it returns a set instead of a list, I found it quite tiresome to then go to all the call sites of get_kittens and change their types to match. What was I doing wrong?* Perhaps there’s a cleverer tool out there that can infer and implement these type cha…

This is true for all typed languages though..

No, type inference avoids this issue.

Re: Why I Don't Like Golang (2016)

#168

Post by dizhn »

einpoklum wrote: post #130
sriram_malhar wrote: post #18

Earlier quoted context omitted.

Musicians and carpenters make far less than programmers, but they still buy their tools. Software people are too entitled. Even if you are not professional, you can still afford 54c a day ($200 a year). Even a programmer in India can.

1. A Musician has one tool. Ok, maybe a note-stand etc. But in software, there are thousands of "tools" you can buy. 2. Physical tools vs making copies of some bytes. No need to retread this here, but bottom line: Not comparable.

I wonder if anybody has 'one' guitar. I don't really know anyone who does.

Re: Why I Don't Like Golang (2016)

#169

Post by xigoi »

pjmlp wrote: post #160
xigoi wrote: post #146

Earlier quoted context omitted.

Do you have any other workflow that allows so much programmability and composability while being lightweight and cross-platform?

You mean the "cross platform" as long it is UNIX?

Windows has WSL. Is there any other major non-Unix platform?

Re: Why I Don't Like Golang (2016)

#170

Post by sokoloff »

sam0x17 wrote: post #83
bmitc wrote: post #25

Earlier quoted context omitted.

What's even worse is getting companies to pay for this stuff. Getting a company to buy software to help you do your job is like pulling teeth.

I dunno I've been in plenty of situations where a department head will literally beg me to buy things so they can reach the same budget spend as last year so their budget isn't slashed (DoD), and have seen the same situation in VC-backed startups looking to come up with tax write offs. Businesses for the most part love spending money and would rather do that than pay taxes, which is definitely a problem with corporat…

No sane business wants to spend $100 to save $15-30 in taxes.
Post reply on HN