31–40 of 96 posts
I have a personal rule, which I've shared on here before and people seem to think has some merit: If a project is innovative in a business sense, then choose a boring technology. If it is boring in a business sense, then choose an interesting technology.
I have a personal rule, which I've shared on here before and people seem to think has some merit: If a project is innovative in a business sense, then choose a boring technology. If it is boring in a business sense, then choose an interesting technology.
Can you flesh out the reasoning behind the rule?
I have a personal rule, which I've shared on here before and people seem to think has some merit: If a project is innovative in a business sense, then choose a boring technology. If it is boring in a business sense, then choose an interesting technology.
Other factors are familiarity and what tech the people who have to support it are familiar with. Language is in some ways a less important choice and is seldom a matter of choosing the 'best' one.
if you're talking about a side project though, knock yourself out. Personally I'd recommend looking at Typescript (web), C# (windows), Swift (apple) or Delphi (cross platform).
Personally I feel most comfortable in Python / Go / Java - while I have no problem kicking off a project in another language, those three just happen to hit the sweet spot for me for different use cases while not getting too much in my way. I assume we are talking about some side / hobby project, not starting new projects for a client? One thing I usually take into consideration is if there are libraries or framework…
Currently my picks are:
Rust -> to native + speedy Ruby -> nice relaxed scripting language Scala -> on a VM general purpose language
Though the difference is more blurred from original intent these days - it used to look like:
C Perl (5) Java / C#
which is considerably more pronounced.
The only addition I can make to this is I'd pick based on how I'm going to deploy too - Java is fairly difficult to deploy to desktops compared to Golang for example (for reasons like ensuring the correct JVM version is installed etc). Ruby is even higher on the difficulty to deploy scale, to the point where I probably wouldn't ship it to a customer non-dockerized (but if hosted internally, that's fine).
If you're starting a one man project, just take the one you're being the most productive in. If the project is a team effort, then it comes down to the team preferences or team members' willingness to change. From my experience, team adopting a completely new language isn't the big deal per se, more difficult is team dynamics, requirements/people changes, hiring new team members especially if your area can't provide…
I'm all for learning stuff, and if I'm working on a project that has no particular deadline (or a deadline that's far enough out that I can deal with frustrations of learning), by all means use new and shiny. But if I have a real goal and a deadline, I'm going to use something I already know in and out so I can spend my time making, not learning. If I get something to production and find that it's performance is horrendous, I can always come back and optimize (or rewrite) later, but it's better to get something out and see if it even works than to be fighting a new syntax or picking middleware.
It's more about frameworks than languages. You're already learning 2 languages a year. That's not so hard. The surrounding tech is the bigger investment.
I have a personal rule, which I've shared on here before and people seem to think has some merit: If a project is innovative in a business sense, then choose a boring technology. If it is boring in a business sense, then choose an interesting technology.
Ohh so you're the guy who's responsible for writing the BI data aggregator with React... ;)