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

Go Rocks - How Can We Avoid Something This Bad In The Future?

acooke.org

Post reply on HN
Print view View original

31–40 of 68 posts

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#31

Post by singular »

God what an annoying troll.

It's a very new language, and things are being improved + fixed all the time, I would be very surprised indeed if tail-call optimisation + the ever so vital self-recursive lambda issue weren't fixed at a later date. To treat these things as permanently a part of the language is disingenuous at best.

Rob Pike (part of the core team) has said that what puts a lot of PL people off is that it is not theoretically exciting, it's just designed to be very useful [1].

The funny thing about go is that it seems like an uninteresting language when you first begin, but as you write more code you begin to appreciate its simplicity and orthogonality and realise that these are extremely nice qualities.

Language design is as much about saying no to things as it is to saying yes to things.

On a related note, I don't like the implication that there is now a scientific method to language design which obviates the need for practical considerations - that strikes me as class A ivory tower bullshit.

[1]:http://www.youtube.com/watch?v=-i0hat7pdpk&feature=playe...

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#32

Post by enneff »

rdtsc wrote: post #21
dlsspy wrote: post #4

I wrote a bunch of go code this morning. It's definitely got a few really neat ideas in it. I tend to write erlang or c++ mostly for my day job. I do really wish the designers had a bit more erlang experience. Just a touch. Just enough so that I had a way to propagate the death of a goroutine through a bunch of other goroutines without building all of that manually. For example, code I wrote today: http://pastebin.co…

> I do really wish the designers had a bit more erlang experience. I feel the same way. I had this hope that this would be what I would learn instead of Erlang. You know it has goroutines and channels -- kind of like processes and casts. Well except that it is not the same. Erlang's processes that have explicit pids and messages are cast to those processes by referring to their pid, make a lot more sense to me than a…

Go is something quite different to Erlang, despite some small similarities. If you want Erlang, just use Erlang.

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#33

Post by enneff »

dlsspy wrote: post #19
enneff wrote: post #7

Earlier quoted context omitted.

If you modify your for loop to range over ch, you can make the sending side close(ch) when an error occurs, and then the loop will end and the receiver can shut itself down. http://pastebin.com/FMSLvFCn

Wow, that's not intuitive. :) Throwing in a "defer close(ch)" and that range thing did exactly the right thing. I'm not sure my API is right, but I know how to get it right now. Thanks a lot.

I'm surprised you say it's not intuitive. What is it just that you didn't know you could close channels?

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#34

Post by kraemate »

singular wrote: post #31

God what an annoying troll. It's a very new language, and things are being improved + fixed all the time, I would be very surprised indeed if tail-call optimisation + the ever so vital self-recursive lambda issue weren't fixed at a later date. To treat these things as permanently a part of the language is disingenuous at best. Rob Pike (part of the core team) has said that what puts a lot of PL people off is that it…

I wonder what the author means by programming language "academic research". None of the mentioned deficiencies of Go (anon lambdas/TCO) is the product of any new academic research and have been around for a very long time (see Lisp).

Most PL academic research goes into Haskell/ML , and we know how useful they really are. (Monads/Type inferencing , anyone?)

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#36

Post by pavpanchekha »

xorglorb wrote: post #30
billmcneale wrote: post #14

I think Go is a pretty mediocre language overall, one that would have been a killer early 2000, but this article basically boils down to: "Go sucks because it doesn't support tail call optimization and continuations". Way to miss the boat.

I don't mind those as much, but what really kills it for me is the lack of separation between the language and the standard library.

Wait, is there supposed to be such a separation? Python's standard library is half the reason people use Python. Do I consider the MatLab matrix multiplication routine the library or the language? Because the abstract syntax and semantics of MatLab could certainly do without it. What about ODE solving? I wouldn't use MatLab without it. Is Lisp's (defun) library or language? In my own pylisp, I put (def) in the standard library. But you'll see little code that doesn't use it.

