6 ms·

After working for ~2.5 years on the web stack, I've spent the better part of the last year working purely in C++, and I can agree with the author's sentiment he

After working for ~2.5 years on the web stack, I've spent the better part of the last year working purely in C++, and I can agree with the author's sentiment here. Both languages have warts, but JS is a small enough language (at least in the ES5/ES5+Typescript world I was working in) that the warts felt finite. The first couple months were full of surprises, but after that I felt like I had a good grasp on the language, and knew when it was going to bite me. No such luck with C++, however. It still seems like there are several times per week where I'm surprised by some new way the language can screw me over, like non-virtual inheritance, or a newly discovered subtlety in the way includes are processed. Another benefit of JS - since the language is interpreted, build times tend to be much lower, and debugging tends to be much easier than C++. EDIT: Another benefit of JS - people like to give JS devs grief for all of the OSS frameworks they create, but in the C++ world every major company has built their own, in-house, closed-source implementations of the same shit. I'd love to know how many different implementations of a linked list in C++ exist in the wild today.

hliyan 11y ago
After 10 years with C++ and the past 2.5 years on JavaScript, I agree with you. JavaScript is to the web what C++ is to systems development. The introduction of Node.js and module systems did the trick for me.
andrepd 11y ago
>I'd love to know how many different implementations of a linked list in C++ exist in the wild today. Why isn't the STL linked list enough?
- AnimalMuppet 11y ago
  NIH syndrome. Some company thinks that they can do better than the STL, or that it doesn't meet their needs, or that they have a bunch of legacy code that was written before the STL and they have to maintain compatibility, or that they're a bunch of special snowflakes that deserve to have their own, or whatever. So they write their own, even though the STL is just fine.
- amyjess 11y ago
  Because a lot of C++ code predates the STL (or at least the STL being made available for whatever compiler they use).
- deleted 11y ago
  [deleted]
- bkjelden 11y ago
  A combination of code that predates the STL and a fear in taking a dependency on things you can't change. (Both should be irrelevant in a new code base, but most large C++ codebases are pretty old)
- ludamad 11y ago
  Sometimes intrusive linked lists are more efficient and require less cleanup
  - nly 11y ago
    With an intrusive linked list you pay the memory cost of having node pointers all the time. If you're you're going to do that, then you may as well keep all your nodes in a list all the time, and use splice() to move them around. There are practically no performance advantages to using intrusive linked-lists in this case.
    - comex 11y ago
      There is a usability advantage, though: with a STL list, you need an iterator corresponding to an element to move it between lists, not just a pointer to the value. So all functions taking a reference to an object, if they might want to move it around at some point, need to take an iterator, and in particular, object methods cannot do so, unless the class contains a wasteful iterator-to-self field. Intrusive lists also allow an object to be in multiple lists at the same time (usually ones with different purposes) by having multiple sets of prev/next pointers.
      - nly 11y ago
        Boost multi_index solves both of these problems. To simulate multiple lists you can simply add more than one sequenced index to the container type. The sequenced index interface provides an iterator_to() method which takes a reference and returns an iterator, and the container interface allows you to project one index to another. It's incredibly powerful. http://www.boost.org/doc/libs/1_58_0/libs/multi_index/doc/reference/seq_indices.html http://www.boost.org/doc/libs/1_58_0/libs/multi_index/doc/re... As a bonus the ownership semantics are clear and memory management remains trivial. Intrusive lists are useful, i'll grant you, but they'll always be a last resort for me. Especially if you're implementing them yourself.
blub 11y ago
Read some C++ literature like the C++ FAQ and you shouldn't be caught off guard any more, those pitfalls you mentioned are basic things. * there is no subtlety in the way includes work, they are simply merged into the file. * non-virtual inheritance is just normal inheritance. In case you meant non-virtual functions when using inheritance, that is also a very basic part of C++. As for the list, there's been a std::list for a very long time now. If your project is using custom lists then they either needed something very specific or are very very old. In that case, you should not criticize the language IMO. JS however can very well be lambasted, because new JS frameworks pop up often nowadays and they do exactly the same things in slightly different ways in 2015, not in 1997.
- deleted 11y ago
  [deleted]

hliyan 11y ago

After 10 years with C++ and the past 2.5 years on JavaScript, I agree with you. JavaScript is to the web what C++ is to systems development. The introduction of Node.js and module systems did the trick for me.

andrepd 11y ago

>I'd love to know how many different implementations of a linked list in C++ exist in the wild today. Why isn't the STL linked list enough?

AnimalMuppet 11y ago
NIH syndrome. Some company thinks that they can do better than the STL, or that it doesn't meet their needs, or that they have a bunch of legacy code that was written before the STL and they have to maintain compatibility, or that they're a bunch of special snowflakes that deserve to have their own, or whatever. So they write their own, even though the STL is just fine.
amyjess 11y ago
Because a lot of C++ code predates the STL (or at least the STL being made available for whatever compiler they use).
deleted 11y ago
[deleted]
bkjelden 11y ago
A combination of code that predates the STL and a fear in taking a dependency on things you can't change. (Both should be irrelevant in a new code base, but most large C++ codebases are pretty old)
ludamad 11y ago
Sometimes intrusive linked lists are more efficient and require less cleanup
- nly 11y ago
  With an intrusive linked list you pay the memory cost of having node pointers all the time. If you're you're going to do that, then you may as well keep all your nodes in a list all the time, and use splice() to move them around. There are practically no performance advantages to using intrusive linked-lists in this case.
  - comex 11y ago
    There is a usability advantage, though: with a STL list, you need an iterator corresponding to an element to move it between lists, not just a pointer to the value. So all functions taking a reference to an object, if they might want to move it around at some point, need to take an iterator, and in particular, object methods cannot do so, unless the class contains a wasteful iterator-to-self field. Intrusive lists also allow an object to be in multiple lists at the same time (usually ones with different purposes) by having multiple sets of prev/next pointers.
    - nly 11y ago
      Boost multi_index solves both of these problems. To simulate multiple lists you can simply add more than one sequenced index to the container type. The sequenced index interface provides an iterator_to() method which takes a reference and returns an iterator, and the container interface allows you to project one index to another. It's incredibly powerful. http://www.boost.org/doc/libs/1_58_0/libs/multi_index/doc/reference/seq_indices.html http://www.boost.org/doc/libs/1_58_0/libs/multi_index/doc/re... As a bonus the ownership semantics are clear and memory management remains trivial. Intrusive lists are useful, i'll grant you, but they'll always be a last resort for me. Especially if you're implementing them yourself.

blub 11y ago

Read some C++ literature like the C++ FAQ and you shouldn't be caught off guard any more, those pitfalls you mentioned are basic things. * there is no subtlety in the way includes work, they are simply merged into the file. * non-virtual inheritance is just normal inheritance. In case you meant non-virtual functions when using inheritance, that is also a very basic part of C++. As for the list, there's been a std::list for a very long time now. If your project is using custom lists then they either needed something very specific or are very very old. In that case, you should not criticize the language IMO. JS however can very well be lambasted, because new JS frameworks pop up often nowadays and they do exactly the same things in slightly different ways in 2015, not in 1997.

deleted 11y ago
[deleted]