9 ms·

I mean... Let's pause for a minute and remove the year, and remove the language / framework. What are we trying to accomplish? If we know something really well

I mean... Let's pause for a minute and remove the year, and remove the language / framework. What are we trying to accomplish? If we know something really well and there are enough developers to support an ecosystem and the talent pool in your <however you decide your region> is big enough just use whatever you want. PHP in 2018? SURE. C++ in 2018? SURE (You masochist) Rails in 2018? Youre damn right I would. GO in 2018? OK. Fine. Whatever. This is highly opinionated, but our jobs are to make stuff that works in a predictable, less risky way. Do that.

sircastor 8y ago
This was pretty much my response as well. If there are lots of people who can write it, and write it in such a way that it's maintainable, go with what you like most.
fsloth 8y ago
"C++ in 2018? SURE (You masochist)" I know this is tongue in cheek, but if one is doing anything related to real time graphics programming I'm not aware of any good alternatives.
- colordrops 8y ago
  WebGL? I do get that hardcore games are more suited to compiled code non garbage collected though.
  - fsloth 8y ago
    I suppose WebGL is okay for shader prototyping, for example using Shadertoy [0]. However, you can use it only within the context of a browser framework. That is still not the optimum deployment nor development platform for a variety of scenarios. The original joke though, was that C++ was for masochists. I'm not sure developing a web application is any less painfull... [0] https://www.shadertoy.com/ https://www.shadertoy.com/
    - pjmlp 8y ago
      I used to think like that specially given how poorly many demos run on mobile devices that don't have any issues dealing with ES 3.x games. However the demos one gets to see from production work at Siggraph are quite impressive when running on proper desktop cards.
- lloeki 8y ago
  > I'm not aware of any good alternatives. Vulkan/C? Metal/ObjC†/C? From C libs you can probably get to bindings to other languages like D, Haskell, Rust, Go†. † depending on your definition of "real time" (soft vs hard), both kernel-wise and GC-wise.
  - fsloth 8y ago
    "Vulkan/C? Metal/ObjC†/C? " Vulkan and C are a sane option. Although, with C and linear algebra one starts to miss C++ operator overloading and existing libraries like eigen [0] or glm[1] with their graphics and computational geometry targeting API:s really soon. If one deploys only to OS X/IOS, Metal and ObjC, sure. "From C libs you can probably get to bindings to other languages like D, Haskell, Rust, Go†." With the added complexity of the binding layer, and sub-par collection of existing examples and resources. With C++ both OpenGL and Vulkan have excellent didactic material, including: https://vulkan-tutorial.com/ https://vulkan-tutorial.com/ https://learnopengl.com/ https://learnopengl.com/ [0] http://eigen.tuxfamily.org/index.php?title=Main_Page http://eigen.tuxfamily.org/index.php?title=Main_Page [1] https://glm.g-truc.net/0.9.9/index.html https://glm.g-truc.net/0.9.9/index.html
    - wtetzner 8y ago
      For Rust, there's [1] for OpenGL and [2] for Vulkan. I don't know about Vulkano, but Glium is much more pleasant to use than the raw OpenGL API. [1] https://github.com/glium/glium https://github.com/glium/glium [2] https://github.com/vulkano-rs/vulkano https://github.com/vulkano-rs/vulkano
      - fsloth 8y ago
        The sentence in the top of the readme for the github repo is: "Glium is no longer actively developed by its original author." Which links to: https://users.rust-lang.org/t/glium-post-mortem/7063 https://users.rust-lang.org/t/glium-post-mortem/7063 Which pretty much states that Glium is not a really long term viable solution at the moment. I've toyed with cool open source libraries for 20 years. I'm too old to get caught up with something new and shiny only to find out it wasn't structurally sound. That is why C++ is a good choice. It has huge traction. The ecosystem is basically bullet proof. It has lot of practical libraries that are so well used that while not bullet proof themselves, it is likely they will stay alive as long as you need to compile your code.
