6 ms·

I expect to see all the usual writeoffs of C++ here. And, to be sure, it's an easy language to criticize. But, for better or for worse, it's still the only reas

I expect to see all the usual writeoffs of C++ here. And, to be sure, it's an easy language to criticize. But, for better or for worse, it's still the only reasonable choice for a lot of very interesting application domains. And a lot of its less elegant features make more sense when you think carefully about the specific design goals for the language. I'd love to be able to write my DSP code in cleaner, simpler language but for now I'm happy that I have a tool that lets me build the software I care about.

minamea 14y ago
I think that's true, but it's also sad. I've looked at D and it's criticism seems reasonable to me: it actually seems to have more features than C++. I really hope Go catches on more and fixes some of the (imho) bad things about it (like lack of generic programming). And then C++ won't be the only option anymore.
- WalterBright 14y ago
  I don't really understand your post. You criticized D for having more features than C++, and Go for having fewer.
  - minamea 14y ago
    That's exactly how I feel, I guess. D seems to have a lot more features (import, public import, and static import?) and I'm no expert but I feel some aren't all that necessary/add enough value. Go has fewer than C++, which I think is really good, except for some few ones that I wish were there. Only generic programming/templates off the top of my head actually.
    - zura 14y ago
      And exceptions, or any other way to better handle error conditions, rather than that "if hell".
      - minamea 14y ago
        See I don't know about that. Maybe exceptions was one of the features that was good to be left out. I think maybe the comma ok idiom forces the programmer to more actively check for errors and recover from them, and there is no need to do things like RIIA. Maybe also the code is clearer to read, because you can see "if not ok then do_this()" and know that this is error checking/recovery code, instead of looking up the call stack to see where the exception that was thrown in one place is being handled.
      - jamesaguilar 14y ago
        I feel like panic/recover give me 90% of what I need from exceptions.
  - jamesaguilar 14y ago
    Go <what I want> C++ D
    - parbo 14y ago
      Have you tried Rust?
      - jamesaguilar 14y ago
        Read some code thanks to your comment. I think I will try it.
  - zura 14y ago
    If only D had Rust like reference counted embedded smart pointers... [for a deterministic memory management]. I think that would be much easy to add than C++esque `smart pointers as library`.
