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

141–150 of 279 posts

Re: What Golang Is and Is Not

#141

Post by randomdata »

RodgerTheGreat wrote: post #132
thatswrong0 wrote: post #44

Earlier quoted context omitted.

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

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
     }

Re: What Golang Is and Is Not

#142

Post by easuter »

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…

Oh wow, string prefix checking is the example you want to run with? In C#:

  toCheck.StartsWith(prefix)
Meanwhile in Golandia, this is still an issue:

https://github.com/golang/go/issues/16721#issuecomment-24015...

...and I haven't felt this kind of pinch when using C#, ever. But what do I know? I'm just a .NET wage-slave pleb who's too mentally handicapped to see Go's glory.

Re: What Golang Is and Is Not

#143

Post by mixedCase »

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…

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

I've seen this meme being spouted so much every time Go's mentioned it's ridiculous.

No, piling up feature upon feature is not progress otherwise we wouldn't be using anything but C++.

Go is a language you pick for the right situation. If it's not enough for what you're trying to do, go for a different one instead of trying to expand in the wrong direction leaving you with warts, like Java's done, C++'s done, Python, JavaScript etc... which you will have to end up avoiding in order to write performant and clear code, counting on luck not to have to deal with code that abuses those features to create anti-pattern upon anti-pattern.

Re: What Golang Is and Is Not

#144

Post by drvdevd »

snaky wrote: post #71
skybrian wrote: post #59

Earlier quoted context omitted.

Having tried to use Go for analytics, I agree that it's not a good fit for that use case. (It does work well for scripts and simple servers, though.)

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.

Re: What Golang Is and Is Not

#145

Post by Terribledactyl »

tinco wrote: post #131
karma_vaccum123 wrote: post #125

Earlier quoted context omitted.

Haskell's runtime has one overriding attribute: laziness. If laziness is not desirable in your domain, Haskell is not a useful option

Can you give me an example of a domain where laziness is not desirable? I only do Haskell for side projects, so perhaps I lack exposure to some domains.

Laziness can make it hard or counterintuitive to determine the runtime properties of your program, especially with regards to memory. Same with real-time systems. But you can turn it off, or force evaluation if needed.

Re: What Golang Is and Is Not

#146

Post by sheepmullet »

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…

The grass is always greener....

> easy to hire for

There are 100x as many experienced C# enterprise developers. And that is being conservative.

Re: What Golang Is and Is Not

#147

Post by bpicolo »

> Finally, in certain problem domains the power and flexibility of a hash-map is also unavoidable, therefore Go provides a Map built in

Not a fan of this sentence. Why try to make it sound like Maps are unusual or bad? Just as fundamental as the list to real programming.

Re: What Golang Is and Is Not

#148

Post by RodgerTheGreat »

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 }

It was just the first example that came to mind to illustrate the general pattern. We could also make this particular example shorter by using your naming conventions and writing it in a more functional manner instead of mutating the list:

    function unique(list) {
        return list.reduce((r, i) => r.includes(i) ? r : r.concat(i), []);
    }
Clearer? I dunno; probably depends on the reader's background and preferences.

Re: What Golang Is and Is Not

#149

Post by remus »

pjmlp wrote: post #8
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.

Not only C++, there are plenty of options. The only thing good about Go, is being an evolution path for C coders willing to embrace a GC and some type safety.

>The only thing good about Go, is being an evolution path for C coders willing to embrace a GC and some type safety.

You say that like it's a small thing, but what proportion of bugs in C code does that cover? Im guessing you'd hit over 50%.

Re: What Golang Is and Is Not

#150

Post by twic »

pcwalton wrote: post #139
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…

> 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. Sorting a slice is a pretty obvious counterexample.

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.
Post reply on HN