5 ms·

+1 regarding your additions to my list! With respect to compiling an SML-like language to Go (I've thought about this a lot), it would probably get you a long w

+1 regarding your additions to my list! With respect to compiling an SML-like language to Go (I've thought about this a lot), it would probably get you a long way, but the performance would suffer because FP langs allocate like crazy and Go's GC is not optimized for lots of fine-grained allocations. And there would still be a long tail of things that didn't work quite right: stack traces would need to be modified to map to lines in your source program (instead of the emitted Go code), documentation generation and linking would need to be patched, dependency fetching would need to understand and distinguish between packages in $MYLANG and Go packages (so it invokes the $MYLANG->Go compiler appropriately), and so on. That said, it would certainly be a great proof of concept!

vram22 8y ago
>Go's GC is not optimized for lots of fine-grained allocations Why is it not? Hadn't heard of this point before. Is it because of catering to the most common use cases, which are not fine-grained, maybe?
- weberc2 8y ago
  Go has value types and they're used pervasively. Where an OCaml or Python or Haskell list is O(n) allocations, a Go slice is 1 allocation (values are laid out side-by-side in memory). This allows Go to have a simple, concurrent GC with pause times on the order of 1us (compared to 10-100ms, as is common for compacting generational collectors) as well as great (CPU) cache properties (things are more likely to be collocated in memory, so you're more likely to have cache hits).
  - vram22 8y ago
    Got it, thanks. The Go team has been working on improving Go's performance, over time, I've read. One other such example I read about is that for compilation, where package A depends on B and B depends on C, the metadata for C is stored in the header of B, so when A is being compiled, it only needs to read B, not C - and there are other related optimizations on the compilation front, IIRC. I thought that was a good optimization. I wish the EXE/binary sizes of Go programs were smaller, though I know they've done some work on that too. Coming from a C background originally, I was a bit surprised when I first saw that the size of a simple hello-world-style Go binary was ~1 MB (some years ago). Equivalent Free Pascal and D binaries are a lot smaller, IIRC, from what I tested at the time (~100 KB or less). Heck, the Red interpreter / compiler (and the Rebol interpreter before it) fit in ~1 MB. Don't mean to denigrate the efforts of the Go team at all (even apart from the fact that as a long-time Unix guy, Rob Pike, Ken Thompson, et al are among the people I look up to); I know language translation technology is a hard field, plus the scope of Go may be much more than that of Rebol / Red; just speaking from the POV of a user, hoping for smaller binary sizes.
    - weberc2 8y ago
      > Got it, thanks. The Go team has been working on improving Go's performance, over time, I've read. One other such example I read about is that for compilation, where package A depends on B and B depends on C, the metadata for C is stored in the header of B, so when A is being compiled, it only needs to read B, not C - and there are other related optimizations on the compilation front, IIRC. I thought that was a good optimization. AFAICT that's a compiler optimization, not a runtime optimization. But yes, generally the Go team is working to improve performance. > I wish the EXE/binary sizes of Go programs were smaller, though I know they've done some work on that too. Coming from a C background originally, I was a bit surprised when I first saw that the size of a simple hello-world-style Go binary was ~1 MB (some years ago). Equivalent Free Pascal and D binaries are a lot smaller, IIRC, from what I tested at the time (~100 KB or less). Heck, the Red interpreter / compiler (and the Rebol interpreter before it) fit in ~1 MB. Don't mean to denigrate the efforts of the Go team at all (even apart from the fact that as a long-time Unix guy, Rob Pike, Ken Thompson, et al are among the people I look up to); I know language translation technology is a hard field, plus the scope of Go may be much more than that of Rebol / Red; just speaking from the POV of a user, hoping for smaller binary sizes. Go binaries contain _everything_, while C programs (usually) statically link against libc (glibc is on the order of 10mb by itself). Go's runtime is also quite a lot more complex than C's--it comes with a scheduler, a reflection system, and a garbage collector. These are one-time costs--the binary for a program 10 times the size of hello world is pretty much the same size as the hello world binary. If you really want, you can dynamically link a Go program, but I can't imagine a scenario where this is practical.
      - vram22 8y ago
        >AFAICT that's a compiler optimization, not a runtime optimization. But yes, generally the Go team is working to improve performance. Right, it is a compile time one. >Go binaries contain _everything_, while C programs (usually) statically link against libc (glibc is on the order of 10mb by itself). Did you mean "dynamically" (for C) [1]? Also, I'm not too sure if Go links all dependencies statically by default, if that is what you implied above. IIRC I read somewhere recently that some things are linked statically, and some dynamically - I need to check that. [1] I need to check it for C too, because things have changed since I last used C a lot. >Go's runtime is also quite a lot more complex than C's--it comes with a scheduler, a reflection system, and a garbage collector. These are one-time costs--the binary for a program 10 times the size of hello world is pretty much the same size as the hello world binary. Agreed on the points about the other stuff Go has that C does not, like a GC, reflection, etc. And that those are one-time costs. But they are still costs, and if you create lots of small binaries, that cost adds up. Disk space is cheap nowadays, but depending on the use case and your environment (e.g. small or embedded system, cost constraints if shipping many copies of a h/w + s/w product or appliance, etc., that cost might be significant. Whereas with some of those other languages that I mentioned above, those costs can be quite a bit less, times the number of copies of binary or appliance that you ship. That's all that I meant. That's not to say that we should not use Go, though, of course. As always, the overall picture and all factors need to be taken into account, e.g. the benefits of Go's language features vs. some of those others, team knowledge of the various language contenders, even availability of needed libraries, time to market, etc. etc.
  - pjmlp 8y ago
    Haskell can do value types allocations, not everything is a list.
    - weberc2 8y ago
      Unless 90% of Haskell allocations are value types on the stack, this is irrelevant pedantry.
      - pjmlp 8y ago
        Do not optimize what isn't proven by an optimizer. The features are there, 90% of the cases it doesn't matter for the typical use cases. When it does matter, they are in reach to any savy Haskell developer.

vram22 8y ago

>Go's GC is not optimized for lots of fine-grained allocations Why is it not? Hadn't heard of this point before. Is it because of catering to the most common use cases, which are not fine-grained, maybe?

weberc2 8y ago
Go has value types and they're used pervasively. Where an OCaml or Python or Haskell list is O(n) allocations, a Go slice is 1 allocation (values are laid out side-by-side in memory). This allows Go to have a simple, concurrent GC with pause times on the order of 1us (compared to 10-100ms, as is common for compacting generational collectors) as well as great (CPU) cache properties (things are more likely to be collocated in memory, so you're more likely to have cache hits).
- vram22 8y ago
  Got it, thanks. The Go team has been working on improving Go's performance, over time, I've read. One other such example I read about is that for compilation, where package A depends on B and B depends on C, the metadata for C is stored in the header of B, so when A is being compiled, it only needs to read B, not C - and there are other related optimizations on the compilation front, IIRC. I thought that was a good optimization. I wish the EXE/binary sizes of Go programs were smaller, though I know they've done some work on that too. Coming from a C background originally, I was a bit surprised when I first saw that the size of a simple hello-world-style Go binary was ~1 MB (some years ago). Equivalent Free Pascal and D binaries are a lot smaller, IIRC, from what I tested at the time (~100 KB or less). Heck, the Red interpreter / compiler (and the Rebol interpreter before it) fit in ~1 MB. Don't mean to denigrate the efforts of the Go team at all (even apart from the fact that as a long-time Unix guy, Rob Pike, Ken Thompson, et al are among the people I look up to); I know language translation technology is a hard field, plus the scope of Go may be much more than that of Rebol / Red; just speaking from the POV of a user, hoping for smaller binary sizes.
  - weberc2 8y ago
    > Got it, thanks. The Go team has been working on improving Go's performance, over time, I've read. One other such example I read about is that for compilation, where package A depends on B and B depends on C, the metadata for C is stored in the header of B, so when A is being compiled, it only needs to read B, not C - and there are other related optimizations on the compilation front, IIRC. I thought that was a good optimization. AFAICT that's a compiler optimization, not a runtime optimization. But yes, generally the Go team is working to improve performance. > I wish the EXE/binary sizes of Go programs were smaller, though I know they've done some work on that too. Coming from a C background originally, I was a bit surprised when I first saw that the size of a simple hello-world-style Go binary was ~1 MB (some years ago). Equivalent Free Pascal and D binaries are a lot smaller, IIRC, from what I tested at the time (~100 KB or less). Heck, the Red interpreter / compiler (and the Rebol interpreter before it) fit in ~1 MB. Don't mean to denigrate the efforts of the Go team at all (even apart from the fact that as a long-time Unix guy, Rob Pike, Ken Thompson, et al are among the people I look up to); I know language translation technology is a hard field, plus the scope of Go may be much more than that of Rebol / Red; just speaking from the POV of a user, hoping for smaller binary sizes. Go binaries contain _everything_, while C programs (usually) statically link against libc (glibc is on the order of 10mb by itself). Go's runtime is also quite a lot more complex than C's--it comes with a scheduler, a reflection system, and a garbage collector. These are one-time costs--the binary for a program 10 times the size of hello world is pretty much the same size as the hello world binary. If you really want, you can dynamically link a Go program, but I can't imagine a scenario where this is practical.
    - vram22 8y ago
      >AFAICT that's a compiler optimization, not a runtime optimization. But yes, generally the Go team is working to improve performance. Right, it is a compile time one. >Go binaries contain _everything_, while C programs (usually) statically link against libc (glibc is on the order of 10mb by itself). Did you mean "dynamically" (for C) [1]? Also, I'm not too sure if Go links all dependencies statically by default, if that is what you implied above. IIRC I read somewhere recently that some things are linked statically, and some dynamically - I need to check that. [1] I need to check it for C too, because things have changed since I last used C a lot. >Go's runtime is also quite a lot more complex than C's--it comes with a scheduler, a reflection system, and a garbage collector. These are one-time costs--the binary for a program 10 times the size of hello world is pretty much the same size as the hello world binary. Agreed on the points about the other stuff Go has that C does not, like a GC, reflection, etc. And that those are one-time costs. But they are still costs, and if you create lots of small binaries, that cost adds up. Disk space is cheap nowadays, but depending on the use case and your environment (e.g. small or embedded system, cost constraints if shipping many copies of a h/w + s/w product or appliance, etc., that cost might be significant. Whereas with some of those other languages that I mentioned above, those costs can be quite a bit less, times the number of copies of binary or appliance that you ship. That's all that I meant. That's not to say that we should not use Go, though, of course. As always, the overall picture and all factors need to be taken into account, e.g. the benefits of Go's language features vs. some of those others, team knowledge of the various language contenders, even availability of needed libraries, time to market, etc. etc.
- pjmlp 8y ago
  Haskell can do value types allocations, not everything is a list.
  - weberc2 8y ago
    Unless 90% of Haskell allocations are value types on the stack, this is irrelevant pedantry.
    - pjmlp 8y ago
      Do not optimize what isn't proven by an optimizer. The features are there, 90% of the cases it doesn't matter for the typical use cases. When it does matter, they are in reach to any savy Haskell developer.