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

What Golang Is and Is Not

danmux.com

Post reply on HN
Print view View original

181–190 of 279 posts

Re: What Golang Is and Is Not

#181

Post by pcwalton »

geodel wrote: post #173
pcwalton wrote: post #138

Earlier quoted context omitted.

That post's numbers are entirely based a giant multi-gigabyte long-lived array: the classic worst case for a generational GC. That is not representative of most memory allocations. The generational hypothesis, which has been empirically verified in real world code again and again, is that most allocations are short-lived and small.

There were 3 points mentioned in post with only 1 about GC. Performance and memory efficiency were major points not delivered by standard idiomatic Java code. Considering the popularity of memory compact Java collections like Fastutils etc I feel that memory bloat of standard Java is very common issue plaguing Java applications.

If you read the comments, you'll find that the issue is in fact GC: specifically, the cost of tenuring objects.

Re: What Golang Is and Is Not

#182

Post by hiram112 »

tptacek wrote: post #151
sheepmullet wrote: post #146

Earlier quoted context omitted.

The grass is always greener.... > easy to hire for There are 100x as many experienced C# enterprise developers. And that is being conservative.

C#, Java, and Go serve basically the same demographic and have most of the same strengths. Both Java and C# have larger ecosystems but more intellectual baggage. People without long-standing affinities to Java or C#, but who have the systems programming problems these Java-likes solve, are likely to appreciate Go, because it's simpler to pick up and use. I think if you're proficient in one Java-like, you're single-di…

Neither Java nor C# are really adequate for 'systems' programming problems, assuming the term is being used colloquially - OS level problems using system API calls, process, threads, etc.

Both Java and C# are really more suited to enterprise services. It is difficult at best to communicate with the underlying OS behind the VM. you really need to be using C / C++ to reach the kernel on Unix. Probably the same on Windows, though I'm guessing .Net provides some sort of integration.

Re: What Golang Is and Is Not

#183

Post by kornish »

divan wrote: post #174
codygman wrote: post #24

As someone who writes Go every day for work, I can't agree that Go is simple. Using a language for analytics without generics can be quite painful and error prone. Go is a language that pushes remembering corner cases and failure conditions onto the programmer rather than the language and runtime itself. When you already have to remember a myriad of corner cases for business logic, also remembering so many corner cas…

> Go is a language that pushes remembering corner cases and failure conditions onto the programmer Can you elaborate on this? I write go for 3+ years and I have no idea what corner cases and failure conditions do you mean.

I presume an example would be something like remembering to check `rows.Err()` in `package sql` at the end of iterating through all rows. If you check the error each iteration while calling `rows.Scan()` but forget to check the `rows.Err()` at the end, it could potentially be much, much later that you find out something went wrong.

Re: What Golang Is and Is Not

#184

Post by bobbyi_settv »

IshKebab wrote: post #109
knucklesandwich wrote: post #9

Accusing other languages of suffering from paralysis of choice and fragmentation and offering "go get" as an example of solving this is truly ironic: https://github.com/avelino/awesome-go#package-management

Why? `go get` is an obvious default choice for package management. You don't have to make a choice. There would be paralysis of choice if when you install Go you were forced to choose from that list, but you aren't.

I don't see how something that doesn't allow pinning versions can be an obvious default choice for dependency management.

Re: What Golang Is and Is Not

#185

Post by andrepd »

mixmastamyk wrote: post #110
codygman wrote: post #24

As someone who writes Go every day for work, I can't agree that Go is simple. Using a language for analytics without generics can be quite painful and error prone. Go is a language that pushes remembering corner cases and failure conditions onto the programmer rather than the language and runtime itself. When you already have to remember a myriad of corner cases for business logic, also remembering so many corner cas…

> Nim is a very good language… Is it as good at concurrent services as golang is?

There are many use cases for which Nim might very well be a very good language other than concurrency.

Re: What Golang Is and Is Not

#186

Post by groovy2shoes »

thatswrong0 wrote: post #44
codygman wrote: post #28

Earlier quoted context omitted.

Go doesn't make real world programming easier. It makes you work hard for pointless things. Most of its problems are from a lack of generics.

Yep. Add those and a proper type system and you have yourself a decent language. But when the creator of the language doesn't see the value in abstractions [0], then it's probably never going to happen. [0] https://github.com/robpike/filter

Holy shit. Those are the longest implementations of `map` and `reduce` I've ever seen.

Re: What Golang Is and Is Not

#187

Post by [deleted] »

divan wrote: post #174
codygman wrote: post #24

As someone who writes Go every day for work, I can't agree that Go is simple. Using a language for analytics without generics can be quite painful and error prone. Go is a language that pushes remembering corner cases and failure conditions onto the programmer rather than the language and runtime itself. When you already have to remember a myriad of corner cases for business logic, also remembering so many corner cas…

> Go is a language that pushes remembering corner cases and failure conditions onto the programmer Can you elaborate on this? I write go for 3+ years and I have no idea what corner cases and failure conditions do you mean.

[deleted]

Re: What Golang Is and Is Not

#188

Post by sergiotapia »

randomdata wrote: post #38
sergiotapia wrote: post #3

The author is quite correct. Go is super boring, and runs fast. Two great points for it. For me however I just never felt happy writing Go code. I have a couple of open source projects with it, so I have put it through it's initial paces to see if we fit. The language that did make me happy was Elixir. Everything about the language and the surrounding tooling is polished. You end up with significantly less lines of c…

Are those really idiomatic examples though? For instance, without changing too much, you could implement scrapeProfile like this: https://play.golang.org/p/sP34n9acy7 I think that reads quite nicely, although I'm sure someone else can do even better. If you modified dumpToCSV to take an interface instead of the concrete type, you wouldn't even have to prepare the user structure. You could pass in the vcard directly.

I'm not sure if they're idiomatic. However, I did write both projects with the same amount of experience in each language. It goes to show then, how much easier it is to write idiomatic Elixir.

Also the elixir-lang Slack channel is just full of incredibly nice people. :P

Re: What Golang Is and Is Not

#189

Post by pcwalton »

TillE wrote: post #16
catnaroek wrote: post #5

Earlier quoted context omitted.

C++, otherwise a deeply flawed language, gives you more abstraction than Go and allows you to optimize and micromanage things more.

I love how C++ has had simple features like default arguments / function overloading for decades, while modern languages like Go and Rust require awkward workarounds. Swift 3 looks good, though. They've learned the right lessons.

There are also features that Rust has that C++ doesn't. So what?

Re: What Golang Is and Is Not

#190

Post by snaky »

drvdevd wrote: post #144
snaky wrote: post #71

Earlier quoted context omitted.

Looking at things people write in Go, I can't shake the feeling Go is a new /bin/sh with xinetd built in.

The way I personally use it ... I'd say you're exactly right. And adding that to an easy cross compilation/platform story that can side-step C toolchains in many cases, garbage collection, and intelligible concurrency, and you've got an extremely useful tool.

So the main reasons for Go are the fact 'coproc' keyword added to Bash since version 4 is still considered experimental[1] and the fact that a vast majority of modern developers don't know shell good enough.

[1] https://www.reddit.com/r/bash/comments/4ksl7w/golanglike_gor...

Post reply on HN