9 ms·

I think a lot of people are looking for a replacement for C++ that isn't C#/Java. As in a language that is still low-level enough to offer stuff like pointers,

I think a lot of people are looking for a replacement for C++ that isn't C#/Java. As in a language that is still low-level enough to offer stuff like pointers, but without the pitfalls and minefield which is C++ (a lot of which is due to historic reasons and backwards compatibility with C). Some newer languages that try to fill the niche are D, Nim, Rust and Go. Can't say much about Nim, it seems to be in the background. Go started as a systems programming language, but since then they backed out on it and it's mostly pushed as nicer C and webservice language. That leaves D and Rust on the field. Both are competing for the same audience, but Rust has the advantage of a popular brand backing (Mozilla) and a potential killer app (Servo, Mozilla's new work in progress browser engine). It also seems to have a clearer vision because of Mozilla backing and constant dogfooding in Servo. Meanwhile D is more of a design by community, as a result it gets not always the features that are needed or people want, but the features people are willing to work on. Also, D gets a lot of backlash from the game dev and system programming languages communities for using a (not too great) garbage collector, whereas Rust uses memory management somewhat similar to C++ model with RAII/smart pointers, however greatly improved and with much stronger static checks. I think people just view Rust as the language that could actually be the alternative to C++, because there is a place for a language that is safer to use than C++, yet performs at similar speeds and doesn't handhold you like C#/Java do.

gjm11 11y ago
> Some newer languages that try to fill the niche are D, Nim, Rust and Go. Can't say much about Nim, it seems to be in the background. Nim is frustrating, because to my taste it gets so many things just right while getting one particular thing so spectacularly wrong that I can't bring myself even to try it. The one thing is its rule for when two identifiers are the same. They are compared case-insensitively, ignoring any underscores and en-dashes in either name, except that the first character must match exactly. Consequence #1: if you have, say, something called user_sort (perhaps it's a function that sorts users) and something called use_RSort (perhaps it selects which of two sorting algorithms to use somewhere) then they will be the same identifier, with results anywhere from compilation failure to silent malfunction you don't notice until a year later. Consequence #2: if you want to search for an identifier using some obscure tool like, say, grep or Vim or Eclipse, you're out of luck. (You can make your own tool -- call it "nimgrep", perhaps -- and extensible things like Vim and Eclipse can be given the ability to search for Nim identifiers. But their built-in facilities, like what "*" does in Vim, will do the wrong thing if you are working on Nim code.)
- nyan4 11y ago
  This criticism usually comes from people that do not use Nim. I was very surprised as well at first - now after 1 year of using Nim I realize I never run into any trouble because of case/underscore insensitivity. #1: those variables have to be in the same scope or be procs working on the same types to be an issue. #2: I don't use nimgrep, I just keep a consistent style across my files. When reading somebody else's code, case-insensitive search is usually enough.
  - gjm11 11y ago
    I suspect this criticism usually comes from people who don't use Nim because anyone inclined to be bothered by it will not use Nim for that reason. I agree that "just keep a consistent style" is a good approach for single-person projects. It's harder to keep it working well as you get more people working on the code, though.
    - progman 11y ago
      Actually Nim's attitude is more suitable for group work because every group can have its own style of coding. A simple transformer could be used to normalize the code. However it would force the developers to qualify all imported conflicting names which is a good idea anyway. You cannot do this in C++ and Rust. There you actually have to keep a consistent style.
- pif 11y ago
  Thanks a lot! I had never heard of Nim before, and I'll never ever try to know more. Such a gigantic error is a triple NO.
  - progman 11y ago
    Thirty years of C obviously has fixed the mindset of many developers so much that they don't even want to think in different ways :-(
    - 11y ago
