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.
...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.
> 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.
All of these things existed long before Ruby on Rails gained in popularity. Unless the popularity of Rails, Python, PHP, and Javascript was all just collective insanity, dynamic languages do offer benefits in some circumstances over languages with stronger type guarantees. Certainly not in every situation, but enough that it doesn't make sense to dismiss them out of hand.
> Unless the popularity of Rails, Python, PHP, and Javascript was all just collective insanity, dynamic languages do offer benefits in some circumstances over languages with stronger type guarantees.
with strongly typed languages it's harder to perform exploratory coding. This drives a kind of backpressure on the design stage of development where it becomes more prudent to design your classes and interfaces before you start coding, because changing interfaces part way through development is a much larger undertaking than in, say, Javascript. On the other hand, strongly typed languages provide a lot of guarantees that have to be coded for in dynamic languages. This is why I prefer gradual typing - you get the best of both worlds.
> with strongly typed languages [...] it becomes more prudent to design your classes and interfaces before you start coding, because changing interfaces part way through development is a much larger undertaking
Quite the opposite. With strongly typed languages, it becomes safer to make changes, because the compiler will catch mistakes. On top of that, with mature strongly typed languages, there is tooling which takes advantage of the types to help you avoid mistakes in the first place.
It's safer to make changes, but you can't rapidly mess around with different structures without having to perform housekeeping on your types. This primarily applies to OO code, which is primarily where I draw my experience from - I find FP code is easier to refactor even with strong types because it doesn't enforce as rigid a structure.
I love the idea that typed languages create backpressure. I have very little confidence in peoples' ability to create well-designed (in software architecture terms) projects.
This is not true in general. There is nothing intrinsic to static types that is incompatible with exploratory coding. If you want to turn all your type errors into runtime crashes, then some statically typed languages will even let you do this (e.g. deferred type errors in Haskell).
Python is a strongly typed language and language dynamism has no relationship to strong typing. you're likely thinking of static typing. With Python's type annotation feature as well as the work being done with MyPy, Python is also beginning to grow some static typing behavior as well.
First of all, zzzeek, thanks for your great software. While working on SQLAlchemy, have you ever run into situations where you really missed static typing? Do you ever see yourself wanting to introduce Python's static typing behavior into that project, and why or why not?
I did nothing but Java from around 1998 to 2002 and then again around 2006-2008, and there is definitely a deep satisfaction when you have built your giant statically typed castle and compile it and then it runs the first time. In Java though, obviously the verbosity that implies, particularly when I was using it pre-generics, most certainly erased any productivity gains and made for code that was very difficult for new people to understand, tests were in particular extremely hard to write. So at least with Java's widely criticized model, it was sort of nice-ish but hard to say it was worth it.
What Python is doing with typing I think is going to be amazing though. Just not sure if I'll have time to embrace it fully within my own projects.
Unless the popularity of Rails, Python, PHP, and Javascript was all just collective insanity, dynamic languages do offer benefits in some circumstances over languages with stronger type guarantees.
The benefit they offer is fewer checks so you can deploy things faster.
It's the same benefit you can get if you take your car to a mechanic who doesn't bother to check the wheels are attached properly after they've changed the brake discs.
But one can add checks after the design/features settle; it's not all or nothing. Using the mechanic analogy, if you are requesting a custom car, the mechanic can shape the look and feel first, and then verify everything once you made up your mind.
Most CRUD (such as tracking applications) is just marshaling attributes around and about, not really doing much math on them. Forced type checks can be repetitive busy work and hogs screen real-estate.
>> 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.
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.
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.
Runtime speed, as an example of one of the few considerations when choosing a language that isn't related to code quality and maintainability.
I agree though that it's not relevant for nearly all web applications (and even for those where it is, it doesn't require that everything is done in a performant language)
Sure, but the choice of language is rarely a factor in this, barring very specialized subdomains where library support is limited to a few languages. There's very few web applications that couldn't have been written in virtually any modern language.
I think ideally they are the same, but doing a re-write isn't cost free - opportunity cost as you're not doing feature customers care about, new bugs being created, old bugs re-appearing etc etc.
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.
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).
No one said that one needs to use LINQ with C# all the time.
Likewise no one is using C++ with MI and 9 level deep hierarchies for game engines anymore.
C++ is one of my toolbox languages, which I know since C++ARM days, yet I am also open minded that it shouldn't be the only way.
I am old enough to remember when C, Modula-2, Basic and Turbo Pascal, AMOS were the "Unity" of MS-DOS/Amiga, because
for this kind of tasks there's nothing better than Assembly and everyone had a copy of Zen of Assembly Language.
Then the speech was updated to there's nothing better than C when compilers improved, and it took PS 2 with its C++ SDK to eventually force game devs to grudgingly accept C++.
Which now reigns on all things GPGPU, but it doesn't mean we should be happy with just one language.
And even though it is one of my favorite ones, I dislike the lack of modules (maybe C++23 with luck) and the copy-paste compatibility with C that endangers the software I use written with it, because on many teams static analyzers and guidelines are foreign words.
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.
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.
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.
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...
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:
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.
Immediately after that, it says: "That said, PRs are still welcome and maintenance is continued by the surrounding community."
> Which pretty much states that Glium is not a really long term viable solution at the moment.
Except what that post-mortem is _really_ saying is that OpenGL is not a long-term viable solution. The whole post-mortem is about the fact that OpenGL drivers are so buggy that you can't write portable code to target it.
"OpenGL drivers are so buggy that you can't write portable code to target it."
Sure, that's why generic non-platform specific OpenGL wrapper is a bad idea, unless you have an army of engineers to apply kludges and workarounds. I'm sorry the author had to find out this the hardest way. The quality of OpenGL drivers has always been like this.
One way of writing portable OpenGL is to look at what some popular game with open source is doing, and copy their approach, because the likelihood of a) the bugs that title triggered are mostly fixed and/or b) they managed to avoid the biggest potholes.
For the several dozen EA games I worked on, in C++, all operator overloading was banned. Too many fools play dumb tricks with operator overloading, so it was declared illegal. I don't miss it, as it is a fool's tool.
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.
> 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.
My initial comment may have been a bit uncharitable, and I'm sorry - I chose clear communication instead of overt politeness. I might not resemble the core audience of the language in any way :)
I based my response to the first page mentioning windows install:
My instinctive response was based on a pattern matching from trying to run various open source projects on Windows the past 20 years, and how the projects choose to communicate their install narrative. I.e. the "ciphers" I mentioned in my posting above.
"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)."
WIX toolset may be an option http://wixtoolset.org. Not having a Windows installer generally appears amateurish nowadays (I know a plain zip is just as good but that's what people do and is generally expected nowadays).
Even Latex which was an incredible mish-mash of various components you needed to... acquire, is now available through just clicking the installer:
https://www.latex-tutorial.com/installation/
"...Despite this, you won't find many languages with Windows support that is as good as Nim's."
You could mention msvc in the initial install page since you need it. There was a specific time when projects had good economic and technical reasons not to depend on Visual Studio on windows. Not so much anymore, since it's free for individuals.
Installer landing pages for languages which don't signal my "fragile-not-well-supported" sense:
The Ocaml Install page is on the edge, but, that is compensated by a pedigree of being well known and having credible industrial users (i.e. Jane street):
I know you are a small team and have other priorities than your web page... the installer and mentioning MSVC on the install page would go a long way in increasing the likelihood of at least trying the project for random people running Windows.
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++.
Because with small subset you get pretty and understandable code with reasonably fast build time.
Although STL implementations are getting closer today (regarding underlying speed), unless you plan to lock to particular implementation, even version, you'd better use subset ;)
Are you a quant? What do you use instead of C++? Python/cython? I’m not convinced C++11/17/20 cannot be used in quant but I am not in the business (i’d Love to though).
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.)
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...
I'm very interested in leaving the dev farms for something more interesting. I'm taking steps in that direction, but do you have any advice on how you escaped into scientific software dev?
Not OP, but worked in science before. What you want is not to work in science on software dev ;) Scientists usually write extremely ugly, messy code, just to make it working and finalize paper for publishing. Remember, their focus is paper not code nor properly workable program.
Things like testing, agile, tickets, code indentation, patterns - none of that you'll find there.
If you aim for serious environments like Wolfram Research or MathWorks, that could be different. If you aim for quantitative firms, usually you'll find there scientists writing prototype in mathematica/matlab/r/python (messy again) and devs who will re-write it in c/c++/java/asm.
Thanks for the suggestions! I hadn't thought about places like Wolfram Research or MathWorks. I'll keep my eye on those. I'm working on picking up more C++ since that seems to be what everything I'm interested in is using.
Keep in mind these are "conservative developers" - they work in C/C++ - meaning a preference towards C styled C++, a preference towards maintainability, and a preference away from the latest features of C++. That is being a developer, yet in a tech shop. There are lucrative alternatives too:
When one looks outside the traditional technology industries, there are a huge number of technology jobs as the tech person in a non-tech industry, being forced into the tech world. These tend to be C-Suite level jobs, so picking up an e-MBA is also be pretty good idea - to know how to talk and operate in their terms, how and why what you're doing for them is what you're paid to do. They have no idea, and very likely a history of being burned by low level tech consultants.
Thanks for the info. I'm kind of burned out on the shiny new things, so C and maintainability sound like a breath of fresh air. I think reading an OS paper from ~1983 that described what is effectively Kubernetes (with working prototype written in ML) really drove home how little the fundamentals of our industry change.
The way I describe my career goals now is: I want to work in a domain where quality and performance is the product.
I hadn't considered getting an MBA and using it in that way, that's something that I will take a hard look at. Thanks for the advice!
Great point. I used to use C++ a lot on Nintendo video games, government contracting, etc. I always used a subset. Three of my favorite current languages are Haskell, Common Lisp, Scala - and I use small subsets of those languages also. I think it makes sense to look at complex languages filtered by what your needs are and decide on a set of features you really need. For me, this makes my code easier for me to read and modify in the future.
It's widely noted that this "select what you want out of the language" works best if you're working by yourself or in a very small team, with no inclusion of third-party code, or no such code that doesn't conform to your restrictions.
It really is best if the language doesn't include the kitchen sink in the first place, if you want the code to be clean in the most general circumstances.
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...
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).
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.
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.
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.
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!
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.