- pjmlp 8y ago
  C# is slowly getting there thanks to Unity efforts with HPC# and Microsoft's improvements on SIMD support, stack allocation and slices. Then on the browser you are stuck with GLSL 3.0 shaders, or any JS library that generates them on the fly. But yeah for the layer that actually talks to the metal, it is still going to be C++ for many years, specially thanks to the ongoing language improvements since C++11 revision. Metal and DirectX shaders are C++ dialects, and Google is driving the effort of making HLSL having first class support on Vulkan as well. Oh, and NVidia has designed they latest GPGPUs specifically to run C++ code optimally.
  - golergka 8y ago
    I'm a fulltime Unity lead developer and I love C# as a business logic (or game logic) language, but it becomes quite ugly for hot code that is perfomance-critical. Once you get thousands of objects that you have to process every frame, you have to throw the usual C# object-oriented style and things like Linq (and I'm a fan of Linq!) out of the window and write code that reads like C. And when you get to object pools, well, that's practically the same thing as writing your own allocator (only instead of allocating arbitrary memory, you allocate objects). Seriously, for this kind of tasks there's nothing better than C/C++ - and I write this as someone who is actively AFRAID of power of C++ and uses less powerful tools whenever and wherever possible (because I don't want all that power to shoot in my own leg).
    - fsloth 8y ago
      "things like Linq" It's really easy to accidentally create a simple Linq query that underneath turns into O(N^2) and suddenly the production application crawls to a halt. Actually happened.
      - golergka 8y ago
        That's why you should know where to write code optimized for perfomance and where to write code optimized for readability. It's the latter 95% of the time.
- jdc 8y ago
  Depending on what libraries you need, Nim and D seem like decent alternatives.
  - fsloth 8y ago
    "Nim ... seem like decent alternatives." Note that I specified real time graphics development as the focus area here for C++. While I don't want to get into platform wars, on that front Windows is a really strong contender, for various ecological reasons. Nim does not seem to be well supported on windows [0]. The typical cyphers for poor windows support in open source projects, that seem to hold true for Nim, are that: a) No mention of MSVC support as a compiler option b) Installer does not install the complete required language runtime, and the end user must hunt the missing DLL:s by themselves. c) Need to manually configure various paths While these are not a technical blocks, they imply strongly that Windows support is not one of the key priorities for the project. "Here you go, have a nice language - and oops, good luck debugging our runtime". Whereas in industrial quality setups that have lot of users you can pretty much expect it to work out of the box. [0] https://nim-lang.org/install_windows.html https://nim-lang.org/install_windows.html
    - dom96 8y ago
      Wow. We really need to fix our install page if people are reaching this conclusion. Hey, Nim dev here. I can assure you that Windows is incredibly well supported by Nim. > a) No mention of MSVC support as a compiler option https://nim-lang.org/faq.html#how-do-i-use-a-different-c-compiler-than-the-default-one https://nim-lang.org/faq.html#how-do-i-use-a-different-c-com... > b) Installer does not install the complete required language runtime, and the end user must hunt the missing DLL:s by themselves. The DLLs are all included in the .zip file. Even if they weren't, you do not need to "hunt" them, there is a link for them at the bottom of the download page. > Need to manually configure various paths You don't. It's easy to think that when you only read the headings though :( Here is an excerpt from under the heading: > The zip file includes a simple application called finish.exe that can attempt to add the first directory into your PATH. This tool also checks for the presence of a C compiler and can install MingW, the GNU C compiler collection for Windows. The installation isn't perfect, we did have an installer in the past but it proved more trouble than it was worth (NSIS is very archaic and INNO is a PITA). Despite this, you won't find many languages with Windows support that is as good as Nim's.
- deleted 8y ago
  [deleted]
- eahman16 8y ago
  There's absolutely nothing wrong with C++ if you use a small subset of it, like for example Carmack did in Doom 3. The only problem that arises with C++ is when people want to use EVERYTHING in the language, because if it exists, it has to be in my project, right?
  - TimMurnaghan 8y ago
    If you're using a small subset why on earth is it the right language? I had the misfortune to try to mentor a new quant who felt they had to write C++ "for speed" . But refused to use the STL as they were going to use a subset. So they wrote Fortran-like C++, array as the only data structure, bad lookup algorithms and leaked like a sieve. Things are in the language for a reason - if you've got the issue then you use the feature. I hardly ever recommend C++ these days as it's not worth the slower dev time. There are a few cases where run-time really does trump everything else and it's still appropriate. In that case the code will be templated to within an inch of its life, because that's how to write real C++.
    - bsenftner 8y ago
      Let's just be honest: today's dev's can't write in C/C++ because they don't have the formal training. They are primarily script language devs who can't work at the low level required by C/C++. The formally educated programmers who were taught low level large-scale systems programming are too few to create the programmer farms you all work it (which I left for scientific software development, where the devs are older and we all work in C/C++ or assembly.)
      - ahartmetz 8y ago
        You don't need formal education to understand why some things are the way they are in C++, you need to understand how a CPU works. A small amount of assembly programming is sufficient for that - it is actually very simple to understand, just hard to write nontrivial programs...
      - atomic-hedge 8y ago
