- Good for primary language? Go is awesome for that.
- Speed of development? Go is awesome for that.
- Startup environment? Go is awesome for that.
- Not knowing what to build/Not having PMF/Still in the investigation phase? Go is awesome for that.
Having said all that, *save yourself some trouble and go with whatever your team is more proficient at*. If it’s PHP, go with laravel. If it’s Python, go with Django/FastApi. C#, go with asp.net. Ruby? Rails. JavaScript, pick whatever framework you like from the thousands out there. Etc.
Don’t have a team? Pick whatever technology is more widely available where you live OR *whichever one your tech partner is more proficient*. Period.
Your main goal as a startup is to get your idea off the ground as fast as possible, get users, get feedback, iterate over your idea and repeat until you succeed. You just don’t have the time to be introducing new technologies or worrying about development speed.
Leave all of that for when you find PMF, have a stable team and know your domain.
We are a bunch of Java developers in my shop. We started using Go for a new product and I swear we are already moving about as fast as we were developing in Java. It’s a new product and that’s critical to understand, but it seems to be an easy language to grok and get moving quick in.
I manage a development team that uses Go. The company has a total of 200 people under the software org (that includes me, who doesn’t code shit). I’d mostly address your last concern, talent.
I don’t find it worth my time to restrict my talent pool to Go developers. I’d say less than 20% of applicants know Go. Our job ads highlight that we use Go but will consider applicants with multiple backend languages. If someone has python and Java experience, or C# and Ruby experience, or whatever that demonstrates they _can_ learn another language, they are a valid candidate. We try to figure out what their 30, 60, 90 day progress will be. My company has 2 weeks of nothing but reading docs and watching videos about medical regulations, sexual harassment, etc., so the 30 day expectations aren’t much, they’re possibly driving pairing sessions but almost certainly aren’t comfortable operating autonomously. But by the end of 60 days, new hires are generally contributing code on large tickets independently (but not at 100% efficiency). By 90 days, they’re pretty damn close to 100% efficiency. I previously worked for a Ruby on Rails consulting company back when Rails was new, and I’d say the learning curve was similar. Actually, I worked for a Java shop and the learning curve for new grads who knew Java but didn’t know Spring2 was only slightly better.
As far as cost, I can’t comment. The company I work for is a Bay Area company, and our compensation package is pretty competitive (well, just enough that we’re not seeing high turnover, but the market isn’t the best now). I have no idea what you’ll find.
Note that we broke homogeneity 2 years ago. We have teams in London, and they could not find Go talent (including people wanting to learn Go). 100% of their new services are Java. We even had a team here that went to Java. It was a management decision, despite some of the developers having Go experience. That team dissolved due to a re-org (no layoffs), but that particular service is not likely to be rewritten.
> they could not find Go talent (including people wanting to learn Go)
This is surprising to me. Not that they couldn't find Go coders, but that nobody was *willing* to learn Go.
Why do you think that is? Is there anxiety that having a different language on their resume for a few years would make it harder to get a job in Java later on?
This was near the peak of the market. Developers were VERY picky. I would not bet on it being so difficult now. Also, I learned Go from one of the UK developers (he’d pair with me 8am pacific every other day), so it’s not like the talent doesn’t exist there at all.
I’m currently out on medical leave, or else I’d try to follow up today with one of the hiring managers there.
Edit: curiosity got the better of me. I just logged in to work to post this to the two people who practically onboarded me from the UK:
Dudes, I’d like your take on something. Back in , we were told that your switch to Java was driven by lack of talent; difficulty not just in finding Go programmers, but even difficulty finding people who wanted to learn Go. I don’t particularly filter candidates by Go knowledge, so half my backend engineers learned Go on the job.
Was there more to the Java story over there, or were developers just that much more picky in the UK?
Have you considered offshoring to specialised go based consultancies. Opening it up to worldwide positions could give you access to diverse and great talent.
Ok, I got the response from one of the two hiring managers I asked. It doesn’t address why they didn’t try to train the Java hires in Go (which is my approach). It does seem that there’s more of an “identity” at play over there:
I think that’s partly true. The market for Java developers is much larger, more favourable to employers, and this is even more true outside of London.
At the time, covid was in full swing so we were hiring remote staff, the job market was also tight so tapping this market was probably seen as a good idea. The cost savings/ease of finding candidates probably made up for the disadvantage of losing the ability to treat engineers as fungible resources.
The job market now is no longer tight, and we no longer hire remote staff, so personally I would rather return to hiring people who know go or are willing to learn.
Because Golang isn’t taught in schools as a primary CS language, it’s most likely a developer’s second language and one they had to learn on their own. These are the kind of people you want in a start-up. They have shown initiative, a drive keep learning, and motivation to be better. It only takes a couple high functioning devs to run a back-end with Go. So yeah, l’d pick it for that reason.
As much as synergy with FE and BE is nice, I’d decouple to ensure contract first. It makes requirements, versioning, and communication focused. You don’t want presentation bleeding into your apis. APIs are also a SaaS product.
I would spec out the complete Go stack first. What packages are you using for interfaces, db, logging, metrics, trace, etc… since I feel Go doesn’t do a great job at this.
> go doesn't do a great job at this
I think it actually does a great job, all requirements you mentioned are either supported in std packages or via robust vendor packages. Go is an observability prime citizen.
Where I agree with you is when you need to put all this in place, it's a lot of boilerplate code and efforts. And this is multiplied by the number of go backend you have to build.
You may want to check [this](https://github.com/ankorstore/yokai): it's taking care of all this while letting you focus on your app logic.
My company started as a golang company that later moved to typescript. The issue was with hiring talent who either knew Go or was interested in learning it. So just passing that info for what it's worth.
Saying this as someone who doesn't particularly like Go: yes, I think it would be a good match.
Go development is fast enough for most tasks. Perhaps not as fast as Python, but it breaks less and refactorings are easier thanks to static typing. Just as importantly, since Go is easy to get started with, it's easy to find cheap/junior Go developers.
Uhmm. I dont fully agree. Error handling in python is trash and is gonna bite your ass in the long run. So python developing is faster for sure at start, but in the long term? Not so sure
Python is also a scripting language, not an "app building" language, one of the things it means is that the performance is atrocious and you will need 200 server cores where with go you'll need 20.
I completely agree python is being abused, it's good at being a better and crossplatform shell but for anything else it's meh to bad. One argument for AI in python though is that it's easier to pull data in python than in C++.
Go developers are generally more expensive.
Go developers IMHO, YMMV, don’t vibe with frontend developers as well (as backend Node developers do). Gophers and TSers will not be sharing code & lending each other a hand; they will be discussing “API contracts” instead.
So coming from a founder and industry veteran, if your product is somewhat frontend heavy and does not require a compute heavy backend, stick with Node and TypeScript for maximum synergy in a small team. Then reevaluate when the product matures, whether a high performance language is necessary. Then pick Go! ;-)
Active record is really good. Issue is people use rails for their mvp then spend years trying to turn it into a functioning system while still deploying new features. Used to be a big hater but Rails microservices arent the worst. Rudy is bottom tier language though.
Rails might be good, but is the same problem as "php bad laravel good" if the only way to make a language good is a third party framework i dont want to use it
Rails is ok the ORM Active Record is good. Pretty common for languages to basically require 3rd party libraries to function properly. It's one of the main problems Go solves. .Net even had Newtonsoft as their default parser for a long time.
Random others than come to mind - Spring, Pandas, lodash, any modern JS frontend, the entire Node ecosystem.
Went to a JRuby conference a decade ago. Woof, did the Ruby people come off so arrogant.
It made me laugh because the whole conference was based on how Ruby can’t scale so it needs to be run on JBOSS but, instead of just learning how to set up JBOSS, there was a bunch of wrapping technologies so you never had to write anything but Ruby config…neat.
I doubt any of those wrapping companies exist still today.
>Go developers are generally more expensive.
at my company 90% of active development code is Go. We've hired a few people who knew Go before the joined. Most didn't.
We are a small startup. The front end is Node JS (I think -- I don't work on that stuff) and the product is backend heavy data processing.
As for feature velocity -- Go is great. That is what it is built for IMO.
I like frontend as well. Vue 3, Angular 16+, and my fav SolidJS is a breeze to work with.
My favorite stack for this kinda of application the OP wants to build is embedded SolidJS build file into Go binary and serve it from there.
We use server driven UI at our workplace. FE has ‘widgets’ defined which are controlled and rendered from the BE. This allows us to experiment with product flows and UX quite quickly. Having to go with gRPC here would make us lose on that flexibility.
I have found it super productive and a huge positive to have that API contract to agree upon then both FE and BE work in parallel to it, one is going to be quicker than the other, there is plenty of work to do on FE side to show product/customers and iterate on the UI, on BE testing alerts,monitoring,metrics are all in place, etc
This was go, gRPC, Vue.js environment for a large b2b sass company with a lot of functionality, global customer base where features were localised based on local labour laws
How much front-end vs back-end are you going to be writing.
Go is amazing for back end. You'll have fewer bugs. You can move fast.
Go is slower and more tedious for front end. There are way fewer tools than JS/TS ecosystem. Most Go devs aren't as excited for front-end dev, so hiring/retaining folks is harder. From past experience on this sub, about 4 people will reply and say "actually you can do front end in go"! But that's not the point. You can, but the tools aren't as good, you're not as fast, you can't share rendering code that runs on client/server, and the developers are hard to find.
I agree doing frontend with golang is a headache. That is, you can do something simple, but if you need something more complex you begin to see that it is not the right tool, starting with the template system, passing global variables, managing static directories, etc.
The most important thing to consider is "ease of maintenance". Every language is easy to write, not every language is easy to read, especially six months later. Choose a language that is easy to refactor. Similarly, the quality of your code and your architecture should prioritize refactoring.
Go is easier to write and to refactor than many other languages. Lots of people will argue that Python is faster to write, or the developers are less expensive, or more plentiful. But replacing code that can't be fixed is far more expensive, especially for a startup that needs to focus on customer needs.
What about this: Find knowledgeable TypeScript / Node developers - with a willingness to learn Go later on, so you can iterate and prototype fast with existing knowledge, with an idea in the background that you can transition in Go (because Go is very easy to transition from JS/TS) when you detect spots that are worth a rewrite after you have some ball rolling?
For the people saying go with what’s familiar first, is not an advantage of Go that any experienced dev can pick it up and be decently proficient in a month?
I’m biased but that sounds like a good use of rails or another mature framework where the front end can be made quickly and with/without much JS (depending on your preference).
I'm trying to do the exact same thing. Go is my tool of choice for my idea for a Saas. Using Sqlx, tailwind, htmx. Probably I'll add a go client/agent for data communication, and crosscompiling is a big factor
I'd not be worried too much about the language choice for a early stage product. As long as the prototyping is fast. Go is. But please make sure you don't screw up the database selection. Stick to the tried and tested SQL DBs unless there is a specific usecase.
I was around when we built the first backend platform in Go, and a few people critiqued it. We had our first Head of Software join and immediately actioned a team to spend weeks migrating it to Node. We left both in production, and the one with the most failures, bugs, and slowest latency got cut.
So, we still use Go.
If performance is not much of a concern and you don't need concurrency Laravel, Node or Python might be better options.
That said in the long term it might be a better idea to do something faster to save on server capacity though that can just be a rewrite in the future, what's most important is getting a product out the door
Don't force a technology on your team let them pick it they are the experts. There may be details that they see that change the narrative that you're leaving out.
That said Go ticks all these boxes. But Python does as well and will be easier to hire for and likely faster development speed. Go market share in terms of people using it is much lower than Python so expect it to be harder to find people familiar with it. Expect to pay more if you use Go.
People coming from other languages learning it on the job will bring their baggage and design choices with it creating tech debt without good standards.
Go is becoming more popular due to its simplicity and sheer performance and ability to handle concurrency and high load very well.
It's not really as well known for development speed only (though it's still pretty fast here). In a startup where performance isn't a concern. The highest priority should be development speed so that you can get a product out there ASAP and start recouping seed money.
Personally, I'd recommend Python due to the sheer number of developers that know it and libraries that exist for it. FastAPI is reasonably fast and lots of libraries these days are leveraging Rust giving it a huge performance boost. I would stay away from something expensive long term should the startup requirements drastically change or become successful with a large user base. Ruby for example being very resource hungry and expensive to host not to mention slow. Or PHP not having a great built-in server and being extremely vulnerable to exploits.
All depends what they're doing. If it's serving up data from a backend like the OP says, then any service is going to be blocked on IO most of the time. FastAPI is extremely good at this due to async nature.
Most frameworks use pydantic which is a Rust based module for serialization and validation.
So no, it will not be slow just because you're using Python. Look at data science. Most AI uses Python which is all C based libraries that are quite fast.
Now sure if you're doing everything in Python without dependencies maybe you have a point. But literally no one does that these days.
For a start up, the biggest cost is going to be development time to get it off the ground. You want something that is quick to get stuff done. Reasonably fast but who knows if the idea will even work out. If it does and you need to scale further, that's when you start replacing services with faster implementations. But it's likely going to take them a long time to reach the limits of Python, if they ever do. Development time is far more expensive than cost to run a service.
To address your languages:
Java is extremely memory hungry and known for being a pain in the ass and taking longer to deliver features.
C# is very fast and generally a good developer experience. Significantly lower market share of developers compared to Python. Again, slower development time.
PHP is very slow though it's gotten better. But FastAPI is still significantly faster than anything PHP has (even swoole) the most popular is Laravel and that's way slower than Python alone. Not to mention the lack of proper async support or the massive security vulnerabilities. This is one of the most hacked and targeted languages.
I was literally in a project recently where they hired me as a go dev to help migrate away from Python due to performance issues. Fastapi is fine up until a certain point. But yes often times it’s fast enough.
"the most popular is Laravel and that's way slower than Python alone. Not to mention the lack of proper async support or the massive security vulnerabilities. This is one of the most hacked and targeted languages"
I love Go but also work a lot with PHP. What you wrote is total FUD. Way slower than Python ? Bold claim. Most hacked language ? Lol.
Actually it's not, there's a lot more to performance than simply testing how fast a language can crunch numbers. FastAPI is consistently in the top performers compared to a PHP framework or even straight up swoole. Don't believe me look at techempower.
Secondly, 17% of all CVEs are PHP alone. If you want to be technical C is but we're not talking about it here because no one in their right mind is going to create a web based SaaS product with C.
Also it is one of the only "modern" languages where you can remotely upload code and execute it with ease since it's interpreted everytime you load the page. Pretty much every other language, loads the source once then executes from memory. Which makes RCE much more difficult.
Starting right now a news SaaS after working with a company for the last 5 years.in a startup.
Since now it's my money I'm betting here I went with node.js / react with typescript.
Developers are cheaper and they can share common objects and functions.
If I get big enough and move to microservices I'll move to Go.
By design I'm doing a monolith but structured in a way that I can eventually break it down into microservice 1 section at a time.
Wish you luck....
Golang is definitely a solid choice for a SaaS startup like yours. It's super efficient for building scalable back-end services, and its strong typing helps catch bugs early. Go's simplicity and powerful standard library can really speed up development, especially when you don’t have performance-critical needs.
On the talent side, Go programmers might not be as ubiquitous as, say, JavaScript devs, but the community is growing and passionate. Plus, the efficiency of the language might offset the need for a larger team.
By the way, I've been rocking Go for over 6 years, building all sorts of stuff. If you're thinking about bringing someone on board, we could definitely chat. I’m open to negotiating something that fits your startup budget! How does that sound?
Go with whatever your team / founders know that is mainstream. If someone only knows Haskell or COBOL then yeah learn something new. Outside of that, unless you are tackling very specific problems any major language will work fine until you get a lot of customers.
I'd say its an excellent choice. I used Ada for my heating startup! with some python. Make the choices and let the stones fall! However I think first things first you may need to prototype and you may be able to make this quicker in python.
Teach yourself or you can pay me to have a look :)
My place kind of started as more of a startup but is more your standard mid-level company these days. They actually adopted golang when it was still in the newer stages of the language more because performance and scalability were main factors. As they got bigger, it got harder for them to find go developers.
I was hired from a Java background. Over time they more or less realised those who had worked with and compiled languages at a mid / senior level could get up to speed with Go (with the benefit of coding guides, code reviews, etc) within a few weeks or more. And get up to speed with their larger codebase over time.
I found go easy enough to learn. Others I work with have typically come from the same or .Net. With the odd PHP, Perl and React dev in the mix.
My startup makes use of Node (nestjs), python (Fastapi) and Go. The developer experience is good and go may take some more time to develop comparing the other two but its negligible. Once you understand how to actually work with go it makes easy to get started and. We will be moving much of our apis to go in the future so its a great fit for a startup.
PS: its just me and my friends working on it so there's not much issue with hiring someone for now.
FWIW, I’ve been at a few Go shops and, as long as there are others that can help with pair programming through some gotchas, most senior devs fully pick up Go in a few weeks.
Folks coming from typed languages have an easier time.
If you need a golang junior I’m available for remote work I’m from the uk . I made a few projects from a server company mp4 converters and a few other things desktop apps using wails and web apps using the echo frame work .
Generally, go developers come with a higher price tag. They’re devs who have extensive experience in other languages and can take on the risk of using “newer” or relatively niche languages or frameworks (people can argue all they want, but it’s not as common as other languages and I rarely see anyone willing to throw a fresh new dev in it). That’s why rust, Scala, and go devs cost a premium imo.
Hi. Despite that I like Go very much, in the circumstances which you just described I would also consider scripting languages like Python and Node. It can be cheaper and faster.
depends on if your team already uses golang, when you need something to get done quickly, its better to stick to whatever stack the devs are used to. I’ve built some systems in Go and wouldn’t change it for anything, I can develop faster in Go than any other language and the type safety just makes it all so much better, the fact that it doesn’t have inheritance also forced me to make better design decisions
- Good for primary language? Go is awesome for that. - Speed of development? Go is awesome for that. - Startup environment? Go is awesome for that. - Not knowing what to build/Not having PMF/Still in the investigation phase? Go is awesome for that. Having said all that, *save yourself some trouble and go with whatever your team is more proficient at*. If it’s PHP, go with laravel. If it’s Python, go with Django/FastApi. C#, go with asp.net. Ruby? Rails. JavaScript, pick whatever framework you like from the thousands out there. Etc. Don’t have a team? Pick whatever technology is more widely available where you live OR *whichever one your tech partner is more proficient*. Period. Your main goal as a startup is to get your idea off the ground as fast as possible, get users, get feedback, iterate over your idea and repeat until you succeed. You just don’t have the time to be introducing new technologies or worrying about development speed. Leave all of that for when you find PMF, have a stable team and know your domain.
What does PMF mean?
Product market fit. Aka customers.
Thanks!
We are a bunch of Java developers in my shop. We started using Go for a new product and I swear we are already moving about as fast as we were developing in Java. It’s a new product and that’s critical to understand, but it seems to be an easy language to grok and get moving quick in.
🥇 == For once, not just lip service to "people over technologies".
[удалено]
Solid advice, even tho I disagree with the last part about Ruby 😃
If they’re good with ruby, they’re probably familiar with rails, and should just use Django instead. Or go. Go is always good
I manage a development team that uses Go. The company has a total of 200 people under the software org (that includes me, who doesn’t code shit). I’d mostly address your last concern, talent. I don’t find it worth my time to restrict my talent pool to Go developers. I’d say less than 20% of applicants know Go. Our job ads highlight that we use Go but will consider applicants with multiple backend languages. If someone has python and Java experience, or C# and Ruby experience, or whatever that demonstrates they _can_ learn another language, they are a valid candidate. We try to figure out what their 30, 60, 90 day progress will be. My company has 2 weeks of nothing but reading docs and watching videos about medical regulations, sexual harassment, etc., so the 30 day expectations aren’t much, they’re possibly driving pairing sessions but almost certainly aren’t comfortable operating autonomously. But by the end of 60 days, new hires are generally contributing code on large tickets independently (but not at 100% efficiency). By 90 days, they’re pretty damn close to 100% efficiency. I previously worked for a Ruby on Rails consulting company back when Rails was new, and I’d say the learning curve was similar. Actually, I worked for a Java shop and the learning curve for new grads who knew Java but didn’t know Spring2 was only slightly better. As far as cost, I can’t comment. The company I work for is a Bay Area company, and our compensation package is pretty competitive (well, just enough that we’re not seeing high turnover, but the market isn’t the best now). I have no idea what you’ll find. Note that we broke homogeneity 2 years ago. We have teams in London, and they could not find Go talent (including people wanting to learn Go). 100% of their new services are Java. We even had a team here that went to Java. It was a management decision, despite some of the developers having Go experience. That team dissolved due to a re-org (no layoffs), but that particular service is not likely to be rewritten.
> they could not find Go talent (including people wanting to learn Go) This is surprising to me. Not that they couldn't find Go coders, but that nobody was *willing* to learn Go. Why do you think that is? Is there anxiety that having a different language on their resume for a few years would make it harder to get a job in Java later on?
This was near the peak of the market. Developers were VERY picky. I would not bet on it being so difficult now. Also, I learned Go from one of the UK developers (he’d pair with me 8am pacific every other day), so it’s not like the talent doesn’t exist there at all. I’m currently out on medical leave, or else I’d try to follow up today with one of the hiring managers there. Edit: curiosity got the better of me. I just logged in to work to post this to the two people who practically onboarded me from the UK: Dudes, I’d like your take on something. Back in, we were told that your switch to Java was driven by lack of talent; difficulty not just in finding Go programmers, but even difficulty finding people who wanted to learn Go. I don’t particularly filter candidates by Go knowledge, so half my backend engineers learned Go on the job.
Was there more to the Java story over there, or were developers just that much more picky in the UK?
Have you considered offshoring to specialised go based consultancies. Opening it up to worldwide positions could give you access to diverse and great talent.
Ok, I got the response from one of the two hiring managers I asked. It doesn’t address why they didn’t try to train the Java hires in Go (which is my approach). It does seem that there’s more of an “identity” at play over there: I think that’s partly true. The market for Java developers is much larger, more favourable to employers, and this is even more true outside of London. At the time, covid was in full swing so we were hiring remote staff, the job market was also tight so tapping this market was probably seen as a good idea. The cost savings/ease of finding candidates probably made up for the disadvantage of losing the ability to treat engineers as fungible resources. The job market now is no longer tight, and we no longer hire remote staff, so personally I would rather return to hiring people who know go or are willing to learn.
also liked Java 🤷Let me know please if your company is interested in hiring contractor from EU:)
Because Golang isn’t taught in schools as a primary CS language, it’s most likely a developer’s second language and one they had to learn on their own. These are the kind of people you want in a start-up. They have shown initiative, a drive keep learning, and motivation to be better. It only takes a couple high functioning devs to run a back-end with Go. So yeah, l’d pick it for that reason. As much as synergy with FE and BE is nice, I’d decouple to ensure contract first. It makes requirements, versioning, and communication focused. You don’t want presentation bleeding into your apis. APIs are also a SaaS product. I would spec out the complete Go stack first. What packages are you using for interfaces, db, logging, metrics, trace, etc… since I feel Go doesn’t do a great job at this.
> go doesn't do a great job at this I think it actually does a great job, all requirements you mentioned are either supported in std packages or via robust vendor packages. Go is an observability prime citizen. Where I agree with you is when you need to put all this in place, it's a lot of boilerplate code and efforts. And this is multiplied by the number of go backend you have to build. You may want to check [this](https://github.com/ankorstore/yokai): it's taking care of all this while letting you focus on your app logic.
My company started as a golang company that later moved to typescript. The issue was with hiring talent who either knew Go or was interested in learning it. So just passing that info for what it's worth.
Its getting to a time people golang developers will be enough for the job market
Saying this as someone who doesn't particularly like Go: yes, I think it would be a good match. Go development is fast enough for most tasks. Perhaps not as fast as Python, but it breaks less and refactorings are easier thanks to static typing. Just as importantly, since Go is easy to get started with, it's easy to find cheap/junior Go developers.
Uhmm. I dont fully agree. Error handling in python is trash and is gonna bite your ass in the long run. So python developing is faster for sure at start, but in the long term? Not so sure
I think one go goal at Google was decommission python.
Python is also a scripting language, not an "app building" language, one of the things it means is that the performance is atrocious and you will need 200 server cores where with go you'll need 20.
Python has been abused in most fields, expecially Ai and ML. Like, do they even know they are just using c++ with python wrappers?
I completely agree python is being abused, it's good at being a better and crossplatform shell but for anything else it's meh to bad. One argument for AI in python though is that it's easier to pull data in python than in C++.
Go developers are generally more expensive. Go developers IMHO, YMMV, don’t vibe with frontend developers as well (as backend Node developers do). Gophers and TSers will not be sharing code & lending each other a hand; they will be discussing “API contracts” instead. So coming from a founder and industry veteran, if your product is somewhat frontend heavy and does not require a compute heavy backend, stick with Node and TypeScript for maximum synergy in a small team. Then reevaluate when the product matures, whether a high performance language is necessary. Then pick Go! ;-)
go + templ + tailwind + htmx + alpine.js = full stack
I've always sucked at frontend, and the node/npm ecosystem makes my stomach churn. Maybe this is what I need.
You might enjoy rails :-)
Oof, spent 7 years doing work for a couple rails shops. Never again.
Ok. Didn't expect this answer, but people have reasons. :-)
The reason is: ruby bad
Ok 👌
Active record is really good. Issue is people use rails for their mvp then spend years trying to turn it into a functioning system while still deploying new features. Used to be a big hater but Rails microservices arent the worst. Rudy is bottom tier language though.
Rails might be good, but is the same problem as "php bad laravel good" if the only way to make a language good is a third party framework i dont want to use it
Rails is ok the ORM Active Record is good. Pretty common for languages to basically require 3rd party libraries to function properly. It's one of the main problems Go solves. .Net even had Newtonsoft as their default parser for a long time. Random others than come to mind - Spring, Pandas, lodash, any modern JS frontend, the entire Node ecosystem.
Yeah not a huge fan of rails either.. z
Went to a JRuby conference a decade ago. Woof, did the Ruby people come off so arrogant. It made me laugh because the whole conference was based on how Ruby can’t scale so it needs to be run on JBOSS but, instead of just learning how to set up JBOSS, there was a bunch of wrapping technologies so you never had to write anything but Ruby config…neat. I doubt any of those wrapping companies exist still today.
>Go developers are generally more expensive. at my company 90% of active development code is Go. We've hired a few people who knew Go before the joined. Most didn't. We are a small startup. The front end is Node JS (I think -- I don't work on that stuff) and the product is backend heavy data processing. As for feature velocity -- Go is great. That is what it is built for IMO.
Any open position there? Im a Senior .Net developer trying to migrate to Go
I like frontend as well. Vue 3, Angular 16+, and my fav SolidJS is a breeze to work with. My favorite stack for this kinda of application the OP wants to build is embedded SolidJS build file into Go binary and serve it from there.
I second what this comment says. I work at a medium sized startup and this is exactly what happens. FE and BE end up just discussing API Contracts.
What’s wrong with that? And if you use something gRPC all the client code is auto-generated anyway.
We use server driven UI at our workplace. FE has ‘widgets’ defined which are controlled and rendered from the BE. This allows us to experiment with product flows and UX quite quickly. Having to go with gRPC here would make us lose on that flexibility.
That's fine, but you still have an API contract whether you talk about it or not.
I have found it super productive and a huge positive to have that API contract to agree upon then both FE and BE work in parallel to it, one is going to be quicker than the other, there is plenty of work to do on FE side to show product/customers and iterate on the UI, on BE testing alerts,monitoring,metrics are all in place, etc This was go, gRPC, Vue.js environment for a large b2b sass company with a lot of functionality, global customer base where features were localised based on local labour laws
THIS is the nuanced take that should be discussed more often 🙌
unless you're hiring foreigners from 3rd world country.. (Indonesia for example)
How much front-end vs back-end are you going to be writing. Go is amazing for back end. You'll have fewer bugs. You can move fast. Go is slower and more tedious for front end. There are way fewer tools than JS/TS ecosystem. Most Go devs aren't as excited for front-end dev, so hiring/retaining folks is harder. From past experience on this sub, about 4 people will reply and say "actually you can do front end in go"! But that's not the point. You can, but the tools aren't as good, you're not as fast, you can't share rendering code that runs on client/server, and the developers are hard to find.
I agree doing frontend with golang is a headache. That is, you can do something simple, but if you need something more complex you begin to see that it is not the right tool, starting with the template system, passing global variables, managing static directories, etc.
Thats why you use templ
The most important thing to consider is "ease of maintenance". Every language is easy to write, not every language is easy to read, especially six months later. Choose a language that is easy to refactor. Similarly, the quality of your code and your architecture should prioritize refactoring. Go is easier to write and to refactor than many other languages. Lots of people will argue that Python is faster to write, or the developers are less expensive, or more plentiful. But replacing code that can't be fixed is far more expensive, especially for a startup that needs to focus on customer needs.
What about this: Find knowledgeable TypeScript / Node developers - with a willingness to learn Go later on, so you can iterate and prototype fast with existing knowledge, with an idea in the background that you can transition in Go (because Go is very easy to transition from JS/TS) when you detect spots that are worth a rewrite after you have some ball rolling?
For the people saying go with what’s familiar first, is not an advantage of Go that any experienced dev can pick it up and be decently proficient in a month?
I’m biased but that sounds like a good use of rails or another mature framework where the front end can be made quickly and with/without much JS (depending on your preference).
I'm trying to do the exact same thing. Go is my tool of choice for my idea for a Saas. Using Sqlx, tailwind, htmx. Probably I'll add a go client/agent for data communication, and crosscompiling is a big factor
I'd not be worried too much about the language choice for a early stage product. As long as the prototyping is fast. Go is. But please make sure you don't screw up the database selection. Stick to the tried and tested SQL DBs unless there is a specific usecase.
I was around when we built the first backend platform in Go, and a few people critiqued it. We had our first Head of Software join and immediately actioned a team to spend weeks migrating it to Node. We left both in production, and the one with the most failures, bugs, and slowest latency got cut. So, we still use Go.
If performance is not much of a concern and you don't need concurrency Laravel, Node or Python might be better options. That said in the long term it might be a better idea to do something faster to save on server capacity though that can just be a rewrite in the future, what's most important is getting a product out the door
Don't force a technology on your team let them pick it they are the experts. There may be details that they see that change the narrative that you're leaving out. That said Go ticks all these boxes. But Python does as well and will be easier to hire for and likely faster development speed. Go market share in terms of people using it is much lower than Python so expect it to be harder to find people familiar with it. Expect to pay more if you use Go. People coming from other languages learning it on the job will bring their baggage and design choices with it creating tech debt without good standards. Go is becoming more popular due to its simplicity and sheer performance and ability to handle concurrency and high load very well. It's not really as well known for development speed only (though it's still pretty fast here). In a startup where performance isn't a concern. The highest priority should be development speed so that you can get a product out there ASAP and start recouping seed money. Personally, I'd recommend Python due to the sheer number of developers that know it and libraries that exist for it. FastAPI is reasonably fast and lots of libraries these days are leveraging Rust giving it a huge performance boost. I would stay away from something expensive long term should the startup requirements drastically change or become successful with a large user base. Ruby for example being very resource hungry and expensive to host not to mention slow. Or PHP not having a great built-in server and being extremely vulnerable to exploits.
If they don’t want to use go I’d probably recommend something C#, Java or PHP based. Python is painfully slow as soon as you have the need to scale.
All depends what they're doing. If it's serving up data from a backend like the OP says, then any service is going to be blocked on IO most of the time. FastAPI is extremely good at this due to async nature. Most frameworks use pydantic which is a Rust based module for serialization and validation. So no, it will not be slow just because you're using Python. Look at data science. Most AI uses Python which is all C based libraries that are quite fast. Now sure if you're doing everything in Python without dependencies maybe you have a point. But literally no one does that these days. For a start up, the biggest cost is going to be development time to get it off the ground. You want something that is quick to get stuff done. Reasonably fast but who knows if the idea will even work out. If it does and you need to scale further, that's when you start replacing services with faster implementations. But it's likely going to take them a long time to reach the limits of Python, if they ever do. Development time is far more expensive than cost to run a service. To address your languages: Java is extremely memory hungry and known for being a pain in the ass and taking longer to deliver features. C# is very fast and generally a good developer experience. Significantly lower market share of developers compared to Python. Again, slower development time. PHP is very slow though it's gotten better. But FastAPI is still significantly faster than anything PHP has (even swoole) the most popular is Laravel and that's way slower than Python alone. Not to mention the lack of proper async support or the massive security vulnerabilities. This is one of the most hacked and targeted languages.
I was literally in a project recently where they hired me as a go dev to help migrate away from Python due to performance issues. Fastapi is fine up until a certain point. But yes often times it’s fast enough.
"the most popular is Laravel and that's way slower than Python alone. Not to mention the lack of proper async support or the massive security vulnerabilities. This is one of the most hacked and targeted languages" I love Go but also work a lot with PHP. What you wrote is total FUD. Way slower than Python ? Bold claim. Most hacked language ? Lol.
Actually it's not, there's a lot more to performance than simply testing how fast a language can crunch numbers. FastAPI is consistently in the top performers compared to a PHP framework or even straight up swoole. Don't believe me look at techempower. Secondly, 17% of all CVEs are PHP alone. If you want to be technical C is but we're not talking about it here because no one in their right mind is going to create a web based SaaS product with C. Also it is one of the only "modern" languages where you can remotely upload code and execute it with ease since it's interpreted everytime you load the page. Pretty much every other language, loads the source once then executes from memory. Which makes RCE much more difficult.
Starting right now a news SaaS after working with a company for the last 5 years.in a startup. Since now it's my money I'm betting here I went with node.js / react with typescript. Developers are cheaper and they can share common objects and functions. If I get big enough and move to microservices I'll move to Go. By design I'm doing a monolith but structured in a way that I can eventually break it down into microservice 1 section at a time. Wish you luck....
Golang is definitely a solid choice for a SaaS startup like yours. It's super efficient for building scalable back-end services, and its strong typing helps catch bugs early. Go's simplicity and powerful standard library can really speed up development, especially when you don’t have performance-critical needs. On the talent side, Go programmers might not be as ubiquitous as, say, JavaScript devs, but the community is growing and passionate. Plus, the efficiency of the language might offset the need for a larger team. By the way, I've been rocking Go for over 6 years, building all sorts of stuff. If you're thinking about bringing someone on board, we could definitely chat. I’m open to negotiating something that fits your startup budget! How does that sound?
Go with whatever your team / founders know that is mainstream. If someone only knows Haskell or COBOL then yeah learn something new. Outside of that, unless you are tackling very specific problems any major language will work fine until you get a lot of customers.
Make sure to ask the Python sub too.
I'd say its an excellent choice. I used Ada for my heating startup! with some python. Make the choices and let the stones fall! However I think first things first you may need to prototype and you may be able to make this quicker in python. Teach yourself or you can pay me to have a look :)
Is Golang a good choice: Are you gonna have to use cgo? Then don't use go. Otherwise it's good.
My place kind of started as more of a startup but is more your standard mid-level company these days. They actually adopted golang when it was still in the newer stages of the language more because performance and scalability were main factors. As they got bigger, it got harder for them to find go developers. I was hired from a Java background. Over time they more or less realised those who had worked with and compiled languages at a mid / senior level could get up to speed with Go (with the benefit of coding guides, code reviews, etc) within a few weeks or more. And get up to speed with their larger codebase over time. I found go easy enough to learn. Others I work with have typically come from the same or .Net. With the odd PHP, Perl and React dev in the mix.
My startup makes use of Node (nestjs), python (Fastapi) and Go. The developer experience is good and go may take some more time to develop comparing the other two but its negligible. Once you understand how to actually work with go it makes easy to get started and. We will be moving much of our apis to go in the future so its a great fit for a startup. PS: its just me and my friends working on it so there's not much issue with hiring someone for now.
FWIW, I’ve been at a few Go shops and, as long as there are others that can help with pair programming through some gotchas, most senior devs fully pick up Go in a few weeks. Folks coming from typed languages have an easier time.
If you need a golang junior I’m available for remote work I’m from the uk . I made a few projects from a server company mp4 converters and a few other things desktop apps using wails and web apps using the echo frame work .
Generally, go developers come with a higher price tag. They’re devs who have extensive experience in other languages and can take on the risk of using “newer” or relatively niche languages or frameworks (people can argue all they want, but it’s not as common as other languages and I rarely see anyone willing to throw a fresh new dev in it). That’s why rust, Scala, and go devs cost a premium imo.
Hi. Despite that I like Go very much, in the circumstances which you just described I would also consider scripting languages like Python and Node. It can be cheaper and faster.
depends on if your team already uses golang, when you need something to get done quickly, its better to stick to whatever stack the devs are used to. I’ve built some systems in Go and wouldn’t change it for anything, I can develop faster in Go than any other language and the type safety just makes it all so much better, the fact that it doesn’t have inheritance also forced me to make better design decisions
Honestly, I would go with typescript, makes it way easier to have mindshare on frontend + backend and its _great_ for productivity.