4 ms·

Isn't .NET Native comparable to Go? I mean, an ahead-of-time compiled, garbage collected language. Whereas both Rust and C++ don't have mandatory GC. That bein

by barosl 11y ago

Isn't .NET Native comparable to Go? I mean, an ahead-of-time compiled, garbage collected language. Whereas both Rust and C++ don't have mandatory GC. That being said, I'm really excited to see a single binary .NET application on Linux, as I like C# very much, possibly more than Go and Java.

pjmlp 11y ago
Yes, but currently I don't see any OS vendor picking up Rust, for what really matters, systems programming, e.g. drivers, kernel space modules, embedded development. For anything else, Rust will have to deal with existing languages that are also able to deliver results. Regarding GC, not all GC were made alike and being able to use value types also helps. Rust needs to find a sweet spot to pick up speed. Being yet another application language won't help.
- bad_user 11y ago
  You're making the mistake of thinking that only "OS vendors" are interested in languages like C++ or Rust, or that such languages are only interesting for the kernel space or embedded stuff. That couldn't be further from the truth. Languages without a GC are a requirement for anything real-time and desirable even for soft real-time. A lot of applications fall into this space, including audio/video processing, real-time bidding systems or game engines. There's a really good reason for why a lot of software being built for the finance industry is being built in C++. > not all GC were made alike and being able to use value types also helps Value types don't help quite as much as people think, value types only help avoid some unnecessary boxing/unboxing, relieving some pressure from the young generation and that's it. The problem is storing a lot of data in memory which will imply heap management and dealing with a big old generation, no matter what you do. And there are only 2 GC-enabled platforms suitable for many soft real time use-cases (but not all) and those would be Java and Erlang ... Erlang because it was built for such scenarios with its lightweight processes and the per-process GC and Java because it has fancy incremental and non-blocking GCs available, like the one from Azul.
  - pjmlp 11y ago
    > You're making the mistake of thinking that only "OS vendors" are interested in languages like C++ or Rust, or that such languages are only interesting for the kernel space or embedded stuff. That couldn't be further from the truth. Well, I have been coding since 1986 and the only systems programming languages that survived were the ones adapted by OS vendors. If a systems programming language isn't adopted by an OS vendor, it becomes yet another application programming language and has to compete in already full arena. > There's a really good reason for why a lot of software being built for the finance industry is being built in C++. I do like C++, a lot, given its capabilities. But also dislike the unsafety it inherited from C. However, I think one of the reasons C and C++ got so widespread is that 20 years ago, Java and .NET kind of killed all the other alternatives capable of produced standalone executables with optimizing compilers. At least from what mainstream developers are comfortable with. So when a average developer goes looking for a programming language able to deliver binaries without dependencies his/her only options are C and C++, which feeds the circle. I bet if Java, C# and VB.NET had gone the way of producing binaries like Delphi, Oberon and so on, the domain of C and C++ wouldn't be as it is nowadays. For example, if Ada compilers were cheaper or if Borland had improved Delphi's toolchain across multiple OS instead of going astray in multiple directions, any of those languages could be in C++'s place. Actually finance is one of the reasons why both Java and .NET are getting pure AOT compilation support nowadays. > Value types don't help quite as much as people think, value types only help avoid some unnecessary boxing/unboxing, relieving some pressure from the young generation and that's it. The problem is storing a lot of data in memory which will imply heap management and dealing with a big old generation, no matter what you do. Yet Mesa/Cedar, Oberon and Modula-3 were used successfully to build OSes that, in Oberon and Cedar's case, were used for quite a while as ETHZ and Xerox PARC workstations.
    - bad_user 11y ago
      I believe that the need of producing binaries without dependencies (I assume you mean a VM) isn't so widespread, quite the contrary, most developers want a VM underneath because then deployment becomes easier. The loud minority that has historically complained about the widespread usage of the VM have been just that, a minority. And it is funny, because things are progressing in that direction with C++ as well (speaking of LLVM or Emscripten). That is not and has never been the real difference between C++ and Java/.NET, but rather in having versus not having a GC. The main reason for why C++ still wins by a good amount in any benchmark is because for performance sensitive code memory access becomes by far the biggest bottleneck and in C++ there's simply more opportunity for optimizing memory access patterns. Delphi too lacked a GC. Java and .NET haven't killed Delphi, it is Borland that killed Delphi. This isn't a winner takes all kind of war (well, maybe it is in Windows land). We live in an industry in which multiple programming languages can coexist. For evidence of this you need to look no further than Linux, the Tower of Babel of our age. And I disagree with you - besides the open-source operating systems that are developed by multiple parties, all "OS vendors" are interested in the lock-in of developers. You're mixing cause and effect I think ... when an "OS vendor" adopts a programming language that isn't created by themselves, that's only because the programming language in question is already popular and here to stay.