- Razengan 8y ago
  Swift or Objective-C with Metal, so far so good. Console-quality graphics on phones and tablets.
- tylerhou 8y ago
  I think he means "C++ in 2018" to build a standard webapp, which definitely is masochistic because you can be much more productive on e.g. Rails. Just like how using PHP to build a real-time graphics engine is also probably masochistic.
  - bsenftner 8y ago
    People who don't know say these things. Try writing web applications in C/C++, it's a deluxe development situation. Where do you think web browsers come from? Everyone afraid of C/C++ are shooting themselves in the feet.
    - criddell 8y ago
      When I started to learn Rails, the intro was a Twitter-like messaging app. Somebody that knows what they are doing could turn that out in an hour. Is the situation in C++ frameworks very far off?
      - bsenftner 8y ago
        The same. Using Restbed, a C++ embedded web server framework, a twitter messaging app is about an hour of work.
  - 52-6F-62 8y ago
    It's getting better. I've been starting to dig into Crow to see if it might be a worthwhile option as a C++ web app framework: https://github.com/ipkn/crow https://github.com/ipkn/crow https://github.com/jolks/crow-template https://github.com/jolks/crow-template (Relies on libboost https://www.boost.org/ https://www.boost.org/) Seriously, it makes putting together a simple API a breeze. I haven't had the chance to try anything more complex yet.
- esistgut 8y ago
  There is a growing Rust game development community [0] but of course C++ still has the edge. [0] https://www.reddit.com/r/rust_gamedev/ https://www.reddit.com/r/rust_gamedev/
- sjwright 8y ago
  Jai? (Obviously not yet a good alternative, but worth being aware of in case it perfectly suits your project...) https://inductive.no/jai/ https://inductive.no/jai/
  - fsloth 8y ago
    Any language with a FFI (i.e. ~all of them) can be used to interface with DLL:s with a C interface. That was really not the point...
- bsenftner 8y ago
  I write integrated servers with the web server, the database server, a video server, and a facial recognition application all bundled together in C++. The application screams: try 1/16th the memory footprint of a traditional multi-server Internet application, it is 4000% faster, and can run on a $100 Intel Compute Stick. Try this in any other language...
  - Jyaif 8y ago
    I'm doing the same thing, and I've got a couple questions: How do you handle redundancy, e.g. if your Intel Compute Stick goes offline for any reason? How do you handle crashes of your applications?
  - mwcampbell 8y ago
    What C++ web server library/framework do you use? Or did you roll your own? For the database, are you using SQLite or something else?
    - bsenftner 8y ago
      Restbed is the C++ framework, and yes, we use SQlite.
  - gm-conspiracy 8y ago
    Is this for an art installation or does it have a more business-oriented purpose?
    - bsenftner 8y ago
      Government contracts; software is used by covert agencies.