- dorolow 14y ago
  I haven't looked at D in a while, but I recall it having two competing standard libraries. I'm pinning all my hopes and dreams on Rust, but as a frequent (ab)user of Boost.Coroutine and gevent I certainly wouldn't mind if Go gained a bit more traction.
  - pcwalton 14y ago
    D doesn't have two competing libraries anymore. There's just one, Phobos. Regarding Rust, Rust has lightweight green threads just like Go does. (Go's scheduler is currently more mature though.)
    - dorolow 14y ago
      Regarding D, that's good! I always thought D was very cool, but the two libraries thing kept me away till now. Maybe I'll have to check it out again. It seems like Rust never ceases to impress.
- fauigerzigerk 14y ago
  Go is nice but it's a replacement for Java or Python not for C++. I'm working on an in-memory analytics engine, something that has only become affordable in recent years because memory prices have fallen so much. In-memory computing is a very important trend and garbage collected languages just don't work. You can't have the system stall for seconds or even tens of seconds unless it's purely a batch workload. I have to admit that I haven't really researched what can be done in Go to keep in-memory data off-heap so the garbage collector doesn't see it. I have done that research for Java and it's unworkable. It's either slow or extremely unproductive to work with or both.
  - minamea 14y ago
    Are garbage collection pauses really a concern? You're still running atop a multitasking operating system with all kinds of pauses.
    - fauigerzigerk 14y ago
      Garbage collection pauses are a huge concern with larger heap sizes. Depending on the application it may be OK to make a user wait for a second or two, but not for 30 seconds. Multitasking doesn't cause that kind of lag usually. It's even more problematic for some types of trading systems or stream processing of sensor data, etc. All the trends are working against garbage collection right now. Memory sizes are growing and we're moving away from batch processing for many workloads.
    - berkut 14y ago
      Most definitely - on a modern multitasking operating system your "all types of pauses" is generally only synchronous IO issues to disk or network - as long as you've got spare CPU available to your process/threads and you're sensible with your memory allocation.
  - derefr 14y ago
    > garbage collected languages just don't work. You can't have the system stall for seconds or even tens of seconds unless it's purely a batch workload. What about languages like Erlang and Rust where each actor/object/process has its own heap, GCed individually?
- zura 14y ago
  No language with a nondeterministic memory management will ever be able to be an alternative of C++.
  - Someone 14y ago
    There isn't anything nondeterministic about garbage collection systems; it is just that it is hard to predict how much time they will take for a call. However, the same can be said about classical C style memory management. An alloc can be almost immediate or take lots of time because it has to request a fresh memory block from the OS. Similarly, a free can or cannot take time to coalesce blocks. Yes, the differences are much smaller there, certainly historically, but garbage collectors have improved, and I am not sure that C-style allocators can stay predictable in long-running programs. Let's say you have a terabyte of RAM, and want to run a multi-threaded server in it 'forever'. Chances are that your garbage-collected system will be more stable and use less memory because it can compact memory. A C style allocator would need quite a few heuristics (or maybe, even contain some machine learning code that builds a model of memory allocation patterns) to prevent memory fragmentation. Such features would make their timing less predictable. Because of that, I think we may at some time see an OS with built-in garbage-collection become mainstream.
    - zura 14y ago
      > it is just that it is hard to predict how much time they will take for a call. The problem is not how much but when - you never know when GC fires and interrupts your running code. That is a nondeterminism.
      - Someone 14y ago
        If it interrupts your running code, it only can happen at moments when you allocate memory, just like with malloc. You cannot predict when malloc calls brk(), either. Also, most OS-es are non-deterministic, anyways. You cannot predict whether your code lives in cache/main memory, or on disk. In some systems, your data even might have to be brought in by a tape robot without your code being aware of it. As soon as a garbage collector manages to get its interruptions to be about equal to delays caused by caching and virtual memory, I doubt many people will care.
10098 14y ago
Yes, I also noticed that when it comes to the really interesting things, it's almost always either C or C++. Operating systems, DBMS'es, interpreters, game engines, browsers and lots of other stuff. Projects like webkit, v8, unreal engine are all frighteningly large pieces of high-quality performance-critical software written in C++. I think it really deserves more credit.
- girvo 14y ago
  Exactly. I'm a (web) developer, mainly working with dynamic scripting languages, and honestly for my "play" at home, C/C++ is what I'm forced to use to do interesting things. Although, I will say that Vala plus GTK+ is amazing for desktop development on Linux, especially with elementary OS's Granite library. The thing is, it's really just a nice language on top of C plus GObject as a transpiler! I do wish that some other languages were as nice to use as various scripting languages, but with the performance and pure utility of C/C++. Maybe one day.
- glurgh 14y ago
  They're both interesting and worth knowing something about but it's important not to conflate C and C++ - these are two languages that are probably more different than Python and Ruby are. Nor does merely writing in C or C++ guarantee performance - JRuby, for instance, often outperforms the standard ruby interpreter written in C.
  - aethr 14y ago
    Although with most JVMs being written in C, JRuby is still running on something that was built in C.
    - glurgh 14y ago
      Sure but that's true for almost all software. It's turtles/C[++] nearly all the way down, if you pick a particular way of looking at it. Besides, a modern JVM JIT does not emit C.
    - pjmlp 14y ago

minamea 14y ago

I think that's true, but it's also sad. I've looked at D and it's criticism seems reasonable to me: it actually seems to have more features than C++. I really hope Go catches on more and fixes some of the (imho) bad things about it (like lack of generic programming). And then C++ won't be the only option anymore.

WalterBright 14y ago
I don't really understand your post. You criticized D for having more features than C++, and Go for having fewer.
- minamea 14y ago
  That's exactly how I feel, I guess. D seems to have a lot more features (import, public import, and static import?) and I'm no expert but I feel some aren't all that necessary/add enough value. Go has fewer than C++, which I think is really good, except for some few ones that I wish were there. Only generic programming/templates off the top of my head actually.
  - zura 14y ago
    And exceptions, or any other way to better handle error conditions, rather than that "if hell".
    - minamea 14y ago
      See I don't know about that. Maybe exceptions was one of the features that was good to be left out. I think maybe the comma ok idiom forces the programmer to more actively check for errors and recover from them, and there is no need to do things like RIIA. Maybe also the code is clearer to read, because you can see "if not ok then do_this()" and know that this is error checking/recovery code, instead of looking up the call stack to see where the exception that was thrown in one place is being handled.
    - jamesaguilar 14y ago
      I feel like panic/recover give me 90% of what I need from exceptions.
- jamesaguilar 14y ago
  Go <what I want> C++ D
  - parbo 14y ago
    Have you tried Rust?
    - jamesaguilar 14y ago
      Read some code thanks to your comment. I think I will try it.
- zura 14y ago
  If only D had Rust like reference counted embedded smart pointers... [for a deterministic memory management]. I think that would be much easy to add than C++esque `smart pointers as library`.
dorolow 14y ago
I haven't looked at D in a while, but I recall it having two competing standard libraries. I'm pinning all my hopes and dreams on Rust, but as a frequent (ab)user of Boost.Coroutine and gevent I certainly wouldn't mind if Go gained a bit more traction.
- pcwalton 14y ago
  D doesn't have two competing libraries anymore. There's just one, Phobos. Regarding Rust, Rust has lightweight green threads just like Go does. (Go's scheduler is currently more mature though.)
  - dorolow 14y ago
    Regarding D, that's good! I always thought D was very cool, but the two libraries thing kept me away till now. Maybe I'll have to check it out again. It seems like Rust never ceases to impress.
fauigerzigerk 14y ago
Go is nice but it's a replacement for Java or Python not for C++. I'm working on an in-memory analytics engine, something that has only become affordable in recent years because memory prices have fallen so much. In-memory computing is a very important trend and garbage collected languages just don't work. You can't have the system stall for seconds or even tens of seconds unless it's purely a batch workload. I have to admit that I haven't really researched what can be done in Go to keep in-memory data off-heap so the garbage collector doesn't see it. I have done that research for Java and it's unworkable. It's either slow or extremely unproductive to work with or both.
- minamea 14y ago
  Are garbage collection pauses really a concern? You're still running atop a multitasking operating system with all kinds of pauses.
  - fauigerzigerk 14y ago
    Garbage collection pauses are a huge concern with larger heap sizes. Depending on the application it may be OK to make a user wait for a second or two, but not for 30 seconds. Multitasking doesn't cause that kind of lag usually. It's even more problematic for some types of trading systems or stream processing of sensor data, etc. All the trends are working against garbage collection right now. Memory sizes are growing and we're moving away from batch processing for many workloads.
  - berkut 14y ago
    Most definitely - on a modern multitasking operating system your "all types of pauses" is generally only synchronous IO issues to disk or network - as long as you've got spare CPU available to your process/threads and you're sensible with your memory allocation.
- derefr 14y ago
  > garbage collected languages just don't work. You can't have the system stall for seconds or even tens of seconds unless it's purely a batch workload. What about languages like Erlang and Rust where each actor/object/process has its own heap, GCed individually?
zura 14y ago
No language with a nondeterministic memory management will ever be able to be an alternative of C++.
- Someone 14y ago
  There isn't anything nondeterministic about garbage collection systems; it is just that it is hard to predict how much time they will take for a call. However, the same can be said about classical C style memory management. An alloc can be almost immediate or take lots of time because it has to request a fresh memory block from the OS. Similarly, a free can or cannot take time to coalesce blocks. Yes, the differences are much smaller there, certainly historically, but garbage collectors have improved, and I am not sure that C-style allocators can stay predictable in long-running programs. Let's say you have a terabyte of RAM, and want to run a multi-threaded server in it 'forever'. Chances are that your garbage-collected system will be more stable and use less memory because it can compact memory. A C style allocator would need quite a few heuristics (or maybe, even contain some machine learning code that builds a model of memory allocation patterns) to prevent memory fragmentation. Such features would make their timing less predictable. Because of that, I think we may at some time see an OS with built-in garbage-collection become mainstream.
  - zura 14y ago
    > it is just that it is hard to predict how much time they will take for a call. The problem is not how much but when - you never know when GC fires and interrupts your running code. That is a nondeterminism.
    - Someone 14y ago
      If it interrupts your running code, it only can happen at moments when you allocate memory, just like with malloc. You cannot predict when malloc calls brk(), either. Also, most OS-es are non-deterministic, anyways. You cannot predict whether your code lives in cache/main memory, or on disk. In some systems, your data even might have to be brought in by a tape robot without your code being aware of it. As soon as a garbage collector manages to get its interruptions to be about equal to delays caused by caching and virtual memory, I doubt many people will care.

10098 14y ago

Yes, I also noticed that when it comes to the really interesting things, it's almost always either C or C++. Operating systems, DBMS'es, interpreters, game engines, browsers and lots of other stuff. Projects like webkit, v8, unreal engine are all frighteningly large pieces of high-quality performance-critical software written in C++. I think it really deserves more credit.

girvo 14y ago
Exactly. I'm a (web) developer, mainly working with dynamic scripting languages, and honestly for my "play" at home, C/C++ is what I'm forced to use to do interesting things. Although, I will say that Vala plus GTK+ is amazing for desktop development on Linux, especially with elementary OS's Granite library. The thing is, it's really just a nice language on top of C plus GObject as a transpiler! I do wish that some other languages were as nice to use as various scripting languages, but with the performance and pure utility of C/C++. Maybe one day.
glurgh 14y ago
They're both interesting and worth knowing something about but it's important not to conflate C and C++ - these are two languages that are probably more different than Python and Ruby are. Nor does merely writing in C or C++ guarantee performance - JRuby, for instance, often outperforms the standard ruby interpreter written in C.
- aethr 14y ago
  Although with most JVMs being written in C, JRuby is still running on something that was built in C.
  - glurgh 14y ago
    Sure but that's true for almost all software. It's turtles/C[++] nearly all the way down, if you pick a particular way of looking at it. Besides, a modern JVM JIT does not emit C.
  - pjmlp 14y ago