pjmlp 11y ago
I have done my share of critics regarding Go team decisions, but one thing they got right is that Go is indeed a systems programming language. My understanding being that a systems programming language is one that can be used to bootstrap itself and build a full OS stack with the exception of some Assembly for interfacing with the underlying hardware. As of Go 1.6, the language certainly fulfils this description. If having a GC hinders certain use cases in systems programming, that is an orthogonal issue. Edit: Looking forward to the day someone bothers to write an Oberon like OS in Go and HNers will keep on downvoting those that favour memory safe systems programming languages.
- johncolanduoni 11y ago
  From the Clive design paper[1]: At this moment, the kernel used is a BSD kernel, but we are working now on making Go run on the bare hardware and on hypervisors. When that is done, the BSD kernels will be replaced with our own one. So if that is enough to be a systems programming language, then C# is also one on account of the Singularity OS[2]. [1]: http://lsub.org/export/clivesys.pdf http://lsub.org/export/clivesys.pdf [2]: https://en.wikipedia.org/wiki/Singularity_(operating_system) https://en.wikipedia.org/wiki/Singularity_(operating_system)
  - pjmlp 11y ago
    I can be made to be one, one still needs to remember Singularity and Midori aren't using pure C#, they have extended the language. Namely Sing# and System C# respectively. Both projects influenced the design of native .NET on Windows Phone 8, followed by .NET Native, IILC and CoreRT. Also many of the C# extensions on Midori are being explored for C# 7 and future versions. C# when compiled to native code is not much different than using Modula-3, in terms of available features. It just needs a little more fine tuning in terms of features.
- vvanders 11y ago
  Last I checked Go doesn't have any memory placement semantics. That's a non-starter IMO for a systems programming language. I like performance in my systems programming languages and you won't get that if you can't control where your memory lives.
pmelendez 11y ago
> because there is a place for a language that is safer to use than C++, yet performs at similar speeds and doesn't handhold you like C#/Java do. And sometimes some people (like me) would argue that C++ (11&14) is actually that language. A subset of C++ is actually very perfomant and safe for most of the uses.
- Sean1708 11y ago
  Which is absolutely fine, but competition is never a bad thing.
- UK-AL 11y ago
  People want C++ without the overwhelming choice it gives you.
- Manishearth 11y ago
  Note that it isn't 100% memory safe, it doesn't protect against iterator invalidation (which is a pretty common way in which memory unsafety springs up). But it can be close enough.
  - pjmlp 11y ago
    Still I have come to like it quite much. Yes we cannot get rid of the C underpinnings, but there are enough features to write safe C++. At least when using it alone or in small teams that value safety. I have been using it in anger on my side projects for mobile s. Why use it in spite of my rants about safety? Tooling. Using C++ across Android and Windows Phone is already an extra layer of pain (thanks NDK) with first class support from the platform owners. Using Go, Swift, Rust would increase that pain level quite higher given the actual lack of comparable tooling. Meaning build scripts, IDE, debugging tools, packaging and APIs. C# doesn't suffer as much from it thanks to Xamarin, but I would only use it in commercial projects. I really would wish that one of those languages would eventually be adopted across mobile OS SDKs as C and C++ currently are. Already had a look at Rust for Windows Phone, but COM support is not yet there to the level expected by WinRT as C++/CX allows. Assuming I was looking at the right place.
jaxondu 11y ago
> Some newer languages that try to fill the niche are D, Nim, Rust and Go. I always thought Go is less suitable as C++ replacement due to its GC. Another candidate which could be a dark horse is Swift.

gjm11 11y ago

> Some newer languages that try to fill the niche are D, Nim, Rust and Go. Can't say much about Nim, it seems to be in the background. Nim is frustrating, because to my taste it gets so many things just right while getting one particular thing so spectacularly wrong that I can't bring myself even to try it. The one thing is its rule for when two identifiers are the same. They are compared case-insensitively, ignoring any underscores and en-dashes in either name, except that the first character must match exactly. Consequence #1: if you have, say, something called user_sort (perhaps it's a function that sorts users) and something called use_RSort (perhaps it selects which of two sorting algorithms to use somewhere) then they will be the same identifier, with results anywhere from compilation failure to silent malfunction you don't notice until a year later. Consequence #2: if you want to search for an identifier using some obscure tool like, say, grep or Vim or Eclipse, you're out of luck. (You can make your own tool -- call it "nimgrep", perhaps -- and extensible things like Vim and Eclipse can be given the ability to search for Nim identifiers. But their built-in facilities, like what "*" does in Vim, will do the wrong thing if you are working on Nim code.)

