4 ms·

I don't think Go is any more appropriate as a comparison to C++ than Java or C# are. After all, Go essentially competes in the same space as Java and C#--it's a

by tikhonj 14y ago

I don't think Go is any more appropriate as a comparison to C++ than Java or C# are. After all, Go essentially competes in the same space as Java and C#--it's a managed imperative language designed for use on a server. Now, D and Rust are another story. After doing a bit of reading, I'm actually very excited about Rust. For me, Go is essentially completely useless: it fills the same niche as Java, C# or--far more importantly--Haskell or OCaml. If I need code that's relatively fast but don't want to sacrifice memory safety or the convenience of a high-level language, I can do much better than Go. On the other hand, if I want really low-level access to the system, for whatever reason, I don't have many good choices. I could do C, but that's rather unsafe and unpleasant; I could do C++, but it's a gigantic, overly complex language and also rather unsafe and unpleasant and I could do D. (I've actually heard good things about D but have never tried it.) Rust gives me the perfect alternative--a simpler, higher-level language that's more pleasant to use but still lets me operate at a relatively low level. So next time I need to do something like that (which, honestly, probably won't be soon), I'm almost definitely going to use Rust, even if it's in active development and changing all the time. EDIT: In re-reading this comment, I have realized that "high-level" and "low-level" really aren't great terms (at least the way I'm using them). Particularly, they're not mutually exclusive: a language can both support a high level of abstraction and provide low-level systems access where needed. Of course, I can't think of any language that actually does this, but Rust seems very promising.

acqq 14y ago
If you're doing anything serious, you need something that is going to compile even when compiler changes from version to version, unless you plan to write only a few lines, when it doesn't matter which language is used anyway. That's why I don't understand your argument for Rust. I'd vote for D.
- shmerl 14y ago
  Rust got into more stable state with the last release.
- pcwalton 14y ago
  Rust feature freeze is soon. These days we reject probably 90% of the proposals to incompatibly change the language. There will still be churn, but it's much smaller nowadays; once we hit 1.0 we will be committing to backwards compatibility.
  - Dn_Ab 14y ago
    I'm also really excited about Rust. What would be unimaginable exciting would be if Rust has any plans for iPhone or Android devices. Preferably without a 10MB runtime and a decent debug story. Elsewise, absent the runtime,F# is the most interesting language closest to fitting that bill.
    - pcwalton 14y ago
      Rust definitely has Android support planned.
- eliasmacpherson 14y ago
  If you look at what's been added and removed from C++ and the C++ STL as of C++11, there are changes required to get formerly valid code to compile under it too. noexcept() as a replacement for throw() in particular. I'm sure Rust has a lot more frequent changes though.
- hamstergene 14y ago
  Rust is changing because it's still under development. D had that period too.
- shawn-butler 14y ago
  I gave up on D despite all the positives some time ago because of no support for ARM by Digital Mars. I wonder if the situation is improved now with the GDC effort to use GCC 4.7, 4.8 as a backend?
  - pjmlp 14y ago
    You have support via GDC and LDC.
- pretoriusB 14y ago
  >If you're doing anything serious, you need something that is going to compile even when compiler changes from version to version, unless you plan to write only a few lines, when it doesn't matter which language is used anyway. That's why I don't understand your argument for Rust. C changed going to ANSI C, and C++ change a lot from "C with classes" to the first standard. And D, the one you would "vote for"? Wasn't there the whole mess between 2 versions of the language and libraries? So, why should Rust be any different, considering it's still in design and pre-stable? When the spec freezes and Rust hits version 1, it would be a fully suitable language for his needs.
eriksank 14y ago
It seems quite easy to use C libraries from Rust but not the other way around. Since you cannot easily use Rust libraries from C -- where is the .h header file generator? -- you cannot easily use it from any scripting engine either. How would its language constructs carry across on the C ABI anyway? So, Rust also accidentally becomes a final, top-level language, competing in that space with Javascript, Python, Ruby, PHP, Perl, Lua and so on. Rust does not stand a shadow of a chance in that space. Therefore, it can only suffer a fate worse than C++, which in spite of all problems can still be accessed from scripting engines.
- kibwen 14y ago
  This is mistaken, there are mid-term plans to make Rust code able to run standalone--without a runtime and with a C-compatible ABI--such that it will be entirely possible to call Rust from C.
dysoco 14y ago
I think of Go as a "modern replacement for C", being designed by Rob Pike and Ken Thompson: I think it's really designed to be a Systems Programming language, I wouldn't write a Kernel or a Driver in Go: but it's a modern alternative to implement other related software like userland or networking. I also like Rust, but I'll wait until it's more stable and we have a couple of books to learn from.
4ad 14y ago
Go is not a managed language, it's compiled to machine code and it gives access to the memory layout, just like C and C++ and unlike Java or C#.
- pjmlp 14y ago
  Take care with Go PR, and don't mistake languages with implementations. Java compilers to native code: - VMKit - gcj - Excelsior JET C# compilers to native code: - Windows Phone 8 deployment - NGEN - Bartok - Mono with -aot Additionally C# has control over memory layout via pointers, aligment attributes, marshaling, structs and generics.
  - 4ad 14y ago
    tikhonj was talking about implementations when he described Go as managed imperative language. Go is compiled to native code in all major implementations. In general, it's extremely easy to determine when people are talking about implementations and when they are talking about the language proper. Implementations are important. The primary implementation shapes the language, the way the standard library is designed and scoped, and seeds the ecosystem surrounding the language. Changing the implementation to a native one after the fact changes very little. > Additionally C# has control over memory layout via pointers, aligment attributes, marshaling, structs and generics. This is not true. The level of control you get is extremely limited due to the fact that very few types are values in C#.
    - pjmlp 14y ago
      > Go is compiled to native code in all major implementations So is C#, bytecodes are only used as a storage format. With Microsoft tooling you can JIT at load time, NGEN at installation time, convert to MDIL when uploading to Windows 8 App Store, or convert to pure binary with Bartok in Singularity. With Mono tooling you can JIT at load time or generate binaries with mono -aot. With Cosmos OS , it gets compiled to native code. > This is not true. The level of control you get is extremely limited due to the fact that very few types are values in C#. Please provide an example where Go compilers offer more control than C# ones.

by tikhonj 14y ago

acqq 14y ago

If you're doing anything serious, you need something that is going to compile even when compiler changes from version to version, unless you plan to write only a few lines, when it doesn't matter which language is used anyway. That's why I don't understand your argument for Rust. I'd vote for D.

shmerl 14y ago
Rust got into more stable state with the last release.
pcwalton 14y ago
Rust feature freeze is soon. These days we reject probably 90% of the proposals to incompatibly change the language. There will still be churn, but it's much smaller nowadays; once we hit 1.0 we will be committing to backwards compatibility.
- Dn_Ab 14y ago
  I'm also really excited about Rust. What would be unimaginable exciting would be if Rust has any plans for iPhone or Android devices. Preferably without a 10MB runtime and a decent debug story. Elsewise, absent the runtime,F# is the most interesting language closest to fitting that bill.
  - pcwalton 14y ago
    Rust definitely has Android support planned.
eliasmacpherson 14y ago
If you look at what's been added and removed from C++ and the C++ STL as of C++11, there are changes required to get formerly valid code to compile under it too. noexcept() as a replacement for throw() in particular. I'm sure Rust has a lot more frequent changes though.
hamstergene 14y ago
Rust is changing because it's still under development. D had that period too.
shawn-butler 14y ago
I gave up on D despite all the positives some time ago because of no support for ARM by Digital Mars. I wonder if the situation is improved now with the GDC effort to use GCC 4.7, 4.8 as a backend?
- pjmlp 14y ago
  You have support via GDC and LDC.
pretoriusB 14y ago
>If you're doing anything serious, you need something that is going to compile even when compiler changes from version to version, unless you plan to write only a few lines, when it doesn't matter which language is used anyway. That's why I don't understand your argument for Rust. C changed going to ANSI C, and C++ change a lot from "C with classes" to the first standard. And D, the one you would "vote for"? Wasn't there the whole mess between 2 versions of the language and libraries? So, why should Rust be any different, considering it's still in design and pre-stable? When the spec freezes and Rust hits version 1, it would be a fully suitable language for his needs.

eriksank 14y ago

It seems quite easy to use C libraries from Rust but not the other way around. Since you cannot easily use Rust libraries from C -- where is the .h header file generator? -- you cannot easily use it from any scripting engine either. How would its language constructs carry across on the C ABI anyway? So, Rust also accidentally becomes a final, top-level language, competing in that space with Javascript, Python, Ruby, PHP, Perl, Lua and so on. Rust does not stand a shadow of a chance in that space. Therefore, it can only suffer a fate worse than C++, which in spite of all problems can still be accessed from scripting engines.

kibwen 14y ago
This is mistaken, there are mid-term plans to make Rust code able to run standalone--without a runtime and with a C-compatible ABI--such that it will be entirely possible to call Rust from C.

dysoco 14y ago

I think of Go as a "modern replacement for C", being designed by Rob Pike and Ken Thompson: I think it's really designed to be a Systems Programming language, I wouldn't write a Kernel or a Driver in Go: but it's a modern alternative to implement other related software like userland or networking. I also like Rust, but I'll wait until it's more stable and we have a couple of books to learn from.

4ad 14y ago

Go is not a managed language, it's compiled to machine code and it gives access to the memory layout, just like C and C++ and unlike Java or C#.

pjmlp 14y ago
Take care with Go PR, and don't mistake languages with implementations. Java compilers to native code: - VMKit - gcj - Excelsior JET C# compilers to native code: - Windows Phone 8 deployment - NGEN - Bartok - Mono with -aot Additionally C# has control over memory layout via pointers, aligment attributes, marshaling, structs and generics.
- 4ad 14y ago
  tikhonj was talking about implementations when he described Go as managed imperative language. Go is compiled to native code in all major implementations. In general, it's extremely easy to determine when people are talking about implementations and when they are talking about the language proper. Implementations are important. The primary implementation shapes the language, the way the standard library is designed and scoped, and seeds the ecosystem surrounding the language. Changing the implementation to a native one after the fact changes very little. > Additionally C# has control over memory layout via pointers, aligment attributes, marshaling, structs and generics. This is not true. The level of control you get is extremely limited due to the fact that very few types are values in C#.
  - pjmlp 14y ago
    > Go is compiled to native code in all major implementations So is C#, bytecodes are only used as a storage format. With Microsoft tooling you can JIT at load time, NGEN at installation time, convert to MDIL when uploading to Windows 8 App Store, or convert to pure binary with Bartok in Singularity. With Mono tooling you can JIT at load time or generate binaries with mono -aot. With Cosmos OS , it gets compiled to native code. > This is not true. The level of control you get is extremely limited due to the fact that very few types are values in C#. Please provide an example where Go compilers offer more control than C# ones.