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

201–210 of 297 posts

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

#201

Post by 50 »

borgel wrote: post #196
50 wrote: post #193

Earlier quoted context omitted.

To piggyback this comment, does anyone know of any co's building something interesting mainly w/ the C programming language (and maybe even w/ Rust)? Also, that are usually open to interns/entry level programmers?

It's fairly common for folks doing embedded work. What are you interested in?

At the moment, I don't know. Do you any resources where one maybe may possible find something one would be interested in, in the C programming language domain? I've not thoroughly looked into compilers (i.e. LVMM) and operating systems but IIRC, they both went over my head.

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

#203

Post by LanceH »

mhh__ wrote: post #33
_bxg1 wrote: post #16

Earlier quoted context omitted.

Out of curiosity, what's the motivating case for using Go in 2019's programming landscape? Edit: I didn't mean this as an insult, I meant it as a genuine question. I don't know much about the Go ecosystem, and I meant to find out what Go's killer feature is in 2019, when other languages now have strong and elegant concurrency, C-like performance with higher-level syntax and without manual memory management, etc.

Sunk cost (In a good way). I do not like Go the language but I can begrudgingly admire the ecosystem

I use Ruby and Go in a complementary way.

I find myself choosing Go for:

- concurrency - memory footprint management - cpu speed - that nebulous feeling I want a program etched in stone (strongly typed)

I've written a lot of Api based clients. Read from a queue and update AWS permissions. Receive a callout from something and passing it along to somewhere else. Come to think of it, I've written a lot of queue-reading workers, some replaced existing Ruby workers for CPU or concurrency reasons.

I think in the space of having computers talk to computers Go is highly successful because it handles nearly everything with the standard library. So I find a lot of sdk's for specific platforms written in go that can get something going with the standard library and a single package for the platform.

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

#204

Post by fileeditview »

apta wrote: post #142
jayd16 wrote: post #64

Earlier quoted context omitted.

I see this complaint against Java a lot. If you're going to slum it in a language with no ecosystem so you don't feel overwhelmed, why not just use less of the Java ecosystem?

These complaints are usually by people who have not been using modern Java, or who have just been reading or hearing unsubstantiated claims about it. Or who haven't worked in large golang projects to see all the mess it brings with it because of how underpowered it is. Look up libraries like Spark[1] or Javalin[2] and you get something quite light weight. Or DropWizard[3] if you need something more holistic. That bei…

You are right that big (especially enterprise) projects in Go are also a mess. But one of the main reasons is that people have a Java (or C++) background and try to replicate all sorts of complexity.. not because Go is "underpowered".

Also if you compare those codebases to Java (again enterprise) projects of a similar size they seem quite readable instantly..

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

#205

Post by ecnahc515 »

saagarjha wrote: post #200
lacker wrote: post #189

Earlier quoted context omitted.

If you work for a while at a larger company that enforces a style guide, it starts to make total sense. If your company's style guide already insists that identifiers should be named with some convention that matches their visibility, then by making that part of the language, you are simplifying the system. I would not be surprised if specifically the Google C++ style guide influenced this decision.

Yes, but this forgets the fact that companies have different style guides.

That doesn’t exist for Go because of gofmt.

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

#206

Post by dx034 »

jeremyjh wrote: post #103
cr0sh wrote: post #60

Earlier quoted context omitted.

> Stopping compilation with an error for every unused import & variable is particularly annoying It's been a long while since I last touched Golang, but I recall the process of learning it. My coworker and I were tasked with creating an interface for our employer (a cloud service provider) to allow Rancher (or clients of Rancher - I forget) to use our backend system (which was built out of a combination of PHP, Java,…

This is a solved problem in every compiled language I've ever used - at least 10 of them. Unused variables is a warning, and your CI build compiles with a -werror / --warnings-as-error flag. Thats it. All the benefits you mention, without the "slowing down development" that you mention.

But people ignore warnings. The only way to keep code clean of unused variables and libraries (and prevent potential bugs where typos led to unused variables) is to disallow it completely.

In the end it's just about the variables anyway, most IDEs will remove unused libraries automatically.

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

#209

Post by toast0 »

coder543 wrote: post #109
liveoneggs wrote: post #105

Earlier quoted context omitted.

that cpu spike in BEAM is actually a runtime setting and doesn't reflect usage; it's intentionally busy-looping the connection accepts to reduce latency.

huh. that seems like a lot of waste for no measurable benefit: https://stressgrid.com/blog/beam_cpu_usage/ maybe it's beneficial to someone, but I don't think that should be the default. either way, it doesn't change the picture painted by the TechEmpower benchmarks.

In my experience, having clearer cpu metrics is more useful than any hypothetical latency benefits.

However, the hypothetical benefit would also depend on the cpu model; it made a little more sense when they introduced it than it does now. Back then, CPUs took a significant amount of time to change power states, so going to sleep and waking up for an event that comes shortly after could involve quite a bit of delay. Even if the processor didn't fully sleep, it may reduce the clock frequency, and not increase it until you've done a substantial amount of work.

With more recent processors, these delays are much smaller, and perhaps it would have made more sense to control the power states in another way, but there was some justification.

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

#210

Post by masklinn »

jstewartmobile wrote: post #117
tomohawk wrote: post #85

Earlier quoted context omitted.

After a long stint in enterprise Java land, Go was a really big adjustment. Mostly about letting go of unnecessary complexity. I didn't realize how much I didn't miss that complexity until I recently went back into Java. If you learn the golang way of doing things, the issues this guy mentions really are not something you run into.

One of the commenters on lobste.rs called boilerplate-heavy Go written by programmers coming from Java "Gova". From a lot of what I've seen, that is a useful description.

> One of the commenters on lobste.rs called boilerplate-heavy Go written by programmers coming from Java "Gova".

Not exactly a novel take: https://dirtsimple.org/2004/12/python-is-not-java.html

Post reply on HN