5 ms·

Google came out with Go some months ago, now Mozilla presents Rust. Both languages seem to be targetted at the same audience, I fear it's mere corporate politic

Google came out with Go some months ago, now Mozilla presents Rust. Both languages seem to be targetted at the same audience, I fear it's mere corporate politics that prevent both from using the same language, isn't it? Addon-question, don't know if it fits: Has Google's Go gained publicity apart from having a vibrant community on Google's mailing list?

__bjoernd 16y ago
Note to self: Rust's FAQ actually mentions differences to Go.
alnayyir 16y ago
>I fear it's mere corporate politics that prevent both from using the same language, isn't it? If anyone is guilty of NIH, it's Google. Google didn't use LLVM, didn't follow the example of some more thorough and less facile concurrency models, didn't exercise the necessary discipline re: mutable data structures, and didn't appear to have been keeping up with any lang research that has gone on since the 90s. Whereas Rust is made by a known language implementor, the impetus of the project was not in fact Mozilla's motives (they're merely supporting it after the fact), and it targets LLVM with the bootstrapping OCaml->RS implementation. So by all means, explain to me why the non-gcc implementation (6g, 8g) for Google Go not being LLVM somehow isn't classic NIH. With Go, Google based the language design upon what they'd like (Python with coroutines for systems programming), rather than actual research, restraint, or even using the existing best of class tools for implementation. Edit: >Has Google's Go gained publicity apart from having a vibrant community on Google's mailing list? It got some mentioned on various tech news streams, nothing mainstream or substantial. I've seen (very) occasional posts on YC News of little toy projects in Go, but again, nothing I'd really notice or care about. I'd say Node.js has gotten a much faster start than Go, and don't give me any guff about JavaScript being older, it doesn't matter, server-side js hadn't been done properly before Ryan Dahl.
- wmf 16y ago
  explain to me why the non-gcc implementation (6g, 8g) for Google Go not being LLVM somehow isn't classic NIH. The Go compilers are based on the Plan 9 compilers which predate LLVM. I don't think it's a good reason, but that's the reason.
  - alnayyir 16y ago
    How does any of that contradict this being NIH? Just because it's ken's NIH doesn't change that that is what it is.
    - wmf 16y ago
      But there are different levels of NIH, where "I already had working code" is probably less bad than "I wrote my own because I felt like it".
      - alnayyir 16y ago
        That's a fair way to put it, I think. It's still rather immense to my mind how much trouble they went through for no apparent reason.
- kaib 16y ago
  > So by all means, explain to me why the non-gcc implementation (6g, 8g) for Google Go not being LLVM somehow isn't classic NIH. Disclaimer: I know a bit about the background to the choice, I wasn't involved but I've seen the consequences having worked with the 5g arm compiler. The code generation part of 5g/5l is on the order of 10k lines of C, the whole 8g/6g/5g compiler suite is ~115k. I don't know how to break down LLVM but the whole project looks like ~270k lines of C++ so the code generation is probably more than 10k. Now imagine you are tasked with writing a compiler for an experimental language where one of the key features is blazingly fast compilation. The plan9 compilers are fast, you wrote them yourself so you know their strengths and weaknesses. The plan9 compilers are also reasonably small and written in C which you know well. You know nothing about LLVM. It could be good but it would take some time to find out. You also don't know too much C++ and it would take some time to get up to speed. I would be very interested in understanding why this is NIH as opposed to reasonable management of risk?
  - alnayyir 16y ago
    >where one of the key features is blazingly fast compilation Oh come on. That's one of the banal [excuses|priorities] I've ever heard. I was aware of it, I just couldn't believe someone would invoke it with a straight face. >I would be very interested in understanding why this is NIH as opposed to reasonable management of risk? When you ignore the prime project that has the most labor, most corporate support and funding, the most data, and the most documentation as a competitor to gcc, and it's BSD licensed, and it's perfectly available for compilation/testing to see if it's appropriate to your needs... ...that's classic NIH. You've outlined basic FUD fueled by lack of knowledge of the alternatives. Management of risk? The code is BSD licensed, spare me! If you want to take the code and run off with it in the sunset, you're perfectly able to do so. Instead of at least re-using/borrowing code from LLVM, they decided to embark on a rather laborious and difficult aspect of language development themselves with zero input from other projects. The cognitive dissonance required to believe that when you reach that kind of decision-chain, that what you're doing is anything other than pride/fear/NIH must be immense. I understand that Google has a fetish for the academic/open source elite in their hiring practices, but that doesn't get them a wholesale license to chuck common sense out the window and disregard the work of all others. ARM compatibility, gee, that does make depending on other compiler infrastructures tricky since you can't trust anyone to support anything other than x8---- wait a tick. "An easily retargettable code generator, which currently supports X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, PIC16 MIPS, MSP430, SystemZ, and XCore." --- http://llvm.org/Features.html http://llvm.org/Features.html I'm not buyin' what you're selling. Was I involved in the production of Go? No, but I've been tracking it since it was publicized and unless there's some detail/issue/licensing matter/temporal rift involved that I'm made aware of, I'm just not going to swallow the notion that it was anything other than NIH muddled by incomplete information.
- dagw 16y ago
  Was Go really a Google project, as opposed to a project by an employee at Google that turned out kind of useful? Basically can one say Google did this and Google didn't do that as if those choices where dictated by company policy?
  - alnayyir 16y ago
    Lots of question marks. Let me help you with that: http://en.wikipedia.org/wiki/Go_(programming_language) http://en.wikipedia.org/wiki/Go_(programming_language)
- SteveMcQwark 16y ago
  I'd like to point out that Go also started as a personal project (a 20% time project at Google) that later got picked up by the company, so your statement that the same is the case for Rust isn't really a distinction, but a similarity.
neilk 16y ago
Rust was in the works years before Go was made public. I happen to know some of the authors and I can assure you it's not about corporate politics. The authors of Rust are just interested in exploring different concepts from the Go people.

__bjoernd 16y ago

Note to self: Rust's FAQ actually mentions differences to Go.

alnayyir 16y ago

>I fear it's mere corporate politics that prevent both from using the same language, isn't it? If anyone is guilty of NIH, it's Google. Google didn't use LLVM, didn't follow the example of some more thorough and less facile concurrency models, didn't exercise the necessary discipline re: mutable data structures, and didn't appear to have been keeping up with any lang research that has gone on since the 90s. Whereas Rust is made by a known language implementor, the impetus of the project was not in fact Mozilla's motives (they're merely supporting it after the fact), and it targets LLVM with the bootstrapping OCaml->RS implementation. So by all means, explain to me why the non-gcc implementation (6g, 8g) for Google Go not being LLVM somehow isn't classic NIH. With Go, Google based the language design upon what they'd like (Python with coroutines for systems programming), rather than actual research, restraint, or even using the existing best of class tools for implementation. Edit: >Has Google's Go gained publicity apart from having a vibrant community on Google's mailing list? It got some mentioned on various tech news streams, nothing mainstream or substantial. I've seen (very) occasional posts on YC News of little toy projects in Go, but again, nothing I'd really notice or care about. I'd say Node.js has gotten a much faster start than Go, and don't give me any guff about JavaScript being older, it doesn't matter, server-side js hadn't been done properly before Ryan Dahl.

wmf 16y ago
explain to me why the non-gcc implementation (6g, 8g) for Google Go not being LLVM somehow isn't classic NIH. The Go compilers are based on the Plan 9 compilers which predate LLVM. I don't think it's a good reason, but that's the reason.
- alnayyir 16y ago
  How does any of that contradict this being NIH? Just because it's ken's NIH doesn't change that that is what it is.
  - wmf 16y ago
    But there are different levels of NIH, where "I already had working code" is probably less bad than "I wrote my own because I felt like it".
    - alnayyir 16y ago
      That's a fair way to put it, I think. It's still rather immense to my mind how much trouble they went through for no apparent reason.
kaib 16y ago
> So by all means, explain to me why the non-gcc implementation (6g, 8g) for Google Go not being LLVM somehow isn't classic NIH. Disclaimer: I know a bit about the background to the choice, I wasn't involved but I've seen the consequences having worked with the 5g arm compiler. The code generation part of 5g/5l is on the order of 10k lines of C, the whole 8g/6g/5g compiler suite is ~115k. I don't know how to break down LLVM but the whole project looks like ~270k lines of C++ so the code generation is probably more than 10k. Now imagine you are tasked with writing a compiler for an experimental language where one of the key features is blazingly fast compilation. The plan9 compilers are fast, you wrote them yourself so you know their strengths and weaknesses. The plan9 compilers are also reasonably small and written in C which you know well. You know nothing about LLVM. It could be good but it would take some time to find out. You also don't know too much C++ and it would take some time to get up to speed. I would be very interested in understanding why this is NIH as opposed to reasonable management of risk?
- alnayyir 16y ago
  >where one of the key features is blazingly fast compilation Oh come on. That's one of the banal [excuses|priorities] I've ever heard. I was aware of it, I just couldn't believe someone would invoke it with a straight face. >I would be very interested in understanding why this is NIH as opposed to reasonable management of risk? When you ignore the prime project that has the most labor, most corporate support and funding, the most data, and the most documentation as a competitor to gcc, and it's BSD licensed, and it's perfectly available for compilation/testing to see if it's appropriate to your needs... ...that's classic NIH. You've outlined basic FUD fueled by lack of knowledge of the alternatives. Management of risk? The code is BSD licensed, spare me! If you want to take the code and run off with it in the sunset, you're perfectly able to do so. Instead of at least re-using/borrowing code from LLVM, they decided to embark on a rather laborious and difficult aspect of language development themselves with zero input from other projects. The cognitive dissonance required to believe that when you reach that kind of decision-chain, that what you're doing is anything other than pride/fear/NIH must be immense. I understand that Google has a fetish for the academic/open source elite in their hiring practices, but that doesn't get them a wholesale license to chuck common sense out the window and disregard the work of all others. ARM compatibility, gee, that does make depending on other compiler infrastructures tricky since you can't trust anyone to support anything other than x8---- wait a tick. "An easily retargettable code generator, which currently supports X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, PIC16 MIPS, MSP430, SystemZ, and XCore." --- http://llvm.org/Features.html http://llvm.org/Features.html I'm not buyin' what you're selling. Was I involved in the production of Go? No, but I've been tracking it since it was publicized and unless there's some detail/issue/licensing matter/temporal rift involved that I'm made aware of, I'm just not going to swallow the notion that it was anything other than NIH muddled by incomplete information.
dagw 16y ago
Was Go really a Google project, as opposed to a project by an employee at Google that turned out kind of useful? Basically can one say Google did this and Google didn't do that as if those choices where dictated by company policy?
- alnayyir 16y ago
  Lots of question marks. Let me help you with that: http://en.wikipedia.org/wiki/Go_(programming_language) http://en.wikipedia.org/wiki/Go_(programming_language)
SteveMcQwark 16y ago
I'd like to point out that Go also started as a personal project (a 20% time project at Google) that later got picked up by the company, so your statement that the same is the case for Rust isn't really a distinction, but a similarity.

neilk 16y ago

Rust was in the works years before Go was made public. I happen to know some of the authors and I can assure you it's not about corporate politics. The authors of Rust are just interested in exploring different concepts from the Go people.