The Rust programming language
lambda-the-ultimate.org
lambda-the-ultimate.org
This is like the flat feature lists of the smartphone wars that matter exactly not-at-all.
At the unveiling yesterday, Graydon (the author) said he deliberately has spent no time making syntax nice, and refused to discuss syntax until a much later date to avoid bikeshedding. As a result, its not very pretty code but you can't judge it on that.
The emphasis on multi-paradigm in the docs has less to do with ZOMG FEATURES and more with the restraint lack of force applied to the programmer in terms of style.
I think it would behoove you to look through the source before accusing them of featureitis.
The primary author (Graydon Hoare) is IMO a frickin' genius, but even so he is at pains to reduce expectations for Rust at this time. So, go easy on Rust for now.
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?
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.
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.
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?
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
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.
I think there are two separate concerns, both which I'm disagreeing with you on. First, my understanding is that when ken wrote the initial compilers he wanted to focus on the frontend and re-use a backend. So he picked the plan9 compilers which he knew well (they predate LLVM by 10 years and he mostly wrote them). There was very little original work going into the code generation.
Second, I think you are grossly underestimating the initial cost of integrating with an open source project unkown to someone. The first Go compiler frontend was written in a few weeks or months. I'm guessing that having to pick up a new unknown backend (LLVM) and language (C++) would have set the project back enough to make it miss it's window of opportunity.
It seems to me that your argument is that an incorrect choice was made in what to re-use. That seems like a very different thing than NIH.
> ARM compatibility
ARM compatibility had nothing to do with the decision to re-use the plan9 compilers. I'm a compiler neophyte and when I wanted to add ARM support to Go it was an easy choice to go with the existing framework (there was a solid plan9 C compiler for ARM). If I had tried to port the system to LLVM at the same time as adding ARM support my skills would probably have failed me.
> fast compilation
One of the distinctive features of the optimizers ken wrote for plan9 C, which are used in Go, is that they are much simpler and faster than normal optimizers but produce less optimal code. The GCC Go compilers are slower and slightly less comprehensive but produce code of higher quality. LLVM would undoubtedly produce better code as well. I'm happy to go into more technical detail if you want to, it would help if you'd let me know how much practical compiler writing experience you have?
I for one would like to see a Go front end for LLVM. In fact, the front end used by gccgo is a separate project from gcc and BSD - not GPL - licensed (http://code.google.com/p/gofrontend) specifically to make that easier and so that gccgo and an eventual go-for-LLVM can share code.
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.
Rust is a curly-brace, block-structured statement language. It visually resembles the C language family, but differs significantly in syntactic and semantic details.
I'm not a programming language buff, but why curly-braces and C-style still in 2010?
--- professional Python coder
(P.S. I like significant whitespace, but I also really don't care.)
+ is sooooooooooo 1600s, we should restandardize with ʮ for addition so that + strictly applies to string concatenation...
1) space significant (Python, Esterel) 2) braces or other one character delimiters 3) begin/end or other word delimiters
I find 3) very noisy and while I like 1) (even though I dislike Python), I find that 2) is a pretty good compromise, one where I don't find myself having to visually parse classes ending in "end end end end end".
Plus some languages, such as Haskell, allow for both braces and significant indentation, with the language culture encouraging responsible usage.
That being said, looking over some of the core features, D seemed very similar in spirit.
In future prepare more thorough and informed commentary if you don't want to take a hit on your karma.
If you're unwilling or unable to read the documentation and peruse through the implementation source of your own accord, then I don't think this is the community for you.
Either way, good day and have yourself a nice meal whenever the next one is. :)