nyan4 11y ago
This criticism usually comes from people that do not use Nim. I was very surprised as well at first - now after 1 year of using Nim I realize I never run into any trouble because of case/underscore insensitivity. #1: those variables have to be in the same scope or be procs working on the same types to be an issue. #2: I don't use nimgrep, I just keep a consistent style across my files. When reading somebody else's code, case-insensitive search is usually enough.
- gjm11 11y ago
  I suspect this criticism usually comes from people who don't use Nim because anyone inclined to be bothered by it will not use Nim for that reason. I agree that "just keep a consistent style" is a good approach for single-person projects. It's harder to keep it working well as you get more people working on the code, though.
  - progman 11y ago
    Actually Nim's attitude is more suitable for group work because every group can have its own style of coding. A simple transformer could be used to normalize the code. However it would force the developers to qualify all imported conflicting names which is a good idea anyway. You cannot do this in C++ and Rust. There you actually have to keep a consistent style.
pif 11y ago
Thanks a lot! I had never heard of Nim before, and I'll never ever try to know more. Such a gigantic error is a triple NO.
- progman 11y ago
  Thirty years of C obviously has fixed the mindset of many developers so much that they don't even want to think in different ways :-(
  - 11y ago

pjmlp 11y ago

I have done my share of critics regarding Go team decisions, but one thing they got right is that Go is indeed a systems programming language. My understanding being that a systems programming language is one that can be used to bootstrap itself and build a full OS stack with the exception of some Assembly for interfacing with the underlying hardware. As of Go 1.6, the language certainly fulfils this description. If having a GC hinders certain use cases in systems programming, that is an orthogonal issue. Edit: Looking forward to the day someone bothers to write an Oberon like OS in Go and HNers will keep on downvoting those that favour memory safe systems programming languages.

johncolanduoni 11y ago
From the Clive design paper[1]: At this moment, the kernel used is a BSD kernel, but we are working now on making Go run on the bare hardware and on hypervisors. When that is done, the BSD kernels will be replaced with our own one. So if that is enough to be a systems programming language, then C# is also one on account of the Singularity OS[2]. [1]: http://lsub.org/export/clivesys.pdf http://lsub.org/export/clivesys.pdf [2]: https://en.wikipedia.org/wiki/Singularity_(operating_system) https://en.wikipedia.org/wiki/Singularity_(operating_system)
- pjmlp 11y ago
  I can be made to be one, one still needs to remember Singularity and Midori aren't using pure C#, they have extended the language. Namely Sing# and System C# respectively. Both projects influenced the design of native .NET on Windows Phone 8, followed by .NET Native, IILC and CoreRT. Also many of the C# extensions on Midori are being explored for C# 7 and future versions. C# when compiled to native code is not much different than using Modula-3, in terms of available features. It just needs a little more fine tuning in terms of features.
vvanders 11y ago
Last I checked Go doesn't have any memory placement semantics. That's a non-starter IMO for a systems programming language. I like performance in my systems programming languages and you won't get that if you can't control where your memory lives.

pmelendez 11y ago

> because there is a place for a language that is safer to use than C++, yet performs at similar speeds and doesn't handhold you like C#/Java do. And sometimes some people (like me) would argue that C++ (11&14) is actually that language. A subset of C++ is actually very perfomant and safe for most of the uses.

Sean1708 11y ago
Which is absolutely fine, but competition is never a bad thing.
UK-AL 11y ago
People want C++ without the overwhelming choice it gives you.
Manishearth 11y ago
Note that it isn't 100% memory safe, it doesn't protect against iterator invalidation (which is a pretty common way in which memory unsafety springs up). But it can be close enough.
- pjmlp 11y ago
  Still I have come to like it quite much. Yes we cannot get rid of the C underpinnings, but there are enough features to write safe C++. At least when using it alone or in small teams that value safety. I have been using it in anger on my side projects for mobile s. Why use it in spite of my rants about safety? Tooling. Using C++ across Android and Windows Phone is already an extra layer of pain (thanks NDK) with first class support from the platform owners. Using Go, Swift, Rust would increase that pain level quite higher given the actual lack of comparable tooling. Meaning build scripts, IDE, debugging tools, packaging and APIs. C# doesn't suffer as much from it thanks to Xamarin, but I would only use it in commercial projects. I really would wish that one of those languages would eventually be adopted across mobile OS SDKs as C and C++ currently are. Already had a look at Rust for Windows Phone, but COM support is not yet there to the level expected by WinRT as C++/CX allows. Assuming I was looking at the right place.

jaxondu 11y ago

> Some newer languages that try to fill the niche are D, Nim, Rust and Go. I always thought Go is less suitable as C++ replacement due to its GC. Another candidate which could be a dark horse is Swift.