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

211–220 of 279 posts

Re: What Golang Is and Is Not

#211

Post by olalonde »

xiaoma wrote: post #116
jksmith wrote: post #78

What we like to keep missing is that golang innovates not as a language, but as a tool to contribute to software project success. Project success in the software industry is abysmal, and we still keep thinking we can spin up another language that will contribute to project success because it let's us express ourselves in new ways. Well, how's that working out so far? The reason why golang appears to have such wide ad…

Go has been around nearly a decade with the backing of none less than Google and yet it remains a fairly fringe language. Elixir is on a much steeper adoption curve. So is Swift, but Elixir doesn't even have a tech heavyweight behind it.

What leads you to believe Elixir is on a much steeper adoption curve? I'm a bit surprised by that statement because I've seen a lot of open source projects written in Go (Docker, IPFS, Kubernetes, etc.) but none in Elixir.

Re: What Golang Is and Is Not

#212

Post by codygman »

snaky wrote: post #108
codygman wrote: post #97

Earlier quoted context omitted.

Go is more from the typed world than Python where I came from. It will tell you at compile time you are using a string rather than an int (unless you use interface{}).

The only difference is a selection of basic types. There's just no such types as string or int in Perl, Perl is a contextually polymorphic language whose scalars can be strings, numbers, or references (which includes objects). Although strings and numbers are considered pretty much the same thing for nearly all purposes, references are strongly-typed, uncastable pointers with builtin reference-counting and destructor…

For me the compile time and runtime distinctions are more important.

Re: What Golang Is and Is Not

#213

Post by codygman »

IshKebab wrote: post #112
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.

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…

> The Go standard library is full of things that do exactly what you want them to, whereas in other languages you have to manually do it yourself.

No.

Python: toCheck.startswith(prefix)

JavaScript: toCheck.startsWith(prefix)

Haskell: prefix `isPrefixOf` toCheck

What other languages does Go compete with that don't have a "string starts with" in their standard library.

Since I feel I've proven my point about all other languages Go competes with having this function, what other helpful functions do you think Go has that it's competitors do not?

Re: What Golang Is and Is Not

#214

Post by codygman »

randomdata wrote: post #141
RodgerTheGreat wrote: post #132

Earlier quoted context omitted.

His formulation of reduce() is strikingly clumsy, both in signature and implementation. I daresay I wouldn't have much use for such a function either! Most languages which provide a reduce() permit programmers to provide an initial "carry-in" value. This is a neater and more useful way to handle the cases of a zero- or one-element list. Moreover, it lets you do more interesting things with the reduction. Consider the…

To be fair, even with a well designed interface, it is difficult to see the advantage of your example over using a simple for loop: func unique(list []int) (r []int) { for i := range list { if !includes(r, i) { r = append(r, i) } } return }

Picture map, filter, and fold as for loops with annotations that restrict what they can do. This helps both the source code reader (you and I) and the source code compiler more easily understand what's going on.

For the compiler this makes optimization easier. For the reader it makes reading easier after learning what these recursion primitives do.

It is also less code, meaning less room for bugs.

Re: What Golang Is and Is Not

#215

Post by codygman »

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.

Methods in the standard library panicking if the method receiver is nil for one.

Re: What Golang Is and Is Not

#216

Post by gravypod »

reality_czech wrote: post #194
clappski wrote: post #137

Earlier quoted context omitted.

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.

Where are the 99 other ways? I see one way to do this for any set of data types. Golang is the one with 100 implementations.

Re: What Golang Is and Is Not

#217

Post by codygman »

seagreen wrote: post #118
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…

As someone who writes Go every day for work, I can't agree that Go is simple. You may be confusing "simple" with "good". A simple solution to a complex problem may not be a good one. Go can be simple and still not a great solution because it pushes complexity to a higher level.

Go handles simple problems well but copy pasting more "simplicity" as complexity scales results in a complex program.

Re: What Golang Is and Is Not

#218

Post by gravypod »

bpicolo wrote: post #161
twic wrote: post #150

Earlier quoted context omitted.

Or checking for the presence of an item in a slice. Because Go doesn't supply sets, or allow you to write them yourself, this is something i find myself needing to do a lot, and every time, i'm writing that idiotic function from scratch.

Dang, just like PHP (no built in set)

And yet there is a generic in array function.

Re: What Golang Is and Is Not

#219

Post by snaky »

codygman wrote: post #212
snaky wrote: post #108

Earlier quoted context omitted.

The only difference is a selection of basic types. There's just no such types as string or int in Perl, Perl is a contextually polymorphic language whose scalars can be strings, numbers, or references (which includes objects). Although strings and numbers are considered pretty much the same thing for nearly all purposes, references are strongly-typed, uncastable pointers with builtin reference-counting and destructor…

For me the compile time and runtime distinctions are more important.

Reflection you need to use, whether it be with interface{} in Go or with $scalar in Perl is runtime thing. reflect.TypeOf(tst), ref($tst) - there's no much difference.

Type mismatch errors for basic types are handled in compile time, be it Go or Perl.

Re: What Golang Is and Is Not

#220

Post by gravypod »

unsignedqword wrote: post #50

I'm not much of a Go programmer but I would definitely regard Go's multiple return and error handling (save the 'no assertions' clause) as very cool. I'm not sure if any other languages have experimented with that approach before the rise of Go, but to me at least it appears much saner than the prevalent ridiculousness of exception handling.

You can do it with JavaScript and Python, two other popular languages in the space.
Post reply on HN