partycoder 8y ago
I think C++ has some pretty solid libraries. I particularly like gRPC and Thrift.
onion2k 8y ago
...our jobs are to make stuff that works in a predictable, less risky way. Do that. This is very true, but it doesn't mean "Use the thing that's worked in the past because that's less risky." Languages get better and tooling improves, and if you're still using one that isn't keeping up then you're increasing risk. These days if your chosen language doesn't have things like strong typing, interfaces, good debugging tools, a good compiler, etc, then you should definitely be asking yourself if it's the right tool for the job. You shouldn't jump from one language to another every few months, but you should keep a close eye on what other languages are doing and ask yourself if switching would improve the code you write.
- gadders 8y ago
  >> You shouldn't jump from one language to another every few months, but you should keep a close eye on what other languages are doing and ask yourself if switching would improve the code you write. Shouldn't that last sentence be "... if switching would improve the end product or service you are delivering." The focus should be on what people are paying you for. Better code doesn't always mean a better product, or be a smart business decision.
  - ryanbrunner 8y ago
    The two are equivalent in most cases. There's a relatively small set of problems where the choice of programming languages will have an effect on the product that doesn't come down to the code being more understandable and more amenable to change. Pretty much speed is the only concern for the vast majority of web applications, it isn't really that big a concern for most web applications, and even then it's less about choosing the fastest language and more about limiting yourself to a still pretty broad set of "faster" languages.
    - WillPostForFood 8y ago
      Speed of development, or runtime speed? Language won’t matter for runtime speed except in the .1% of high load apps. In my experience speed of development will vary quite a bit based on language and quality of frameworks. I went from C# shop to Ruby/Rails and the pace increased substantially, though cultural differences are intertwined with language choices.
SkyPuncher 8y ago
This is pretty much my thought. I lead a jumpstarted development effort for a startup last year (we used an agency to get through the initial build). We looked into several options, but ultimately decided to use Rails. Why? We all knew exactly what we could expect from Rails and we knew we could get it to work in the way we wanted without too much hassle. Sure, we might hit growth problems in years but we can cross that bridge down the road.
- aantix 8y ago
  I consulted on a site that could get 50 million unique users in any given month, sometimes with large bursts of traffic. A heavy read site is trivial to scale these days. Serve static assets from CDNs, fragment cache the views, horizontally scale when needed. Rinse, repeat.
  - sho 8y ago
    Exactly. I've also been involved with read-heavy Rails sites serving well in excess of 1000reqs/sec, and I know that others sites (Shopify et al) do way more. As you point out, it's all about having an intelligent caching strategy and extensive use of CDNs. Most scaling issues I've seen on well-designed Rails sites have been to do with the DB, not the framework!
gambiting 8y ago
>>C++ in 2018? SURE (You masochist) How exactly do you think AAA games are made? It's all C++ because there's literally nothing else out there which would give you the same performance(and also nothing that is supported as widely by Sony/MS/Nvidia/ATI).
- deleted 8y ago
  [deleted]
- Retric 8y ago
  AAA games tend to be C++ plus a range of other languages appropriate for specific tasks. It's like saying your Ruby while ignoring SQL and HTML/CSS/JavaScript which combined represent far more lines of code and development time.

sircastor 8y ago

This was pretty much my response as well. If there are lots of people who can write it, and write it in such a way that it's maintainable, go with what you like most.

fsloth 8y ago

"C++ in 2018? SURE (You masochist)" I know this is tongue in cheek, but if one is doing anything related to real time graphics programming I'm not aware of any good alternatives.

colordrops 8y ago
WebGL? I do get that hardcore games are more suited to compiled code non garbage collected though.
- fsloth 8y ago
  I suppose WebGL is okay for shader prototyping, for example using Shadertoy [0]. However, you can use it only within the context of a browser framework. That is still not the optimum deployment nor development platform for a variety of scenarios. The original joke though, was that C++ was for masochists. I'm not sure developing a web application is any less painfull... [0] https://www.shadertoy.com/ https://www.shadertoy.com/
  - pjmlp 8y ago
    I used to think like that specially given how poorly many demos run on mobile devices that don't have any issues dealing with ES 3.x games. However the demos one gets to see from production work at Siggraph are quite impressive when running on proper desktop cards.
