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

191–200 of 279 posts

Re: What Golang Is and Is Not

#191

Post by snaky »

20yrs_no_equity wrote: post #155
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…

Having written a lot of elixir code and now spending my days writing Go code, I think of Go as a tragedy of missed opportunity. If go did concurrency correctly, the way elixir and erlang do it, it would be the language I want to use for everything (well and the pipe operator from elixir is really special.) But concurrency in go is a terrible hack, it's just slightly better multi-threading with all the deadlocks and m…

> concurrency in go is a terrible hack

And what in Go is not?

Re: What Golang Is and Is Not

#192

Post by patio11 »

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.

A corner case about Go which makes me absolutely crazy: calling Reset() on a timer which has already fired has the biggest gap between "What I expect to happen" and "What actually happens" of any stdlib I've ever worked with.

https://gist.github.com/patio11/bc883d566778c323742432c203e6...

(You can see it here in the playground, but try it on your local machine if you don't believe me and/or think the playground has an inconsistent understanding of what time actually means: https://play.golang.org/p/ltdV9dI609 )

Re: What Golang Is and Is Not

#193

Post by groovy2shoes »

Ericson2314 wrote: post #72
berkay wrote: post #69

Earlier quoted context omitted.

"Like lambdas, it can be a complicated concept to learn, but once you unlock this in you code, you write less code and accomplish more" With the caveat that anyone who may be maintaining/using/enhancing your code will also need to be able to "unlock" this. Keeping the language simpler has benefits beyond the initial code development.

Or, you know, we could actually learn something in accordance with the nice pay most of us get.

This is one of my biggest frustrations when these sorts of discussions come up. It seems a great many programmers -- amateurs, students, and even professionals -- resist learning anything new.

As programmers, we deal primarily in abstractions. Our programming languages offer formal tools for creating and manipulating abstractions. In my view, any language that offers more tools for abstractions is better than another language that offers fewer such tools. As a professional whose primary job is to deal with abstractions, any new kind of abstraction is of interest. All programmers should be not only willing to be constantly learning new techniques and new abstractions, but we should be eager to learn and apply these things. Bigger toolbox => better quality of life w.r.t. work.

Even at my day job, I've heard things like "that's too computer sciency for mere mortals". I'm sorry, are we not computer scientists? Are we in the habit of employing people who are not professional programmers to write our software? And to think I'm the only developer in the office without a master's degree, as if they all decided that once they graduated they were finished learning...

Heaven forbid you should have to learn something! To educate yourself! To grow in terms of knowledge and skill! Do we have "development goals" every year for no reason at all?

As if spending an hour or two learning something would kill you!

AAARRRRRRRRGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHH!!!

Re: What Golang Is and Is Not

#194

Post by reality_czech »

clappski wrote: post #137
IshKebab wrote: post #112

Earlier quoted context omitted.

It may be harder to write some things, but it definitely is easier to read Go code. Besides, while the language itself may be more verbose than it could be, the standard library is extremely pragmatic and terse. It's like the opposite of the standard C++ library. E.g. to see if a string starts with another string in C++: std::mismatch(prefix.begin(), prefix.end(), toCheck.begin()).first == prefix.end() In Go: strings…

In your C++ example you're giving `std::mismatch`, which is a generic algorithm. If you're so inclined you could provide a wrapper that has the same interface as the Go example, but you're comparing apples to oranges. I'd argue that `std::mismatch` is much _more_ pragmatic than the Go example, in that I can use it to check any lists of user defined types. In reality, these two methods do completely different things.…

Did you read the article? The fact that there is 1 way to do it in Go, and 100 different ways to do it in C++ (or some other older language) is a feature, not a bug.

Re: What Golang Is and Is Not

#195

Post by snaky »

bad_user wrote: post #85

As some people like to point out, I'd also like to remind that in 1968 Algol had: - user defined record types - user defined sum types - switch/case statement with support for sum types - unified syntax for value and reference types - closures with lexical scoping - parallelism support - multi-pass compilation Given that many mainstream languages don't offer even what Algo68 had, I personally understand how a Go deve…

> Go ignores all progress in programming languages for the last 40 years

That's not unusual at all. Look what Fran Allen said about previous language from those guys - https://news.ycombinator.com/item?id=11578995

Re: What Golang Is and Is Not

#196

Post by anant »

patio11 wrote: post #192
divan wrote: post #174

Earlier quoted context omitted.

> 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.

A corner case about Go which makes me absolutely crazy: calling Reset() on a timer which has already fired has the biggest gap between "What I expect to happen" and "What actually happens" of any stdlib I've ever worked with. https://gist.github.com/patio11/bc883d566778c323742432c203e6... (You can see it here in the playground, but try it on your local machine if you don't believe me and/or think the playground has a…

You never drained the longTimer channel, so when you say "We agree that longTimer has fired, right?"; that's not quite true. After you call Reset(), you're still getting the value from the first firing, because that's the first time you read from the channel at all.

The docs are quite clear on this behavior and say "Timer will send the current time on its channel after at least duration d." -- key words being at least and says nothing about when you choose to read from the channel.

Re: What Golang Is and Is Not

#197

Post by st3fan »

patio11 wrote: post #192
divan wrote: post #174

Earlier quoted context omitted.

> 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.

A corner case about Go which makes me absolutely crazy: calling Reset() on a timer which has already fired has the biggest gap between "What I expect to happen" and "What actually happens" of any stdlib I've ever worked with. https://gist.github.com/patio11/bc883d566778c323742432c203e6... (You can see it here in the playground, but try it on your local machine if you don't believe me and/or think the playground has a…

All standard libraries have their quirks, corner cases and peculiarities. This is not specific to Go. Or are you saying it is worse on Go?

Re: What Golang Is and Is Not

#198

Post by euroclydon »

patio11 wrote: post #192
divan wrote: post #174

Earlier quoted context omitted.

> 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.

A corner case about Go which makes me absolutely crazy: calling Reset() on a timer which has already fired has the biggest gap between "What I expect to happen" and "What actually happens" of any stdlib I've ever worked with. https://gist.github.com/patio11/bc883d566778c323742432c203e6... (You can see it here in the playground, but try it on your local machine if you don't believe me and/or think the playground has a…

Thanks for sharing! I read up on it. This whole "channel draining" concept seems powerful.

Re: What Golang Is and Is Not

#199

Post by chrismonsanto »

catnaroek wrote: post #52
Jtsummers wrote: post #33

Earlier quoted context omitted.

If we consider Go in the context of a systems (their definition) engineering language within Google's enterprise, limiting choice is not about how dumb the programmers are, but about ensuring conformity. Rewriting code is expensive. As my office knows well. We maintain lots of old embedded systems and have to periodically rewrite or rehost it because the old hardware platforms aren't available or aren't performant en…

> By ensuring that developers and architects conform to certain conventions Enforcing conventions is of course a good thing! The problem is how Go enforces conventions: (0) When Go enforces a convention mechanically, it's a triviality that can be adequately handled by external tools (e.g., naming, formatting, unused variables, etc.). (1) When a convention is actually useful (e.g., the correct way of using an interfac…

To be precise, you need to outlaw polymorphic recursion to be able to do full monomorphisation. I'm not sure if that's what you meant by "second-class" in this context

Re: What Golang Is and Is Not

#200

Post by reality_czech »

catnaroek wrote: post #11
bluejekyll wrote: post #6

> “There is nothing new under the sun” rings true in all languages since the 80’s. Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go. Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to…

> Go decided to not have generics, to keep the language easier to learn and more approachable. It's hard to argue with this one. Plain parametric polymorphism is super easy to understand. Standard ML could be learnt in a week by someone who doesn't know how to program. Admittedly, the interaction between parametric polymorphism and subtyping is tricky and subtle. And it seems most programmers have gotten used to taki…

I just spat out my coffee. Standard ML can be learned in a week by someone who doesn't know how to program?

Have you ever actually tried to teach someone who doesn't know how to program? It takes months, even when using a simple language like Python. Or even BASIC, which was designed specifically for beginners.

Standard ML is a good language (especially considering when it was developed, in the 1970s). Somehow a cult has grown up around it that prevents people from seeing that it isn't the solution to all problems, just another tool in the toolbox. Sad.

Post reply on HN