Does programming language matter?
This is a question I want to dive into more in a long form blog post. I've been thinking more and more about the arguments for choosing a programming language in early stage SASS and start ups. Does the programming language actually matter?
Background
Let's approach this from the perspective of starting a new SASS, as an Indie Hacker. You have full control of the tech stack and get to choose what you want.
Yes, It Does Matter
Some of the arguments I can see for why a language does matter are:
- Dev market size. If you look to eventually hire, this might be something to take into consideration. If you choose a niche language, you might not have the choice to hire high quality devs.
- Industry. Some industries are dominated by a certain language or you are forced to use a language (Can't write a native iOS app in Python). So you might not have a choice.
- Support. Goes along with Dev market size. If you choose a bleeding edge, or dying language you might not have support. However, if you need to scale and operate on the fringes, better to be prepared with a language that can scale.
No, Just Build the SASS
Reasons you could say it doesn't really matter:
- The end user doesn't care. A high quality app can be built with any language and at the end of the day it's the functionality the users are looking for.
- If you know a language and are comfortable in the ecosystem, the hardest part is getting started. Just start coding.
- If you're app takes off and you get to a point of mass scalability, hire someone to handle the hard parts.
I know this can be controversial and people have strong opinions, so please be nice :) I'd really like to see the blind spots in my thinking. Any comments are much appreciated! I'm looking to expand on this topic to help aspiring founders figure out first steps and learn myself.
One thing you didn't mention is choice of database. From my experience the code comes and goes, but what really counts is the data.
I often see a lot of junior Devs here reach for a particular stack just because the acronym of their stack dictates it.
I think when you go about designing your SaaS product you should be considering the interface and not the tech. I think taking an API-first approach is best. If you go "contract first" with your design and spec out your system using a RESTful HTTP web API service with Open API spec, then your front end is decoupled from the backend completely.
By Dockerizing your app you then house all your code inside a running container image and the service become language/platform agnostic. Of course you'll still suffer from the issues you mentioned, such as maintenance of code, hiring and so forth but you'll be free to reimplement your container backend anytime if you change stack.
Depending on the size of your team you could just dictate that all services, whether internal or external be consumed in this manner. This is what Bezos did with AWS before it was even made public.
Amazing perspective! I always believed in the API - First approach, but I love your focus on the data. I appreciated the approach solely because of the standards of communicating with the data set through a set of rules. However, you are 100% right that I could even swap that out with another language without affecting the frontend at all. We use docker exclusively so I can totally appreciate the disposable and repeatable aspects.
As for the other issues, I guess I should clarify more to how much weight you should put on a stack just getting started? Like you said though, and I agree, is if you set up a solid dev environment and standardized communication between components, you can swap out or fix at any time. Just finding that balance of not over-engineering to get the app off the ground.
Thanks again for the feedback, I really appreciate it!
I did dodge the programming language aspect. Even if you adopt the containerization approach the issue of language does still remain.
I think the answer is... as always... it depends. I think you would choose a stack based on the product you're building. For example, if your product is heavy frontend then you're likely going to be using mostly JavaScript-family languages either Js/Ts. In that case you might opt for choosing Node.js on the backend because you'll have less context switching (assuming that your developers can work both sides of the APi interface - knowing Js doesn't necessarily mean you know Node.js the platform).
However, I personally prefer compiled strong typed languages so I would opt for Go and a traditional relational database PostgreSQL. I find deploying it is quicker and easier because you end up with a single binary to deal with that you can chuck inside a small scratch or Alpine Linux container. Go binaries have a super fast start time compared to Node.js so that results in lower cold-start latency.
For me personally, I believe in getting it right rather than lashing together any old thing to show to the end user. I come from a software engineering background so cutting corners to "get something up" is like asking a singer to sing out of tune - it just can't be done. I've found that whatever gain you get by shortcutting the build is usually just a debt further into the project.
Of course some devs just write "something up quick" glue it all together with a bunch of cloud functions and throw it up. It's not really "wrong", but I just can't do it. I like things to be correct and thought out a bit.
I definitely agree that it depends on the use case and complexity of the product. Whether you are integrating with hardware and don't want to switch languages, to making a functional web app where most languages would suffice. I think just being a solo dev, it matters more on what you can write efficiently, effectively, clean and maintainable. In a team, it'd really go towards what the team is more comfortable with as a whole and working with the strengths and weaknesses.
As for getting it right instead of cutting corners, I couldn't agree more. I think the slightly extra time to document, indent, follow conventions and
really do quality work pay off no matter what you are doing. The analogy of singing out of tune is perfect. Granted, I'm not a dev perfect myself, but I strive as much as I can to at least follow conventions and write clean code.
I think to get your feet wet in product development, if you know a language, any language, jump in. There's a ton of distraction with frameworks, tooling, libraries, packages, etc. that stop people dead in their tracks. If you are just learning to code, make the app in whatever you want. The concepts you will pick up along the way, the proper development practices, etc. will allow you to make the decision that's right for your app.
If you are a seasoned product dev and have worked with a variety of languages and tools, you probably won't have much problem picking up a new tool and getting started without spending much time learning. Kind of like what you mentioned with everything being thought out and correct.
I guess I'm just trying to think of the best advice to give to someone who has an idea to make an app, knows a programming language and is overwhelmed.
Bingo!
Your name is very apt and reflects your viewpoint exactly, and I agree with it.
Data is king, and if your app is going to be data heavy, it's a good general rule of thumb to build back to front.
In the end, front end should not know (much less care) what language or DB stack is being utilized on the backend.
As long as a good contractual agreement and interface has been put in place, it simply doesn't matter.
That said, if you're working on SaaS app bootstrapping as a solo developer, I generally always recommend you get familiar with JavaScript and it's ecosystem as there are no real alternatives on the front end.
Is being "platform agnostic" that big of an advantage nowadays? In most cases you have access to both the local environment and servers, so you can choose your platform. The cross-platform benefit is usually promoted for end-user applications, not services.
Within the container I meant "platform" from the perspective of the code base. For example, JavaScript the language running on the Node.js platform (runtime). "platform" in that context is the language/platform on which the implementation is based.
From outside the container "platform" might mean the infrastructure itself.
I'm not sure which of those contexts you are viewing it from?
My vote: Just get it built using what you know and you’re comfortable with.
The biggest risk to any project is a lack of traction. Focus the energy on getting traction and not on which tech stack to use.
If it takes off, great! You can re-configure later. If not, it won’t be because of the stack you chose.
I generally agree with this, especially as an indie dev. For the most part, gaining traction, validating the idea, getting users as efficiently as possible is the most valuable. Refactoring and low level features can come as needed.
However, there have been some responses in this thread that do make me think that some consideration on what you want to accomplish might make a difference. Love seeing all the insight!
It matters, just usually not for client.
But if you and your team will work on your product, you want to choose technology you will fell comfortable to work with.
Making startup successful is hard enough. Don't make coding painful.
Team considerations and efficiency are a huge consideration. Totally agree with making a startup is hard enough. There's so much more than development that goes into an app. Making development complicated and inefficient would just be miserable.
One thing you can add to why language matters is the actual functionality
Some years ago i did an application in php with had to use tcp ports heavily and it was not fun to maintain that code as it was full of hacks to make it work
So if your application works with some low level stuff then the language matters
The kind of scenarios when dealing with lower level code is where this topic gets super interesting. It's been a long time since I've done anything that required heavy use of a lower level integration that's not super common. However, once you start getting down there, tools and libraries for "higher" level languages might not be as common. Let alone support for the systems.
I guess when you are examining an app that starts to get down there, you are generally a more seasoned dev and can choose the language that makes the most sense.
Start with the technology which is the easiest and the cheapest for you.
Users care, of course. So be smart here.
For example, if you build a mobile app, go for native code. Unfortunately, Javascript apps may not be as good as native.
If you build a website, pick the technology known by many programmers.
"Users care, of course. So be smart here" -> I love it. I'm primarily a web/mobile app dev and this is one of the areas that prompted this thought and why I posted this. I generally feel, that when building an app, at least getting started, it doesn't really matter which language, framework, toolset you use.
That is until it affects the users. Then the question is, "how it affects the users". Is it scalability? Is it a webview wrapped in a mobile app that was thrown together that gives a "weird feel". At the end of the day, your users/clients are the ones supporting your app so when they are affected, the best tool is necessary. Security is obviously another HUGE aspect of this. Thanks for the feedback!
Don't spend too much time writing the app. It's better to launch it as soon as possible and fix it with the customers :)
Well it depends on the project of course. But for the vast majority of use cases, the shortest way is to use a starter kit like Spark for PHP, Jumpstartpro for Rails, or Saasify for JS. You will save a lot of energy the first weeks.
Definitely love some of those starter kits! Getting off the ground and validating your idea as quickly as possible is essential.
An essay by Paul Graham http://www.paulgraham.com/avg.html on this topic
Programming language are extremely important in practise. One should always use the appropriate tool for the job at hand. Even if you manage to code your solution in a non-suitable language, the results are usually poor.
Theoretically, the differences between languages are irrelevant as long as they are equivalent to the Turing machine computational model (i.e. a language with general computational power). But that's just a theory, and every theory has to ignore some aspects of reality.
If you don't know any language, then you should definitely learn JS as it can be used both on the backend and frontend. If you already know a given language, you should stick to it.
Doesn't matter until it matters
Programming language determines available frameworks, and some frameworks have more libraries available for common features (making it so you don't have to code every little feature from scratch). For most cases, I'd pick something like Django, Rails, or Laravel for full-stack, or Gatsby, Next, Nuxt, or Eleventy for jamstack. The choice has to be balanced with what technology you already know, but nearly everyone who codes knows at least one of JavaScript, Python, Ruby, PHP.
The hard part about building a thing is getting it built. Do it in the language that's easiest for you to do that in. Later when you have revenue, financing, etc. it can always be rebuilt in another language but the problem most indiehackers are facing is to launch a product, not to perfect a product.
Launching the product and not perfecting the product is golden advice! Definitely finding that balance is key to making a successful app.
I voted no but the real answer is “it depends”. The post pretty well summed up my thoughts.
In the end I think it’s more important to just build and ship your ideas and constantly iterate and improve. Are there some decisions about the programming language/tech stack that will possibly hurt you down the road as you scale? sometimes… but don’t let that hold you back from building.
After working for product companies that got acquired I would say that it doesn't matter. Nowhere in the discussion did "the stack" really come up. I'd say use the tools that solve the customer problem and get you to market as fast as possible. Usually the product is re written anyway.
One design decision I'd recommend however is to build a monolith unless you're building something in which scale and performance is a key product feature. In my experience building as micro service architecture has functioned as a tax on the speed of development.
"Does stack make a difference when acquired" is definitely a hot subject for a few debates I've been in. It's also the great unknown since most apps want acquisition and few get it. I'm glad to hear that it never got brought up.
I'd love to hear if anyone else has had experience with this. I'm in the majority camp where non of my apps have been acquired so I have no experience here. Hopefully one day!
I usually approach apps that live on the web only as a monolith, and if I want the same codebase for web + mobile, then I do an SPA + API to separate concerns. But at the end of the day, whatever gets your app out the door!
Almost all apps get re-written anyways at some point as they grow, whether just a piece or the whole thing, so I would focus on getting the app up as fast as possible because you could spent a ton of time getting everything right technologically, and then the app flops, then you're left with a very well designed project that's worth nothing and you lost $$ on build time. Go with tech you know! You can iterate on the tech as you go, this is the way 99% of startups do it because it works. I am a developer too but, for decisions like these, you need to put on your business cap, not your developer cap.
Fun question to think about, thanks for asking!
Personally I'm on the side of "doesn't matter just build".
If you want to learn a new language, great here's a perfect opportunity to pick something new and learn it as you build your thing.
Want to build something fast? Use what you already know and get something out there.
I think trying to outsmart yourself and worry about "hiring devs" and "the industry of coding" is putting the cart before the horse. EVEN IF you build something that is massively successful likely it won't be like that for a maybe a year or more. Which.. the way Javascript frameworks are released you'll be behind anyways. So at that rate it wouldn't have mattered what you picked anyways.
From my personal experience I was a Java + Angular dev from about 2015- 2019 and built some apps with that stack. About a year ago I started learning Rails. I can say from my own perspective choosing Rails was the right decision. Much less complexity, set up and architecture decisions that I didn't have to worry about. I could just focus on building the thing I needed. Not to mention just general macitence. Keeping up with Angular and Java updates, two separate codebases was an absolute nightmare, not to mention trying to do it without a team.
People have a ton of different reasons for starting. I would encourage people to ask, "why am I building this thing?", "how much time do I have?", "do I want to learn something new and if so how much time is that going to take". All important questions that can guide you in deciding what to do in terms of stack.
Personally Rails FTW!
Thanks again for posting, thought provoking!
-Brandon
Thanks for the excellent feedback! One point you touched on that I haven't seen yet is "wanting to learn a new language". I'm extremely adamant on the best way to learn ANYTHING with programming is to build something that matters to you. When you hit that first roadblock, you will motivate yourself and have internal grit to power through if you care about what you are building. This is a great opportunity to learn that new language and open your mind to some of the tools that exist on other platforms. However, this is a new post entirely lol.
Another point you touched on is the trying to "outsmart yourself" and keeping up with the latest and greatest. Every day there's a new JS framework out and that is "more scalable", "quicker to write", "does X even better than Y" when at the end of the day, does it really matter? While I love talking about the pros and cons of some frameworks and there are things that are amazing (I personally love VueJS, but dang, React Native looks awesome), I'm so comfortable with Vue, have used it literally every day for years, switching entirely to React just for React Native seems super overwhelming.
As for the questions you'd consider, those are spot on. It'd be nice to minimize the confusion to starting devs and have them focus strictly on the functionality of the app they want to build. Reduce the friction from 0 to app.
Thanks again for the feedback!
As with everything, it depends. My coding experience spans over 20 years and I've worked with many languages. Even so, I still ask myself with each new project which tech stack I should use.
First and foremost, getting your product shipped should be the number one priority. That usually means picking the tech stack you know the best and rolling with it. But don't rush, cutting corners will slow you down. Just take your time and build the way you know how.
You will have different priorities if you're new to coding and do not have an intimate familiarity with a particular tech stack. In this case, you're probably going to be spending a lot more time digging into documentation, asking questions and doing a lot of trial and error. Select a solution that fits that need.
Nevertheless, it can be very motivating to introduce something new into the tech stack every so often. It's fun to learn something new, and I find it actually encourages me to get more done, especially if the project I'm working on isn't particularly interesting.
Your point on spending time digging into documentation is huge. It's one of the few times where I DO think you should sit down and evaluate the langauge, framework or tool. Especially when you are starting out. Once you have an understanding of app development, you can kind of fill in the blanks left by poor docs or figure out things with minimal time investment.
And I completely agree that it's motivating to dive into something new and approach a situation from a different perspective. It's educational, mind opening, you can find ways to enhance your workflow and even ways to contribute back to your community. That's a whole new article entirely though. Thanks for the feedback!
It Depends... thinking about the tech stack makes always sence according to the goals you want to achieve.
Such questions asked to late can lead early into technical debt.
If you have limited the possible programming languages and still have choices left open, just go for the Programming language your most familiar with.
Do not OVERTHINK your tech stack. There will always be pitfalls to your current language in the future you will never gues today
Great considerations and approach. Definitely in the camp of not overthinking and finding that balance to deliver the product.
Yeah, you need to have an understanding of code, as well as knowledge of trivial layout
I think that the question is a bit confusing.
As long as the language you pick is suitable for your product, it doesn't matter but if you want to build a website with C lang. Well, good luck with that.
C++ (or C with Classes) is an object-oriented, imperative, high level computer programming language developed by Bjarne Stroustrup at Bell Labs at AT&T. This programming language has been around since 1983 and is widely used in creating software applications for Windows, Linux, OS X, iOS, Android, and other platforms that are based on the x86 architecture. Visit https://www.zodiacsigns-horoscope.com/angel-numbers/angel-number-444-meaning/
Depend on the project..
If you think a language other than one you know would be more appropriate for your project, either hire someone to do it that already knows that language or use the language you already know. Creating a new SAAS product you intend to sell using a language you are just learning will likely not be better than using a language you already know even though it might not be the "best" for this particular purpose. ("best" probably being subjective anyway).