lloeki 8y ago
> I'm not aware of any good alternatives. Vulkan/C? Metal/ObjC†/C? From C libs you can probably get to bindings to other languages like D, Haskell, Rust, Go†. † depending on your definition of "real time" (soft vs hard), both kernel-wise and GC-wise.
- fsloth 8y ago
  "Vulkan/C? Metal/ObjC†/C? " Vulkan and C are a sane option. Although, with C and linear algebra one starts to miss C++ operator overloading and existing libraries like eigen [0] or glm[1] with their graphics and computational geometry targeting API:s really soon. If one deploys only to OS X/IOS, Metal and ObjC, sure. "From C libs you can probably get to bindings to other languages like D, Haskell, Rust, Go†." With the added complexity of the binding layer, and sub-par collection of existing examples and resources. With C++ both OpenGL and Vulkan have excellent didactic material, including: https://vulkan-tutorial.com/ https://vulkan-tutorial.com/ https://learnopengl.com/ https://learnopengl.com/ [0] http://eigen.tuxfamily.org/index.php?title=Main_Page http://eigen.tuxfamily.org/index.php?title=Main_Page [1] https://glm.g-truc.net/0.9.9/index.html https://glm.g-truc.net/0.9.9/index.html
  - wtetzner 8y ago
    For Rust, there's [1] for OpenGL and [2] for Vulkan. I don't know about Vulkano, but Glium is much more pleasant to use than the raw OpenGL API. [1] https://github.com/glium/glium https://github.com/glium/glium [2] https://github.com/vulkano-rs/vulkano https://github.com/vulkano-rs/vulkano
    - fsloth 8y ago
      The sentence in the top of the readme for the github repo is: "Glium is no longer actively developed by its original author." Which links to: https://users.rust-lang.org/t/glium-post-mortem/7063 https://users.rust-lang.org/t/glium-post-mortem/7063 Which pretty much states that Glium is not a really long term viable solution at the moment. I've toyed with cool open source libraries for 20 years. I'm too old to get caught up with something new and shiny only to find out it wasn't structurally sound. That is why C++ is a good choice. It has huge traction. The ecosystem is basically bullet proof. It has lot of practical libraries that are so well used that while not bullet proof themselves, it is likely they will stay alive as long as you need to compile your code.
pjmlp 8y ago
C# is slowly getting there thanks to Unity efforts with HPC# and Microsoft's improvements on SIMD support, stack allocation and slices. Then on the browser you are stuck with GLSL 3.0 shaders, or any JS library that generates them on the fly. But yeah for the layer that actually talks to the metal, it is still going to be C++ for many years, specially thanks to the ongoing language improvements since C++11 revision. Metal and DirectX shaders are C++ dialects, and Google is driving the effort of making HLSL having first class support on Vulkan as well. Oh, and NVidia has designed they latest GPGPUs specifically to run C++ code optimally.
- golergka 8y ago
  I'm a fulltime Unity lead developer and I love C# as a business logic (or game logic) language, but it becomes quite ugly for hot code that is perfomance-critical. Once you get thousands of objects that you have to process every frame, you have to throw the usual C# object-oriented style and things like Linq (and I'm a fan of Linq!) out of the window and write code that reads like C. And when you get to object pools, well, that's practically the same thing as writing your own allocator (only instead of allocating arbitrary memory, you allocate objects). Seriously, for this kind of tasks there's nothing better than C/C++ - and I write this as someone who is actively AFRAID of power of C++ and uses less powerful tools whenever and wherever possible (because I don't want all that power to shoot in my own leg).
  - fsloth 8y ago
    "things like Linq" It's really easy to accidentally create a simple Linq query that underneath turns into O(N^2) and suddenly the production application crawls to a halt. Actually happened.
    - golergka 8y ago
      That's why you should know where to write code optimized for perfomance and where to write code optimized for readability. It's the latter 95% of the time.
jdc 8y ago
Depending on what libraries you need, Nim and D seem like decent alternatives.
- fsloth 8y ago
  "Nim ... seem like decent alternatives." Note that I specified real time graphics development as the focus area here for C++. While I don't want to get into platform wars, on that front Windows is a really strong contender, for various ecological reasons. Nim does not seem to be well supported on windows [0]. The typical cyphers for poor windows support in open source projects, that seem to hold true for Nim, are that: a) No mention of MSVC support as a compiler option b) Installer does not install the complete required language runtime, and the end user must hunt the missing DLL:s by themselves. c) Need to manually configure various paths While these are not a technical blocks, they imply strongly that Windows support is not one of the key priorities for the project. "Here you go, have a nice language - and oops, good luck debugging our runtime". Whereas in industrial quality setups that have lot of users you can pretty much expect it to work out of the box. [0] https://nim-lang.org/install_windows.html https://nim-lang.org/install_windows.html
  - dom96 8y ago
    Wow. We really need to fix our install page if people are reaching this conclusion. Hey, Nim dev here. I can assure you that Windows is incredibly well supported by Nim. > a) No mention of MSVC support as a compiler option https://nim-lang.org/faq.html#how-do-i-use-a-different-c-compiler-than-the-default-one https://nim-lang.org/faq.html#how-do-i-use-a-different-c-com... > b) Installer does not install the complete required language runtime, and the end user must hunt the missing DLL:s by themselves. The DLLs are all included in the .zip file. Even if they weren't, you do not need to "hunt" them, there is a link for them at the bottom of the download page. > Need to manually configure various paths You don't. It's easy to think that when you only read the headings though :( Here is an excerpt from under the heading: > The zip file includes a simple application called finish.exe that can attempt to add the first directory into your PATH. This tool also checks for the presence of a C compiler and can install MingW, the GNU C compiler collection for Windows. The installation isn't perfect, we did have an installer in the past but it proved more trouble than it was worth (NSIS is very archaic and INNO is a PITA). Despite this, you won't find many languages with Windows support that is as good as Nim's.
