1. 2

    So much wailing, so little code

    1. 2

      But we want r7.rs! :)

      1. 3

        It is so true.

        “The real danger is not that computers will begin to think like men, but that men will begin to think like computers.”

        1. 8

          I’ll go ahead and say that this is usually a Bad Idea. While the CGO interface isn’t difficult to use, it does make it much more difficult to deploy your Go program, as cross compilation becomes much more difficult. I’d suggest that you only drop into C if you really need to.

          1. 2

            Is there even a way to do cross compilation with CGO? The last time I tried, CGO is turned off when you try to cross compile because the path to the C compiler is hard-coded in for some reason.

            1. 3

              This is scheduled to be fixed for GO 1.3, assuming it can be made reliable enough in time.

              http://code.google.com/p/go/issues/detail?id=4714

              1. 1

                There are ways, but it’s not pretty.

              2. 1

                I just skimmed the article but I didn’t see where he tried to optimize or analyze the Go program to see where those 3 pesky microseconds went missing. As you mentioned, the extra overhead of builds and deployment are often not worth it… especially not for 3 microseconds.

                1. -3

                  There must be a very time-critical problem to rewrite it’s solution from Go to C.

                1. 1

                  The main “bad thing” about OCaml is it’s tremendously and strangely unhandy cross-platformness. The big surprise for me was the extreme clumsiness of Windows port (and the whole language looks a little clumsy in some parts, but it’s not so bad).

                  The post is just another one “static vs dynamic” review. It is not quite right to compare OCaml and Python, each language has it’s own field and all of these “high gains” may be just a result of choosing an inappropriate tool for the first time.

                  1. 3

                    IMO, the Ocaml language has some weird cases, but in total it’s one of the better designed languages as a whole. It’s small, fairly consistent, and adopts useful ideas.

                    I think you might be missing the overall point of the post. My interpretation is that the point is that the two languages are comparable. They have roughly the same niche, and this is a list of what you gain when you use Ocaml to solve your problem where you could use Python.

                  1. 3

                    You can take a look at Plan 9/Inferno coding guidelines and internals. That’s something looking very close to Go. There is some good things in C11 as well.

                    1. 2

                      It looks good and promising but why does someone ever need this? I think that Dylan and Common Lisp communities consists of slightly different people with slightly different problems.

                      1. 1

                        I just want to see it on Plan 9.

                        Also, as for me “translating” the internals of Go compiler from C to Go, especially using an automated translator, is not the best decision. This code will be just a pile of human-non-readable strings and can serve only as a very termporary solution.

                        I like the way Go changes. It’s not the “revolutionary”-flavoured development of languages such as Rust, but the soft evolution.

                        1. 1

                          I like the way Go changes.

                          I like it too. I especially like Go being focused on solving very concrete problems in software development, and making programming productive and pleasant, instead of trying to be a breakthrough research project in language theory.

                          It’s not the “revolutionary”-flavoured development of languages such as Rust, but the soft evolution.

                          Yes and no. I’d say that some aspects are quite “revolutionary” (like the use of interfaces and structural typing instead of classes and inheritance, the builtin goroutines, the rejection of exceptions, the almost mandatory use of gofmt to avoid bikeshedding, the approach to dependency management, the use of defer, the explicit rejection of keyword arguments, etc.) and some are very conventional (one unique heap shared by all goroutines, garbage collection, mutable variables, etc.).