For some reason I can't scroll this page on the iPad.
Use two fingers. It's still a pain, but you can read it.
Go Rocks - How Can We Avoid Something This Bad In The Future?
41–50 of 68 posts
Re: Go Rocks - How Can We Avoid Something This Bad In The Future?
#42I've played very little with GO, and it seems to be a nice language overall.
Anyway, it's designed to allow easy parallelism. It's a system's language for parallel work.
The only thing that I don't like about it is that the built-in types get special treatment (if you want to write a map yourself, you can't use the same syntax). This indeed feels like a design smell.
GO is still very useful this way, but I do hope that it gets generics/templates sometime in the future.
Re: Go Rocks - How Can We Avoid Something This Bad In The Future?
#43He lost me when he said "to understand that, you need to understand the academics".
There is a pretty sizable disconnect between what's going on in academic computer science today and what professional software engineers are looking for. Go explicitly sets out to solve practical problems, not provide an implementation of this year's trendiest compiler porn.
Re: Go Rocks - How Can We Avoid Something This Bad In The Future?
#44No syntactically lightweight way of writing anonymous recursive functions? I can't make myself care about that; I just spent 30 seconds trying, and failed. That's just not a use case worth optimizing for in a practical systems language. Also, it's true that the Go spec doesn't guarantee tail calls are optimized. If Go were designed to be a functional language, that'd be problematic. However, guaranteeing TCO isn't fr…
I think you and a lot of other people got too caught up in the cognitively-well-trodden ground about how a language doesn't support anonymous functions and TCO very well, but missed some of the other less common arguments that I think are at least as important. The complaint about the compiler and runtime having too much magic access is very valid. I've come to see this as a major design flaw in any language, especially given how easy it is (relatively speaking) to give programs access to the magic interfaces instead of locking them away. Python is the best example of this, there is now almost no statement in the language that there isn't an official way to extend with some double-underscore protocol or other. It always causes problems when the language has some magical layer of access that automatically does something for you, because it eventually turns out to be the wrong automatic thing. It's only a matter of time.
And there isn't anything about that complaint that is the slightest bit "academic". If anything, the academics are far more into the idea that they can come up with the One Correct Behavior and write it straight into the underlying specification of the language than the practical languages are. (One of my personal criticisms with Haskell right now is that while this is slowly being fixed, it's being fixed in a haphazard, one-off for each syntax element manner, instead of seeing the underlying problem and addressing it in a unified manner, and I think that this is because, like I said, academics don't really think this way.) In my book, it's simply a mistake.
I think it's a grave mistake to collapse this criticism of Go to "It's not academic enough"; my sense of the problem is actually that it's more on the practical side. There are some clear practical wins that really ought to be well known by anybody doing PL design that seem to have been passed up. Hopefully these are corrected, but it dampens my enthusiasm somewhat that they were missed in the first place. YMWV.
Re: Go Rocks - How Can We Avoid Something This Bad In The Future?
#45Earlier quoted context omitted.
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…
Varargs for the X86_64 is most definitely baked into the compiler, and impossible to do library only.
Re: Go Rocks - How Can We Avoid Something This Bad In The Future?
#46No syntactically lightweight way of writing anonymous recursive functions? I can't make myself care about that; I just spent 30 seconds trying, and failed. That's just not a use case worth optimizing for in a practical systems language. Also, it's true that the Go spec doesn't guarantee tail calls are optimized. If Go were designed to be a functional language, that'd be problematic. However, guaranteeing TCO isn't fr…
I'm a full time OCaml dev these days and I run into OCaml's 'lack of lightweight anonymous recursive functions' maybe three times a year. It costs 3 lines of code to declare the function (called loop() or whatever) and then call it. I've never realized I was supposed to want to switch languages because of it. Otherwise, this comment makes me more interested in Go than I have been before. OCaml has a bazillion feature…
what about pattern matching? that is imo one of the saddest omissions from go - it's not a "huge" feature like continuations, but i find it makes a language significantly more pleasant to work with.
Re: Go Rocks - How Can We Avoid Something This Bad In The Future?
#47He lost me when he said "to understand that, you need to understand the academics". There is a pretty sizable disconnect between what's going on in academic computer science today and what professional software engineers are looking for. Go explicitly sets out to solve practical problems, not provide an implementation of this year's trendiest compiler porn.
[deleted]
Re: Go Rocks - How Can We Avoid Something This Bad In The Future?
#48Earlier quoted context omitted.
I guess it is something like the Valley of The Uncanny for languages. Yes, it looks deceivingly similar to C++, C & Java, but is not any of those. When your eyes see the syntax, your brain expects the functionality to be the same. However Go does introduce fairly radical new paradigms (goroutines, type inference...) that really upsets that initial feeling of familiarity. I (unlike the majority) like Erlang's complete…
I agree except for the whole ";" "," "." line endings issue. When I can't copy and paste to move lines around without "fiddling" with the line endings, I get angry.
[deleted]
Re: Go Rocks - How Can We Avoid Something This Bad In The Future?
#49I work on Rust, which is in a similar space to Go. IMHO this article is oversimplifying. (1) Recursive anonymous functions: This is the first time I've heard this criticism. MLs usually don't have this functionality either. It's not too much trouble to give the function a name. (2) Tail call optimization: TCO isn't free. It requires all callees to pop their arguments, which slightly penalizes every call in the progra…
Can you elaborate on how popping arguments penalizes every call? It seems like, for non-variadic calls at least, it should take the same amount of time to add a constant to %esp whether you're doing it in the RET instruction or in the caller; but factoring that code into the callee should improve code density and therefore icache hit rates. What am I missing?
Re: Go Rocks - How Can We Avoid Something This Bad In The Future?
#50Earlier quoted context omitted.
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…
I agree with your broad point that you can write a usable C library with a very minimal amount of assembly, but I am going to quibble on some of the details.
> You can write pretty much the entire standard library in C, ... varargs, setjmp/longjmp and sbrk are 100% library.
If you're saying "These four functions can be written in C" then you are mistaken. If you are saying "These four functions can be written in assembly" then you are not saying anything interesting about C, because it is true of any language that it is possible to write its library in assembly if it's possible to write it at all.
In more detail.
Whether you can write va_arg in C depends on the platform's calling convention. On most platforms you can (because the default calling convention has to support varargs, and the easiest way to do that is to push the arguments on the stack) but on x86-64 you can't.
setjmp and longjmp cannot be written in C on any platform I'm familiar with, unless you're writing them on top of something like setcontext, which has a slight superset of their functionality. They are, however, very simple to write in assembly.
You can write sbrk in one line of C, and the glibc implementation is only ten: http://koala.cs.pub.ro/lxr/glibc/misc/sbrk.c#L29 But sbrk is simply a convenience wrapper around brk, which is necessarily a system call. And C doesn't have a "system call" statement.
(Actually, you can write brk in C too if you just want to allocate out of some fixed blob of address space, which is a reasonable choice on, say, a microcontroller.)