deleted 8y ago
[deleted]
eahman16 8y ago
There's absolutely nothing wrong with C++ if you use a small subset of it, like for example Carmack did in Doom 3. The only problem that arises with C++ is when people want to use EVERYTHING in the language, because if it exists, it has to be in my project, right?
- TimMurnaghan 8y ago
  If you're using a small subset why on earth is it the right language? I had the misfortune to try to mentor a new quant who felt they had to write C++ "for speed" . But refused to use the STL as they were going to use a subset. So they wrote Fortran-like C++, array as the only data structure, bad lookup algorithms and leaked like a sieve. Things are in the language for a reason - if you've got the issue then you use the feature. I hardly ever recommend C++ these days as it's not worth the slower dev time. There are a few cases where run-time really does trump everything else and it's still appropriate. In that case the code will be templated to within an inch of its life, because that's how to write real C++.
  - bsenftner 8y ago
    Let's just be honest: today's dev's can't write in C/C++ because they don't have the formal training. They are primarily script language devs who can't work at the low level required by C/C++. The formally educated programmers who were taught low level large-scale systems programming are too few to create the programmer farms you all work it (which I left for scientific software development, where the devs are older and we all work in C/C++ or assembly.)
    - ahartmetz 8y ago
      You don't need formal education to understand why some things are the way they are in C++, you need to understand how a CPU works. A small amount of assembly programming is sufficient for that - it is actually very simple to understand, just hard to write nontrivial programs...
    - atomic-hedge 8y ago
Razengan 8y ago
Swift or Objective-C with Metal, so far so good. Console-quality graphics on phones and tablets.
tylerhou 8y ago
I think he means "C++ in 2018" to build a standard webapp, which definitely is masochistic because you can be much more productive on e.g. Rails. Just like how using PHP to build a real-time graphics engine is also probably masochistic.
- bsenftner 8y ago
  People who don't know say these things. Try writing web applications in C/C++, it's a deluxe development situation. Where do you think web browsers come from? Everyone afraid of C/C++ are shooting themselves in the feet.
  - criddell 8y ago
    When I started to learn Rails, the intro was a Twitter-like messaging app. Somebody that knows what they are doing could turn that out in an hour. Is the situation in C++ frameworks very far off?
    - bsenftner 8y ago
      The same. Using Restbed, a C++ embedded web server framework, a twitter messaging app is about an hour of work.
- 52-6F-62 8y ago
  It's getting better. I've been starting to dig into Crow to see if it might be a worthwhile option as a C++ web app framework: https://github.com/ipkn/crow https://github.com/ipkn/crow https://github.com/jolks/crow-template https://github.com/jolks/crow-template (Relies on libboost https://www.boost.org/ https://www.boost.org/) Seriously, it makes putting together a simple API a breeze. I haven't had the chance to try anything more complex yet.
esistgut 8y ago
There is a growing Rust game development community [0] but of course C++ still has the edge. [0] https://www.reddit.com/r/rust_gamedev/ https://www.reddit.com/r/rust_gamedev/
sjwright 8y ago
Jai? (Obviously not yet a good alternative, but worth being aware of in case it perfectly suits your project...) https://inductive.no/jai/ https://inductive.no/jai/
- fsloth 8y ago
  Any language with a FFI (i.e. ~all of them) can be used to interface with DLL:s with a C interface. That was really not the point...