What about Haskell? Is Prelude library or language? Every Haskell file has it preloaded, so you can't code without it (without effort, anyway); but it can certainly be implemented in Haskell itself. Is Haskell the language just typed lambda calculus with type classes and some basic syntax sugar? Is IO Haskell language or library?

What about C's varargs? Is it language or library? It seems like library, since you include a header file to use it. But it's also impossible to do variable-lenght argument lists in C without it. What about longjmp? What about sbrk? It seems like library, since different OSs do it differently, and thus it has multiple implementations, in C. But without it, you can't do heap allocated memory, which is something you can't do without it.

Separation between language and standard library? What language does do it?

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#37

Post by gnuvince »

fauigerzigerk wrote: post #18

I don't think Go's creators are as ignorant of academic ideas as you say. I've seen Rob Pike refer to OCaml a lot for instance. They just don't seem to like many of those ideas.

I cannot recall him ever saying the word "OCaml".

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#38

Post by DanWaterworth »

Peaker wrote: post #29
flogic wrote: post #24

Earlier quoted context omitted.

I wouldn't call either Haskell or Scala academic. However, here a quick shoot from the hip stereotyping of each. Scala gives me the impression it wants to be Java's C++. C++ is largely an extension of C. Sure you can use it entirely differently than C, but that C-ish core is still there. And Scala gives me that same feeling in relation to Java. On the other hand, Haskell suffers from being a "pure" language. I mean "…

I think Haskell accommodates imperative programming so well that it surpasses many imperative languages and beats them in their own game. I also think the name "purity" is misleading. In the context of Haskell it means: * Referential Transparency: references to things are indistinguishable from those things. This helps a lot with equational reasoning about code, optimizations and all sorts of mechanical refactorings.…

I completely agree, in fact I've been trying to show people how well Haskell can encode imperative programs.

See https://github.com/DanielWaterworth/Musings/blob/master/why_... and https://github.com/DanielWaterworth/Musings/blob/master/comp...

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#39

Post by __rkaup__ »

drivebyacct2 wrote: post #15

I know that this is the wrong mentality, but I want to become an expert in a language that is as good as it can be. Can Go evolve to address some of these issues? Would it even be go anymore? I tried Googling, but why are Scala and Haskell automatically classified as "academic"? Is there value in learning them purely for that reason? I walked through some Haskell tutorials after reading this, but I'm rather stare at…

It came from inside a bunch of universities, and it's not hard to find papers talking about things like "monads" or "arrows" mentioning things like "monoids", which are mainly Haskell things. (But monoids aren't really Haskell things.)

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#40

Post by to3m »

pavpanchekha wrote: post #36
xorglorb wrote: post #30

Earlier quoted context omitted.

I don't mind those as much, but what really kills it for me is the lack of separation between the language and the standard library.

Wait, is there supposed to be such a separation? Python's standard library is half the reason people use Python. Do I consider the MatLab matrix multiplication routine the library or the language? Because the abstract syntax and semantics of MatLab could certainly do without it. What about ODE solving? I wouldn't use MatLab without it. Is Lisp's (defun) library or language? In my own pylisp, I put (def) in the standa…

C is actually one of the few languages that gets the language/library separation mostly right. You can write pretty much the entire standard library in C, and you can easily write C without the standard library. It's very straightforward (if sometimes a bit annoying) to do this in Windows, and I believe neither EPOC/Symbian or PalmOS supported the ISO C library.

varargs, setjmp/longjmp and sbrk are 100% library. You can do varargs without stdarg.h; if you know the calling convention, you can just walk through the memory occupied by the arguments. setjmp is trickier but if you know the rules you could write it using assembly language, just like the library writers did. As for sbrk, I'm not terribly familiar with that I do admit, but judging by the man page it is not part of the C standard library, kind of proving my point. But you can definitely have a heap, and allocate out of it, and (where plausible) grab more address space, without having it.

Post reply on HN