by barosl 11y ago

pjmlp 11y ago

Yes, but currently I don't see any OS vendor picking up Rust, for what really matters, systems programming, e.g. drivers, kernel space modules, embedded development. For anything else, Rust will have to deal with existing languages that are also able to deliver results. Regarding GC, not all GC were made alike and being able to use value types also helps. Rust needs to find a sweet spot to pick up speed. Being yet another application language won't help.

bad_user 11y ago
You're making the mistake of thinking that only "OS vendors" are interested in languages like C++ or Rust, or that such languages are only interesting for the kernel space or embedded stuff. That couldn't be further from the truth. Languages without a GC are a requirement for anything real-time and desirable even for soft real-time. A lot of applications fall into this space, including audio/video processing, real-time bidding systems or game engines. There's a really good reason for why a lot of software being built for the finance industry is being built in C++. > not all GC were made alike and being able to use value types also helps Value types don't help quite as much as people think, value types only help avoid some unnecessary boxing/unboxing, relieving some pressure from the young generation and that's it. The problem is storing a lot of data in memory which will imply heap management and dealing with a big old generation, no matter what you do. And there are only 2 GC-enabled platforms suitable for many soft real time use-cases (but not all) and those would be Java and Erlang ... Erlang because it was built for such scenarios with its lightweight processes and the per-process GC and Java because it has fancy incremental and non-blocking GCs available, like the one from Azul.
- pjmlp 11y ago
  > You're making the mistake of thinking that only "OS vendors" are interested in languages like C++ or Rust, or that such languages are only interesting for the kernel space or embedded stuff. That couldn't be further from the truth. Well, I have been coding since 1986 and the only systems programming languages that survived were the ones adapted by OS vendors. If a systems programming language isn't adopted by an OS vendor, it becomes yet another application programming language and has to compete in already full arena. > There's a really good reason for why a lot of software being built for the finance industry is being built in C++. I do like C++, a lot, given its capabilities. But also dislike the unsafety it inherited from C. However, I think one of the reasons C and C++ got so widespread is that 20 years ago, Java and .NET kind of killed all the other alternatives capable of produced standalone executables with optimizing compilers. At least from what mainstream developers are comfortable with. So when a average developer goes looking for a programming language able to deliver binaries without dependencies his/her only options are C and C++, which feeds the circle. I bet if Java, C# and VB.NET had gone the way of producing binaries like Delphi, Oberon and so on, the domain of C and C++ wouldn't be as it is nowadays. For example, if Ada compilers were cheaper or if Borland had improved Delphi's toolchain across multiple OS instead of going astray in multiple directions, any of those languages could be in C++'s place. Actually finance is one of the reasons why both Java and .NET are getting pure AOT compilation support nowadays. > Value types don't help quite as much as people think, value types only help avoid some unnecessary boxing/unboxing, relieving some pressure from the young generation and that's it. The problem is storing a lot of data in memory which will imply heap management and dealing with a big old generation, no matter what you do. Yet Mesa/Cedar, Oberon and Modula-3 were used successfully to build OSes that, in Oberon and Cedar's case, were used for quite a while as ETHZ and Xerox PARC workstations.
  - bad_user 11y ago
    I believe that the need of producing binaries without dependencies (I assume you mean a VM) isn't so widespread, quite the contrary, most developers want a VM underneath because then deployment becomes easier. The loud minority that has historically complained about the widespread usage of the VM have been just that, a minority. And it is funny, because things are progressing in that direction with C++ as well (speaking of LLVM or Emscripten). That is not and has never been the real difference between C++ and Java/.NET, but rather in having versus not having a GC. The main reason for why C++ still wins by a good amount in any benchmark is because for performance sensitive code memory access becomes by far the biggest bottleneck and in C++ there's simply more opportunity for optimizing memory access patterns. Delphi too lacked a GC. Java and .NET haven't killed Delphi, it is Borland that killed Delphi. This isn't a winner takes all kind of war (well, maybe it is in Windows land). We live in an industry in which multiple programming languages can coexist. For evidence of this you need to look no further than Linux, the Tower of Babel of our age. And I disagree with you - besides the open-source operating systems that are developed by multiple parties, all "OS vendors" are interested in the lock-in of developers. You're mixing cause and effect I think ... when an "OS vendor" adopts a programming language that isn't created by themselves, that's only because the programming language in question is already popular and here to stay.