11 ms·

Creator of SASS and Haml now using Go for whole production system. When asked about surprising things about Go, its creators have said that they expected to re

Creator of SASS and Haml now using Go for whole production system. When asked about surprising things about Go, its creators have said that they expected to recruit people from c++ communities, instead it seems to be more ruby/python people.

cageface 14y ago
In hindsight it doesn't seem so surprising. Go really isn't a good alternative to C++ for the kinds of things that really need the low-level control and direct memory access C++ provides. And if you don't really need those things you probably should have moved on to Java or Ruby/Python/etc already. And since a lot of Java shops are fantastically risk averse I'm not at all surprised that the same kind of people that were willing to take a risk on Python or Ruby are now into Go. It offers a lot of the expressiveness of either of the former with much better performance, concurrency as a fundamental, and the extra safety of static type checking.
- thebigshane 14y ago
  Straight from Rob Pike -- http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com/2012/06/less-is-exponentia... Python and Ruby programmers come to Go because they don't have to surrender much expressiveness, but gain performance and get to play with concurrency. C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn't just about getting the job done, it's about doing it a certain way. The issue, then, is that Go's success would contradict their world view. And we should have realized that from the beginning. People who are excited about C++11's new features are not going to care about a language that has so much less. Even if, in the end, it offers so much more.
  - mturmon 14y ago
    Nice link. The separate submission and thread is here: http://news.ycombinator.com/item?id=4158865 http://news.ycombinator.com/item?id=4158865
  - batista 14y ago
    >The issue, then, is that Go's success would contradict their world view. I call BS. The parent explanation is much better: for a lot of the kinds of jobs C++ is good for, Go is not that good, whereas for a lot of things Python is good for, Go is as good and has better performance.
    - qznc 14y ago
      C++ is better for abstraction, as Go does not have generics yet, and C++ is better for performance. Go is faster to compile. Maybe Go is better for concurrent programming, but this is hard to measure.
      - tptacek 14y ago
        One look at the Go standard library contradicts this. Go is perfectly adequate for abstraction.
        kragen 14y ago
        I think you may be talking past each other. C++ or D templates allow you to express (in a crude, verbose, error-prone way) some kinds of abstractions that are not expressible in Golang or ML. Not sure about C#. There are certainly lots of abstractions you can express in Golang.
      - draven 14y ago
        Go has interfaces, which can be used to write generic code. Go performance is not on par with optimized C++ but for me it's fast enough and the performance / dev_time ratio is higher.
        qznc 14y ago
        http://golang.org/pkg/container/list/ http://golang.org/pkg/container/list/ Casting every list element to "interface{}" is not generic.
        14y ago
  - tjoff 14y ago
    I have such a hard time believing how anyone could have believed that C/C++ programmers would switch to a GC-only language just like that. I just can't see Go as an alternative to C or C++, and I'm quite surprised that anyone (especially someone such as Rob Pike) could. Sure there are situations where a program that typically would have been written in C/C++ could benefit from Go (so there is a place for it), but the reasons for choosing C/C++ are often the same that makes Go a really bad fit. My dreams of a C-like language where the dangerous parts have been removed (and in this context I don't consider having control of your memory dangerous) took a hit with the introduction of Go :(
    - eckyptang 14y ago
      I think C/C++ programmers have had their reign long enough and have shown us through the amount of utterly horrible security issues that managing memory yourself is a bad idea. Go fits an important niche: stuff that doesn't have to play with the hardware directly, which is pretty much everything but the OS. I controversially consider there to be no other use for C bsaed languages these days other than at the kernel level. It's better to centralise the memory management and optimisation either into a VM or compiler. It's easier and safer to verify a compiler (mathematically or otherwise) than every memory access that you do. Due to my engineering background, I would always sacrifice performance for less risk and more reliability. I've also spent 20 years writing C and C++ so I know how horrible it is.
      - tjoff 14y ago
        Go fits an important niche: stuff that doesn't have to play with the hardware directly, which is pretty much everything but the OS. The anything-but-the-OS-niche? I thought we had plenty of languages for that. It's better to centralise the memory management and optimisation either into a VM or compiler. It's easier and safer to verify a compiler (mathematically or otherwise) than every memory access that you do. You seem to ignore performance altogether, if you programmed in C/C++ for twenty years but don't care for performance and don't do low-level work, why have you been using C/C++? Or if you have been doing low level or performance critical work, why wouldn't you want a safer alternative for that? When you have to tune and debug your application to please the garbage collector having to deal with your own memory seems like child's play. It is much easier and safer to verify that your own memory management won't bite you than it is to be sure that your garbage collector won't eat you. (surely that depends on the context etc. but making broad claims seems to be on topic...) Right tool for the right job. C/C++ has "monopoly" on a lot of use cases (way more than any other language) and considering its issues I truly believe that a "better C/C++" is needed, way more than those 20 JVM-based languages that popup every other month. Or Go.
- oofabz 14y ago
  I write Go and I have been satisfied with the low-level control and direct memory access. The language has pointers and you can cast between ints and pointers, so you can do anything you can do in C. If you're writing realtime code, you can avoid triggering the garbage collector simply by not allocating memory on the heap. It is harder to get anything done this way, but writing realtime code in any language is difficult.
  - cageface 14y ago
    I actually haven't gotten this far with Go myself so I'm glad to hear that it's possible. But there's a huge uphill battle ahead for Go here. For instance, I write C++ code because I'm doing music software and all the APIs and existing code libraries and samples are in C++. It's just so much easier in this environment to put up with C++'s warts than it would be to try to shoehorn Go in there. As John Carmack says, externalities can quickly overwhelm the advantages of any particular language. But if you're implementing web services from scratch you don't have any of that baggage to carry around so it's much easier to choose Go.
    - Evbn 14y ago
      Swig can help there?
      - cageface 14y ago
        For my particular application it's not even close to worth it, but in some cases I can imagine it might be worth the hassle.
      - akavel 14y ago
        or cgo? http://golang.org/cmd/cgo/ http://golang.org/cmd/cgo/
  - aaronblohowiak 14y ago
    >you can do anything you can do in C This is true only for very limited meanings of "anything"; if your point was that you had direct control of memory layout and you can use CGO for those things that C offers but go does not. For instance, the volatile keyword..
- StavrosK 14y ago
  > In hindsight it doesn't seem so surprising. Most things don't seem surprising in hindsight. That's why you don't judge surprises by it. If C++ programmers did flock to Go, would you then say that that was surprising? If not, you've just fallen victim to hindsight bias (because a model that predicts everything is useless).
  - cageface 14y ago
    Most things don't seem surprising in hindsight. That's why you don't judge surprises by it. Surprising was GP's original term, not mine. I don't expect Go or any other language to displace C++ any time soon. But I do think the "scripting" languages are very vulnerable to challenges from languages with static typing systems less primitive than Java's.
    - StavrosK 14y ago
      That's because the GP was surprised. I rather should have said, you don't judge that something wasn't surprising by hindsight. Hindsight makes things obvious.
Lewisham 14y ago
I think a lot of it is that people sort of did want some static type checking, but were not willing to give up on things like garbage collection or some of the other niceties that the dynamic languages provided. As someone who has been clamoring for a statically-checked Python-esque language, Go looks awesome.
- deleted 14y ago
  [deleted]
jonathansizz 14y ago
I think that Mozilla's Rust is aiming squarely at C++ developers, whereas Go is more of a Java replacement. And it's interesting to see Python and Ruby being squeezed lately, from various directions; Clojure, Go, other languages. Since Python went mainstream and started being picked up for serious projects, it naturally came under the spotlight a lot more than it had previously, and I think many people have started to see some of its warts. The transition from version 2 -> 3 wasn't exactly a smooth one, either. Furthermore, although Python is a pretty good all-round language, it doesn't really excel at anything in particular, unlike for example Perl which continues to maintain a strong niche in the areas of text processing and system administration, despite its popularity having fallen away in some of the other areas it was formerly strong in. In my case, although I have recently moved from Perl to Racket for larger and/or more complex work, I still use Perl a lot for small, simple scripts (which constitute most of my programming). A couple of the Java guys I know switched from Python to Clojure for scripting tasks (I could never convince them to like Perl..), and have started to take an interest in languages like Scala and now Go for more substantial projects. For many years now, Python has been the fresh, fun challenger going up against older (and perhaps clunkier) languages, whereas now things seem to be shifting and Python may soon find its role has reversed and it has become the old, crufty language.
- pcwalton 14y ago
  "I think that Mozilla's Rust is aiming squarely at C++ developers, whereas Go is more of a Java replacement." I basically agree with this as a Rust developer (although I'm not sure about Go being in Java's niche; I think of it more as in node.js's niche -- highly scalable web apps). Early on, I think both Rust and Go were thought to be targeting the same segment, but it turned out that we really weren't. Personally, I'm completely fine with that; different language designs are appropriate for different roles. The huge amount of work that we've done to make non-allocating and manually-memory-managed code easy, predictable, and type-safe is totally overkill for Go's niche, for example, while for games and web browsers this sort of thing is essential.
  - heretohelp 14y ago
    As someone who's tried (and failed) to learn Rust in the past: I'm going to elide any commentary about the syntax for now, as I know why it is the way it is (the type system/annotations). I'm basically just going to expound on one thing for the sake of emphasis. For the love of god make Rust more accessible. I don't mean dumbing down the type system or abandoning regions (I really hope that works out). I mean the frickin' documentation. Digging through the core libs to figure out how to dp fairly common case stuff is obscene. Part of the reason I like to tinker with Go in my spare time is that it's extremely hygienic, clean, cheap, and cheerful. Look at the way the "go" binary works, it does everything. It does builds, automatic formatting of code, the works. And it just "works". On top of that, I'd consider getting somebody more knowledgeable about Rust and get them to team up / pair-document with somebody who is a goddamn dumbass like me and start building tutorials/documentation together. I can't imagine the language's syntax and features are so nascent that tutorials and docs for core functionality/libs would be out of the question, you're already prototyping that web browser engine. Documentation is a UX problem, like syntax. Syntax alone crippled Erlang, please don't let obscurity harm a language I am very excited about. If there's any way I can help (maybe a trail of bread crumbs/notes from me as I try to learn it?), let me know in this thread or via email.
drbawb 14y ago
If that's the case, I hope that Haml [and Sass] get properly ported to Go! I'm aware of gohaml; but last I checked it hasn't been updated to work with Go1 and friends. Namely it's using `gomake` and the packages aren't organized for use with `go build`; those issues alone have stopped me from considering it. I went for a version of mustache.go instead, and then bolted Lambda support onto it.

cageface 14y ago

In hindsight it doesn't seem so surprising. Go really isn't a good alternative to C++ for the kinds of things that really need the low-level control and direct memory access C++ provides. And if you don't really need those things you probably should have moved on to Java or Ruby/Python/etc already. And since a lot of Java shops are fantastically risk averse I'm not at all surprised that the same kind of people that were willing to take a risk on Python or Ruby are now into Go. It offers a lot of the expressiveness of either of the former with much better performance, concurrency as a fundamental, and the extra safety of static type checking.

thebigshane 14y ago
Straight from Rob Pike -- http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com/2012/06/less-is-exponentia... Python and Ruby programmers come to Go because they don't have to surrender much expressiveness, but gain performance and get to play with concurrency. C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn't just about getting the job done, it's about doing it a certain way. The issue, then, is that Go's success would contradict their world view. And we should have realized that from the beginning. People who are excited about C++11's new features are not going to care about a language that has so much less. Even if, in the end, it offers so much more.
- mturmon 14y ago
  Nice link. The separate submission and thread is here: http://news.ycombinator.com/item?id=4158865 http://news.ycombinator.com/item?id=4158865
- batista 14y ago
  >The issue, then, is that Go's success would contradict their world view. I call BS. The parent explanation is much better: for a lot of the kinds of jobs C++ is good for, Go is not that good, whereas for a lot of things Python is good for, Go is as good and has better performance.
  - qznc 14y ago
    C++ is better for abstraction, as Go does not have generics yet, and C++ is better for performance. Go is faster to compile. Maybe Go is better for concurrent programming, but this is hard to measure.
    - tptacek 14y ago
      One look at the Go standard library contradicts this. Go is perfectly adequate for abstraction.
      - kragen 14y ago
        I think you may be talking past each other. C++ or D templates allow you to express (in a crude, verbose, error-prone way) some kinds of abstractions that are not expressible in Golang or ML. Not sure about C#. There are certainly lots of abstractions you can express in Golang.
    - draven 14y ago
      Go has interfaces, which can be used to write generic code. Go performance is not on par with optimized C++ but for me it's fast enough and the performance / dev_time ratio is higher.
      - qznc 14y ago
        http://golang.org/pkg/container/list/ http://golang.org/pkg/container/list/ Casting every list element to "interface{}" is not generic.
        14y ago
- tjoff 14y ago
  I have such a hard time believing how anyone could have believed that C/C++ programmers would switch to a GC-only language just like that. I just can't see Go as an alternative to C or C++, and I'm quite surprised that anyone (especially someone such as Rob Pike) could. Sure there are situations where a program that typically would have been written in C/C++ could benefit from Go (so there is a place for it), but the reasons for choosing C/C++ are often the same that makes Go a really bad fit. My dreams of a C-like language where the dangerous parts have been removed (and in this context I don't consider having control of your memory dangerous) took a hit with the introduction of Go :(
  - eckyptang 14y ago
    I think C/C++ programmers have had their reign long enough and have shown us through the amount of utterly horrible security issues that managing memory yourself is a bad idea. Go fits an important niche: stuff that doesn't have to play with the hardware directly, which is pretty much everything but the OS. I controversially consider there to be no other use for C bsaed languages these days other than at the kernel level. It's better to centralise the memory management and optimisation either into a VM or compiler. It's easier and safer to verify a compiler (mathematically or otherwise) than every memory access that you do. Due to my engineering background, I would always sacrifice performance for less risk and more reliability. I've also spent 20 years writing C and C++ so I know how horrible it is.
    - tjoff 14y ago
      Go fits an important niche: stuff that doesn't have to play with the hardware directly, which is pretty much everything but the OS. The anything-but-the-OS-niche? I thought we had plenty of languages for that. It's better to centralise the memory management and optimisation either into a VM or compiler. It's easier and safer to verify a compiler (mathematically or otherwise) than every memory access that you do. You seem to ignore performance altogether, if you programmed in C/C++ for twenty years but don't care for performance and don't do low-level work, why have you been using C/C++? Or if you have been doing low level or performance critical work, why wouldn't you want a safer alternative for that? When you have to tune and debug your application to please the garbage collector having to deal with your own memory seems like child's play. It is much easier and safer to verify that your own memory management won't bite you than it is to be sure that your garbage collector won't eat you. (surely that depends on the context etc. but making broad claims seems to be on topic...) Right tool for the right job. C/C++ has "monopoly" on a lot of use cases (way more than any other language) and considering its issues I truly believe that a "better C/C++" is needed, way more than those 20 JVM-based languages that popup every other month. Or Go.
oofabz 14y ago
I write Go and I have been satisfied with the low-level control and direct memory access. The language has pointers and you can cast between ints and pointers, so you can do anything you can do in C. If you're writing realtime code, you can avoid triggering the garbage collector simply by not allocating memory on the heap. It is harder to get anything done this way, but writing realtime code in any language is difficult.
- cageface 14y ago
  I actually haven't gotten this far with Go myself so I'm glad to hear that it's possible. But there's a huge uphill battle ahead for Go here. For instance, I write C++ code because I'm doing music software and all the APIs and existing code libraries and samples are in C++. It's just so much easier in this environment to put up with C++'s warts than it would be to try to shoehorn Go in there. As John Carmack says, externalities can quickly overwhelm the advantages of any particular language. But if you're implementing web services from scratch you don't have any of that baggage to carry around so it's much easier to choose Go.
  - Evbn 14y ago
    Swig can help there?
    - cageface 14y ago
      For my particular application it's not even close to worth it, but in some cases I can imagine it might be worth the hassle.
    - akavel 14y ago
      or cgo? http://golang.org/cmd/cgo/ http://golang.org/cmd/cgo/
- aaronblohowiak 14y ago
  >you can do anything you can do in C This is true only for very limited meanings of "anything"; if your point was that you had direct control of memory layout and you can use CGO for those things that C offers but go does not. For instance, the volatile keyword..
StavrosK 14y ago
> In hindsight it doesn't seem so surprising. Most things don't seem surprising in hindsight. That's why you don't judge surprises by it. If C++ programmers did flock to Go, would you then say that that was surprising? If not, you've just fallen victim to hindsight bias (because a model that predicts everything is useless).
- cageface 14y ago
  Most things don't seem surprising in hindsight. That's why you don't judge surprises by it. Surprising was GP's original term, not mine. I don't expect Go or any other language to displace C++ any time soon. But I do think the "scripting" languages are very vulnerable to challenges from languages with static typing systems less primitive than Java's.
  - StavrosK 14y ago
    That's because the GP was surprised. I rather should have said, you don't judge that something wasn't surprising by hindsight. Hindsight makes things obvious.

Lewisham 14y ago

I think a lot of it is that people sort of did want some static type checking, but were not willing to give up on things like garbage collection or some of the other niceties that the dynamic languages provided. As someone who has been clamoring for a statically-checked Python-esque language, Go looks awesome.

deleted 14y ago
[deleted]

jonathansizz 14y ago

I think that Mozilla's Rust is aiming squarely at C++ developers, whereas Go is more of a Java replacement. And it's interesting to see Python and Ruby being squeezed lately, from various directions; Clojure, Go, other languages. Since Python went mainstream and started being picked up for serious projects, it naturally came under the spotlight a lot more than it had previously, and I think many people have started to see some of its warts. The transition from version 2 -> 3 wasn't exactly a smooth one, either. Furthermore, although Python is a pretty good all-round language, it doesn't really excel at anything in particular, unlike for example Perl which continues to maintain a strong niche in the areas of text processing and system administration, despite its popularity having fallen away in some of the other areas it was formerly strong in. In my case, although I have recently moved from Perl to Racket for larger and/or more complex work, I still use Perl a lot for small, simple scripts (which constitute most of my programming). A couple of the Java guys I know switched from Python to Clojure for scripting tasks (I could never convince them to like Perl..), and have started to take an interest in languages like Scala and now Go for more substantial projects. For many years now, Python has been the fresh, fun challenger going up against older (and perhaps clunkier) languages, whereas now things seem to be shifting and Python may soon find its role has reversed and it has become the old, crufty language.

pcwalton 14y ago
"I think that Mozilla's Rust is aiming squarely at C++ developers, whereas Go is more of a Java replacement." I basically agree with this as a Rust developer (although I'm not sure about Go being in Java's niche; I think of it more as in node.js's niche -- highly scalable web apps). Early on, I think both Rust and Go were thought to be targeting the same segment, but it turned out that we really weren't. Personally, I'm completely fine with that; different language designs are appropriate for different roles. The huge amount of work that we've done to make non-allocating and manually-memory-managed code easy, predictable, and type-safe is totally overkill for Go's niche, for example, while for games and web browsers this sort of thing is essential.
- heretohelp 14y ago
  As someone who's tried (and failed) to learn Rust in the past: I'm going to elide any commentary about the syntax for now, as I know why it is the way it is (the type system/annotations). I'm basically just going to expound on one thing for the sake of emphasis. For the love of god make Rust more accessible. I don't mean dumbing down the type system or abandoning regions (I really hope that works out). I mean the frickin' documentation. Digging through the core libs to figure out how to dp fairly common case stuff is obscene. Part of the reason I like to tinker with Go in my spare time is that it's extremely hygienic, clean, cheap, and cheerful. Look at the way the "go" binary works, it does everything. It does builds, automatic formatting of code, the works. And it just "works". On top of that, I'd consider getting somebody more knowledgeable about Rust and get them to team up / pair-document with somebody who is a goddamn dumbass like me and start building tutorials/documentation together. I can't imagine the language's syntax and features are so nascent that tutorials and docs for core functionality/libs would be out of the question, you're already prototyping that web browser engine. Documentation is a UX problem, like syntax. Syntax alone crippled Erlang, please don't let obscurity harm a language I am very excited about. If there's any way I can help (maybe a trail of bread crumbs/notes from me as I try to learn it?), let me know in this thread or via email.

drbawb 14y ago

If that's the case, I hope that Haml [and Sass] get properly ported to Go! I'm aware of gohaml; but last I checked it hasn't been updated to work with Go1 and friends. Namely it's using `gomake` and the packages aren't organized for use with `go build`; those issues alone have stopped me from considering it. I went for a version of mustache.go instead, and then bolted Lambda support onto it.