bsenftner 8y ago
I write integrated servers with the web server, the database server, a video server, and a facial recognition application all bundled together in C++. The application screams: try 1/16th the memory footprint of a traditional multi-server Internet application, it is 4000% faster, and can run on a $100 Intel Compute Stick. Try this in any other language...
- Jyaif 8y ago
  I'm doing the same thing, and I've got a couple questions: How do you handle redundancy, e.g. if your Intel Compute Stick goes offline for any reason? How do you handle crashes of your applications?
- mwcampbell 8y ago
  What C++ web server library/framework do you use? Or did you roll your own? For the database, are you using SQLite or something else?
  - bsenftner 8y ago
    Restbed is the C++ framework, and yes, we use SQlite.
- gm-conspiracy 8y ago
  Is this for an art installation or does it have a more business-oriented purpose?
  - bsenftner 8y ago
    Government contracts; software is used by covert agencies.

partycoder 8y ago

I think C++ has some pretty solid libraries. I particularly like gRPC and Thrift.

onion2k 8y ago

...our jobs are to make stuff that works in a predictable, less risky way. Do that. This is very true, but it doesn't mean "Use the thing that's worked in the past because that's less risky." Languages get better and tooling improves, and if you're still using one that isn't keeping up then you're increasing risk. These days if your chosen language doesn't have things like strong typing, interfaces, good debugging tools, a good compiler, etc, then you should definitely be asking yourself if it's the right tool for the job. You shouldn't jump from one language to another every few months, but you should keep a close eye on what other languages are doing and ask yourself if switching would improve the code you write.

gadders 8y ago
>> You shouldn't jump from one language to another every few months, but you should keep a close eye on what other languages are doing and ask yourself if switching would improve the code you write. Shouldn't that last sentence be "... if switching would improve the end product or service you are delivering." The focus should be on what people are paying you for. Better code doesn't always mean a better product, or be a smart business decision.
- ryanbrunner 8y ago
  The two are equivalent in most cases. There's a relatively small set of problems where the choice of programming languages will have an effect on the product that doesn't come down to the code being more understandable and more amenable to change. Pretty much speed is the only concern for the vast majority of web applications, it isn't really that big a concern for most web applications, and even then it's less about choosing the fastest language and more about limiting yourself to a still pretty broad set of "faster" languages.
  - WillPostForFood 8y ago
    Speed of development, or runtime speed? Language won’t matter for runtime speed except in the .1% of high load apps. In my experience speed of development will vary quite a bit based on language and quality of frameworks. I went from C# shop to Ruby/Rails and the pace increased substantially, though cultural differences are intertwined with language choices.

SkyPuncher 8y ago

This is pretty much my thought. I lead a jumpstarted development effort for a startup last year (we used an agency to get through the initial build). We looked into several options, but ultimately decided to use Rails. Why? We all knew exactly what we could expect from Rails and we knew we could get it to work in the way we wanted without too much hassle. Sure, we might hit growth problems in years but we can cross that bridge down the road.

aantix 8y ago
I consulted on a site that could get 50 million unique users in any given month, sometimes with large bursts of traffic. A heavy read site is trivial to scale these days. Serve static assets from CDNs, fragment cache the views, horizontally scale when needed. Rinse, repeat.
- sho 8y ago
  Exactly. I've also been involved with read-heavy Rails sites serving well in excess of 1000reqs/sec, and I know that others sites (Shopify et al) do way more. As you point out, it's all about having an intelligent caching strategy and extensive use of CDNs. Most scaling issues I've seen on well-designed Rails sites have been to do with the DB, not the framework!

gambiting 8y ago

>>C++ in 2018? SURE (You masochist) How exactly do you think AAA games are made? It's all C++ because there's literally nothing else out there which would give you the same performance(and also nothing that is supported as widely by Sony/MS/Nvidia/ATI).

deleted 8y ago
[deleted]
Retric 8y ago
AAA games tend to be C++ plus a range of other languages appropriate for specific tasks. It's like saying your Ruby while ignoring SQL and HTML/CSS/JavaScript which combined represent far more lines of code and development time.