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

201–210 of 279 posts

Re: What Golang Is and Is Not

#201

Post by snaky »

jacques_chester wrote: post #165
_ak wrote: post #159

Earlier quoted context omitted.

And where is Algol now? It's dead. Theoretical superiority on paper is worth absolutely nothing when there is no usable implementation for modern computing environments out there. This article was written to make Go look bad and unoriginal, but it inadvertently proves that Go is Algol's legitimate successor exactly _because_ it has all these features _and_ a working implementation that is available for wide variety o…

I think Pascal (and Modula and Oberon) are more legitimate successors to Algol. I wasn't aware that all of those working implementations had stopped working. Popularity is just one dimension a language can be placed on. Java utterly dominates the volume of new code being written in regular industry and has most likely done so for the entire lifetime of Go. And this says little about their other relative virtues.

I think it could easily be INTERCAL (and INTERCAL#, of course) dominating the world now, if Sun, IBM and other giants choose it instead of Java and pushed it with the same amount of force.

Re: What Golang Is and Is Not

#202

Post by catnaroek »

chrismonsanto wrote: post #199
catnaroek wrote: post #52

Earlier quoted context omitted.

> 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

First-class polymorphism is what System F gives you: functions from types to values.

Second-class polymorphism is what Damas-Milner gives you: let-bound identifiers may admit more than one type, in which case every type they admit is subsumed by a type schema.

Second-class polymorphism rules out polymorphic recursion if you consider every recursive definition as syntactic sugar for applying a fixed point combinator to some expression of type `a -> a`, for whatever monotype `a`.

Re: What Golang Is and Is Not

#203

Post by chrismonsanto »

catnaroek wrote: post #202
chrismonsanto wrote: post #199

Earlier quoted context omitted.

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

First-class polymorphism is what System F gives you: functions from types to values. Second-class polymorphism is what Damas-Milner gives you: let-bound identifiers may admit more than one type, in which case every type they admit is subsumed by a type schema. Second-class polymorphism rules out polymorphic recursion if you consider every recursive definition as syntactic sugar for applying a fixed point combinator t…

That's a new turn of the phrase for me. I've only ever heard the expression "second-class parametric polymorphism" used in reference to enforcing predicativity (which does not rule out polymorphic recursion)

Re: What Golang Is and Is Not

#204

Post by jbeja »

junke wrote: post #23

So, Go is designed to be an engineering language and not an academic toy. Contrary to other languages, Go programmers "deliver" and have a pragmatic view of the real development world, not just their own commits. Go programmers need a deeper understanding of computer science because other programmers are lazy and have everything given for free and probably don't need to know how it works. A whole page discussing the…

Why you have to be so mentally sick?

Re: What Golang Is and Is Not

#205

Post by catnaroek »

chrismonsanto wrote: post #203
catnaroek wrote: post #202

Earlier quoted context omitted.

First-class polymorphism is what System F gives you: functions from types to values. Second-class polymorphism is what Damas-Milner gives you: let-bound identifiers may admit more than one type, in which case every type they admit is subsumed by a type schema. Second-class polymorphism rules out polymorphic recursion if you consider every recursive definition as syntactic sugar for applying a fixed point combinator t…

That's a new turn of the phrase for me. I've only ever heard the expression "second-class parametric polymorphism" used in reference to enforcing predicativity (which does not rule out polymorphic recursion)

Ah, I might be wrong, then. Pretend I said “let” instead of “second-class”.

Re: What Golang Is and Is Not

#206

Post by catnaroek »

reality_czech wrote: post #200
catnaroek wrote: post #11

Earlier quoted context omitted.

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

> Have you ever actually tried to teach someone who doesn't know how to program?

Yes.

> It takes months, even when using a simple language like Python. Or even BASIC, which was designed specifically for beginners.

I never said anyone can learn everything there is to programming in a week. I only said anyone can learn the Standard ML language in a week. You might encounter far more difficult things along the way, but they shouldn't be related to Standard ML itself.

Re: What Golang Is and Is Not

#207

Post by snaky »

pjmlp wrote: post #168
remus wrote: post #149

Earlier quoted context omitted.

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

It is a small thing because there are other languages that offer the same safety with more features and lets face it, if a C coder is willing to embrace a GC enabled language there are lots to chose from, with AOT compilation to native code. I just expected more from Google, specially if one compares to the other company sponsored languages.

Comparing apples to apples, the first compiler sponsored by 'other company' was PHP, so Go looks not that bad in comparison. Reason is second, and maybe Google's second language would be 1ML.

Re: What Golang Is and Is Not

#208

Post by knucklesandwich »

karma_vaccum123 wrote: post #125
tinco wrote: post #57

Earlier quoted context omitted.

How is it dangerous? Your qualifying remarks with regards to Haskell's domain make no sense. If you need a fast, compiled language with managed memory, high ease of development and a strong ecosystem then you can't go wrong with Haskell. 'Type stable computation' and a strong correctness guarantee are some added benefits of Haskell, though any strongly typed language (like for example Rust) will have these qualities.…

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

FWIW, strictness may be introduced into haskell programs. Weak-head normal-form evaluation is builtin with the "seq" function and the "deepseq" library is commonly used for fully normal form evaluation of expressions.

GHC 8 also introduces the Strict and StrictData pragmas[1] which allow you to make a module (or its types) fully strictly evaluated.

[1]: https://ghc.haskell.org/trac/ghc/wiki/StrictPragma

Re: What Golang Is and Is Not

#209

Post by Ericson2314 »

groovy2shoes wrote: post #193
Ericson2314 wrote: post #72

Earlier quoted context omitted.

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…

And to think we then preach "disruption" to everyone else. It's just jawdropping.

Allow me to disrupt your null and Interface {}.

Re: What Golang Is and Is Not

#210

Post by kevhito »

anant wrote: post #196
patio11 wrote: post #192

Earlier quoted context omitted.

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 leas…

It's even worse. The longTimer has fired, and it sent a message on the channel just as it was supposed to. When Reset() is called, it causes a second firing and a second message. Here is the code, corrected to illustrate. The output times are exactly as one would expect.

https://play.golang.org/p/lntgH6tkiF

Post reply on HN