8 ms·

Can anyone answer why python is a choice anymore instead of i.e. golang for saas applications like this? I previously worked heavily with ruby and I cannot imag

Can anyone answer why python is a choice anymore instead of i.e. golang for saas applications like this? I previously worked heavily with ruby and I cannot imagine building beyond >1000 LoC in interpreted, dynamically typed languages. Aside from developer familiarity which trumps all other points. It's also significantly easier to dockerize a generated binary from golang or rust, etc. Some of my worst docker headaches have been from trying to debug something like mayan-edbms, which uses python and celery workers. I just don't get it unless you specifically need some libraries that no other language has.

Nextgrid 6y ago
What's the Django/Rails equivalent in Go? The value from Python isn't Python itself (though it might be easier to write in - trading off reliability for ease of use compared to a compiled language) but the ecosystem. Fully-featured frameworks such as Django, Rails, etc give you lots of functionality out of the box which is very valuable especially at the early stages of the project where performance isn't a concern yet.
- andrewzah 6y ago
  "(though it might be easier to write in - trading off reliability for ease of use compared to a compiled language)" I find the "ease" is overstated compared to time spent debugging issues in production, but that is a separate discussion. See my comment in the sister thread about the django/rails equivalent.
- rufius 6y ago
  Honestly, frameworks like Rails or Django are an anti-pattern for Golang. The standard library makes it very easy to build web services and there’s a couple or popular packages for making routes and dealing with HTTP requests/responses simple. There’s projects like Micro that try to do a little more batteries included but I wouldn’t consider them to be pervasive in the way Django or Rails are. Beyond that, it’s just app logic and the typical Golang boiler plate. Source: I’ve built a few big Golang services for a couple companies.
  - sk5t 6y ago
    Contrary perspective: only avoid frameworks when you can be assured your project is (and will remain) so narrow that it has no need of validation libraries and the like.
  - treis 6y ago
    >Honestly, frameworks like Rails or Django are an anti-pattern for Golang. Which is, IMHO, the biggest thing holding Go back. The standard library does a lot but a lot is also missing. Authentication, db migration, admin panels, ORM, Asset pipeline and probably more. It's a lot of custom work to do or pulling in various libraries.
    - CameronNemo 6y ago
      I don't think Go will see something even close to Django until generics are merged.
    - rufius 6y ago
      I have mixed feelings on this. I go back and forth on whether I agree or disagree. For example, once an application becomes sufficiently complex, I've found ORM's to be more of a hindrance. The abstraction gets leaky and I end up having to tune custom queries to get around some pathological edge case. That said - most of my experience is with Rails and a lot of the implicit nature of it is problematic. On the other hand, I've not had this experience with Laravel. Which one is right? I dunno. Lately though, writing sizable web applications in Golang is working out well so I guess I'll keep doing that.
      - leetrout 6y ago
        Rails implicit magic is so painful. I’ll disagree and agree on the ORM front. A good ORM has a clean escape handle for tuning hot spots and otherwise saves you time with boilerplate queries. Add a new field? Update the class / structs, generate a migration and move on. Without the ORM you write the migration yourself, you have to find and update all the queries and if you’re centralizing all your query building then you’re just using your own ORM-light without the battle hardened trials of other users using something open source and popular. I insisted we use sql alchemy and alembic in our latest Go project — and I’m eyeballing Buffalo’s Soda and Fizz as a replacement. Its generally just nerdcore navel gazing to insist on raw sql across a project in my opinion. Especially web apps / SaaS where you churn tables a lot. Simple migrations from simple models is what I love about Django and Flask/Fast API with SQL Alchemy.
- kitd 6y ago
  I think if you're using Htmx/Intercooler with Golang, you'd probably want to take a different approach from Django anyway. The backend design approach has to change slightly. You're focused less on whole pages and more on individual user interactions. There's room for a tool that will scaffold a Go backend from an Htmx-ified web page IMHO.
- sofixa 6y ago
  > What's the Django/Rails equivalent in Go? Gin-gonic and a few others try to do that job ( and provide the flexibility to plug the missing parts), but a lot of people say the stdlib is sufficient. Depending on the he case, either can work great.
andybak 6y ago
It's more Django than Python specifically. Does Go (genuinely) have something to match?
- andrewzah 6y ago
  > Does Go (genuinely) have something to match? To the extent of django or rail's maturity and features, likely not, although I don't know what features you use django for. I guess this answers my question to an extent. Last time I worked with golang I used gin and xorm, but there were some things I had to manually do. That being said, I find rails to be an enormous beast that provides a lot of things that one may or may not need. In my experience, working with golang and rust, which are compiled and statically/strongly typed have saved me headaches and time even with having to hand-roll some features.
  - uranusjr 6y ago
    It’s often better to have something you may not need than have not something you may need, especially for projects you intend to grow, iterate on, and possibly pivot. If my experience has taught me anything, I can never assume what I don’t need in the future. Most features come with Django and Rails almost for free (the only downside being some additional deployment size), so why not.
- jw14 6y ago
  Never used it but there's a port/clone of Django in Go called Beego (https://beego.me/ https://beego.me/).
- simplecto 6y ago
  You might want to check out https://gobuffalo.io/en https://gobuffalo.io/en
- TameAntelope 6y ago
  The answer is no, and you’re not going to hear it from the Go zealot replying to every comment in this thread. Suggesting Go, given where it is right now, is betraying a lack of experience with at least one critical part of the software development lifecycle.
simplecto 6y ago
Django drives the choice here. Batteries included, huge community support, and AMAZING documentation. Half the software I write is from stackoverflow. LOL I dont see dockerizing as a problem. Once copied out from my template I never think about it. I do admit that familarity with the underlying Image OS (Debian in this case) makes debugging / fussing about a non-issue.
- cbushko 6y ago
  For local development that debian container is fine but for production you want something small like scratch or alpine. The fewer binaries in the container, the better and more secure. This is one of the benefits of golang. You compile it into a binary and copy just the binary into your scratch container. Maybe it is 20MB in size.
  - simplecto 6y ago
    This feels very hand-wavey to me. I can patch and ship my docker images the same way I might patch a server. apt-get update && apt-get upgrade rinse, repeat. Secondly, all this cargo-culting around small containers is fine if you are cramming resources. I am not. The reality is that my projects and many others are really, really over-provisioned. Looking at my graphs right now, I am on the front page of HN and my server load is still only 20%.
    - andrewzah 6y ago
      "apt-get update && apt-get upgrade" You can do this exactly the same in alpine, with "apk update" and "apk add". "Secondly, all this cargo-culting around small containers is fine if you are cramming resources. I am not." The default docker python image is 885MB. python:buster-slim is 114MB which is much more reasonable. Even if you're not "cramming resources", pushing 885MB vs 115MB vs 20MB across the wire does add up over time. In my case, we do quickly iterate and pull docker images so it does make a difference for my colleagues if the image is 30MB vs 500MB. Even if we're all on gigabit internet. "Cargo culting" implies doing it without knowing why we're doing it. The benefits of reducing the size of docker images is apparent to everyone, although there are diminishing returns. With dive[0] it is very easy to figure out where the waste is. "The reality is that my projects and many others are really, really over-provisioned. Looking at my graphs right now, I am on the front page of HN and my server load is still only 20%. " Optimizing docker images has nothing to do with being over-provisioned. I will concede that it's very different as a solo developer vs even a small team. [0]: https://github.com/wagoodman/dive https://github.com/wagoodman/dive
capableweb 6y ago
> I cannot imagine building beyond >1000 LoC in interpreted, dynamically typed languages Many have imagined and built valuable stuff in interpreted, dynamically typed languages before you, by being more focused on overall structure and making sure it's strict and resilient. One really doesn't have to search far for successful applications that are certainly way beyond 1000 LoC and still iterate pretty quickly for their size. > significantly easier to dockerize a generated binary from golang or rust Not sure the verboseness of either golang or rust would be worth it if you compare it with python. If you're just launching, your focus should not be on performance or how easy it is to dockerize but to figure out who your user really is. Scaling and deployment issues will happen much further down the road, and iteration speed is more important in the beginning as you have many changes. Your architecture needs to reflect this too, and dynamically typed languages (arguably) makes it easier to change things, as long as you know what you're doing. But together with that, you are eventually gonna have to start leveraging more languages, as you have programmers working on different levels of the overall architecture. Some fit for some tasks, and when it comes to quickly launching and iterating on SaaS businesses, dynamically typed languages are a pretty good fit. In the end, I don't really think dynamic/static typing is the most important consideration, that's such a small part of what you have to think about overall.
- cbushko 6y ago
  That is a double edged sword. Sure, that dynamically typed language of python or ruby might be quick to develop on but they often contain a lot of surprising bugs. Compilers catch a lot of bugs before your software is in production.
  - CameronNemo 6y ago
    Tests catch bugs too. As will pylint and mypy.
    - mixmastamyk 6y ago
      Even pyflakes will catch the most numerous bugs.
arcturus17 6y ago
> I cannot imagine building beyond >1000 LoC in interpreted, dynamically typed languages That would include Ruby, Python, PHP, and JS. GitHub, Shopify, Wordpress, Instagram, Pinterest, Reddit, significant parts of Netflix (Node), Facebook, just off the top of my head. And you can’t imagine writing > 1000 LOC of a startup SaaS product in any of them? Really?
- andrewzah 6y ago
  Not in 2021, no. I would go with typescript, golang+gin or preferably rust+warp/tide. If you had asked me in 2010, 2015, or even 2018 I would've had different answers most likely. "And you can’t imagine writing > 1000 LOC of a startup SaaS product in any of them? Really? " After working on large rails codebases I get nauseous even thinking about having to safely maintain that level of code in dynamically typed languages.
  - mythrwy 6y ago
    I've worked on a few sizable (~100+ tables) Django Rest applications and have yet to run into all these fabled type safety issues that would prevent refactoring. Serializers and hygienic procedures seem to take care of whatever might have been or maybe I'm just really used to the setup.
  - acdha 6y ago
    > After working on large rails codebases I get nauseous even thinking about having to safely maintain that level of code in dynamically typed languages. I can’t speak to Rails but this is easy in Python - especially because the addition of typing years back now means that a few annotations will cover most of the common mistakes before leaving your editor. In the Django community there’s a healthy distrust for the heavy levels of magic which are harder to test, which helps a lot.
zmmmmm 6y ago
Sounds like you may not be familiar with Django, but it's honestly an amazing option if you want something that's mature, stable, well documented and full stack (the latter being key - one of the only ORMs I don't hate). The biggest problem for Django and Python in general to me is more in the line of the scalability (performance) question. You are simply forced to put one or even two layers in front of it with a multi-process architecture just to get it to a baseline deployable state (in this case, traefik + gunicorn). But the good news is there are so many people doing that it really isn't a problem. And it turns out you probably want that architecture anyway (probably best if your application server isn't also doing your TLS etc).
turtlebits 6y ago
It's most likely because of Django. Same would be for using Ruby for Rails. It's also very unlikely you are going to write >1000 LoC (or honestly even >100 LoC) for any view function/API endpoint.
- lolinder 6y ago
  But how many apps have only one view? That a single view is only 100 lines doesn't solve the maintainability problem when you have dozens of views.
nickthemagicman 6y ago
I'm playing devil's advocate here. But Python has a ton of useful libraries that other languages don't have. I'm fully aware you can access those libraries in a serverless function or via docker. But some people may just want all of that native to the code to keep things super streamlined.
acdha 6y ago
You have to reach massive scale before you’re going to see a significant performance benefit from Go, but you’ll see productivity wins from Django from day one. If you’re not targeting that kind of public scale and don’t have a large team, there’s a lot to be said for picking a mature stack on a high productivity language.
- simplecto 6y ago
  Exactly this. Developers and their managers and the CTO must accept most likely their work/company does operate a huge scale. Once you internalize that your priorities change from all the tech hype (k8s, react, whatever) to actually working on the business problems. Not solving technical ones.
- danjac 6y ago
  And nothing to stop you from breaking out specific services into Go/Rust where you actually need high performance.
- treis 6y ago
  I used to think the same way and still kind of do. But you're neglecting another performance benefit. You have ~100 ms to respond to a request before the user perceives slowness. With Go you can do 10-100x more stuff in that timeframe.
  - acdha 6y ago
    Or 0 to -100x more stuff. The vast, vast majority of code is limited by the application’s workload and architecture, not the language runtime. I remember a colleague spending 3 months trying to beat Python using Go, eking out a single digit increase because it turns out that the Python stdlib C code is not easy to beat. For web apps, this is especially common: if 95% of your runtime is in the database or other external services, Amdahl’s law reigns supreme. The other experience point which a lot of people forget the first few times is maintenance: if using Go means that you have notably more code to write and integration to support, you’re shipping fewer features and have less time to optimize the architecture. That Go code I mentioned earlier was much larger and required time to identify, integrate, and debug third-party libraries for things which are in the Python standard library. This isn’t to say that Go is a bad choice but again a cue to make sure you’re solving the problems you actually have rather than someone else’s situation. If you’re still exploring the business case you should hesitate before copying a decision made by someone with both a well understood problem, large scale, and more people working on it. In this thread’s context, I would highly recommend focusing on keeping the architecture easy to support and replace components when the business expands to the point where you really need to hammer specific optimizations. This is especially true in the 2020s where a large fraction of problems are either never exceeding single server scale or can be handled by trivially autoscaling containers on-demand for less than it’d cost in developer time to optimize them beyond the level you can hit in a language like Python or Node. Again, that doesn’t mean there’s anything wrong with using Go – it’s a perfectly fine choice and has some great libraries — but it usually won’t be transformative the way some advocates claim. When you hear about huge benefits from rewrites look for how often they mention rearchitecting based on what they’d learned from the first system.
AYBABTME 6y ago
Developing apps in Go is not a high productivity experience, compared to Rails or Django. The framework ecosystem isn't comparable, and you DIY a lot of stuff. I'm saying this in complete self contradiction: my current stack is Next.js with Go/gRPC Web/sqlboiler
AlchemistCamp 6y ago
> I previously worked heavily with ruby and I cannot imagine building beyond >1000 LoC in interpreted, dynamically typed languages. Airbnb, Stripe, WhatsApp and Discord were able to and win in gigantic markets despite fierce competition.
Glyptodon 6y ago
It's very easy to have pretty painless RoR codebases above 1000 LoC without any challenges or problems...
neurostimulant 6y ago
Honestly, django is the only thing that keeps me on python for backend service. With microservice being all the rage these days, I don't see any battery-included framework that can rival django emerging in golang, rust, swift and other new and hip languages.
jgb1984 6y ago
I've been writing python for a living for about 13 years now. I've dabbled in go, but found it incredibly verbose and of a much lower level than python. The error handling alone is enough to turn me off completely. So much boilerplate, so much code and words to express even simple things. No thanks, I'll stick with python, for me it is the perfect balance between expressiveness and being easy to read. Also Django itself and the python ecosystem is hard to beat. It gets out of my way so that I can focus on the business logic, instead of reinventing wheels.
mixmastamyk 6y ago
If compute performance is not a requirement, python is a lot faster to develop in. Once the design has solidified, a few simple techniques can improve reliability to an acceptable degree.

Nextgrid 6y ago

What's the Django/Rails equivalent in Go? The value from Python isn't Python itself (though it might be easier to write in - trading off reliability for ease of use compared to a compiled language) but the ecosystem. Fully-featured frameworks such as Django, Rails, etc give you lots of functionality out of the box which is very valuable especially at the early stages of the project where performance isn't a concern yet.

andrewzah 6y ago
"(though it might be easier to write in - trading off reliability for ease of use compared to a compiled language)" I find the "ease" is overstated compared to time spent debugging issues in production, but that is a separate discussion. See my comment in the sister thread about the django/rails equivalent.
rufius 6y ago
Honestly, frameworks like Rails or Django are an anti-pattern for Golang. The standard library makes it very easy to build web services and there’s a couple or popular packages for making routes and dealing with HTTP requests/responses simple. There’s projects like Micro that try to do a little more batteries included but I wouldn’t consider them to be pervasive in the way Django or Rails are. Beyond that, it’s just app logic and the typical Golang boiler plate. Source: I’ve built a few big Golang services for a couple companies.
- sk5t 6y ago
  Contrary perspective: only avoid frameworks when you can be assured your project is (and will remain) so narrow that it has no need of validation libraries and the like.
- treis 6y ago
  >Honestly, frameworks like Rails or Django are an anti-pattern for Golang. Which is, IMHO, the biggest thing holding Go back. The standard library does a lot but a lot is also missing. Authentication, db migration, admin panels, ORM, Asset pipeline and probably more. It's a lot of custom work to do or pulling in various libraries.
  - CameronNemo 6y ago
    I don't think Go will see something even close to Django until generics are merged.
  - rufius 6y ago
    I have mixed feelings on this. I go back and forth on whether I agree or disagree. For example, once an application becomes sufficiently complex, I've found ORM's to be more of a hindrance. The abstraction gets leaky and I end up having to tune custom queries to get around some pathological edge case. That said - most of my experience is with Rails and a lot of the implicit nature of it is problematic. On the other hand, I've not had this experience with Laravel. Which one is right? I dunno. Lately though, writing sizable web applications in Golang is working out well so I guess I'll keep doing that.
    - leetrout 6y ago
      Rails implicit magic is so painful. I’ll disagree and agree on the ORM front. A good ORM has a clean escape handle for tuning hot spots and otherwise saves you time with boilerplate queries. Add a new field? Update the class / structs, generate a migration and move on. Without the ORM you write the migration yourself, you have to find and update all the queries and if you’re centralizing all your query building then you’re just using your own ORM-light without the battle hardened trials of other users using something open source and popular. I insisted we use sql alchemy and alembic in our latest Go project — and I’m eyeballing Buffalo’s Soda and Fizz as a replacement. Its generally just nerdcore navel gazing to insist on raw sql across a project in my opinion. Especially web apps / SaaS where you churn tables a lot. Simple migrations from simple models is what I love about Django and Flask/Fast API with SQL Alchemy.
kitd 6y ago
I think if you're using Htmx/Intercooler with Golang, you'd probably want to take a different approach from Django anyway. The backend design approach has to change slightly. You're focused less on whole pages and more on individual user interactions. There's room for a tool that will scaffold a Go backend from an Htmx-ified web page IMHO.
sofixa 6y ago
> What's the Django/Rails equivalent in Go? Gin-gonic and a few others try to do that job ( and provide the flexibility to plug the missing parts), but a lot of people say the stdlib is sufficient. Depending on the he case, either can work great.

andybak 6y ago

It's more Django than Python specifically. Does Go (genuinely) have something to match?

andrewzah 6y ago
> Does Go (genuinely) have something to match? To the extent of django or rail's maturity and features, likely not, although I don't know what features you use django for. I guess this answers my question to an extent. Last time I worked with golang I used gin and xorm, but there were some things I had to manually do. That being said, I find rails to be an enormous beast that provides a lot of things that one may or may not need. In my experience, working with golang and rust, which are compiled and statically/strongly typed have saved me headaches and time even with having to hand-roll some features.
- uranusjr 6y ago
  It’s often better to have something you may not need than have not something you may need, especially for projects you intend to grow, iterate on, and possibly pivot. If my experience has taught me anything, I can never assume what I don’t need in the future. Most features come with Django and Rails almost for free (the only downside being some additional deployment size), so why not.
jw14 6y ago
Never used it but there's a port/clone of Django in Go called Beego (https://beego.me/ https://beego.me/).
simplecto 6y ago
You might want to check out https://gobuffalo.io/en https://gobuffalo.io/en
TameAntelope 6y ago
The answer is no, and you’re not going to hear it from the Go zealot replying to every comment in this thread. Suggesting Go, given where it is right now, is betraying a lack of experience with at least one critical part of the software development lifecycle.

simplecto 6y ago

Django drives the choice here. Batteries included, huge community support, and AMAZING documentation. Half the software I write is from stackoverflow. LOL I dont see dockerizing as a problem. Once copied out from my template I never think about it. I do admit that familarity with the underlying Image OS (Debian in this case) makes debugging / fussing about a non-issue.

cbushko 6y ago
For local development that debian container is fine but for production you want something small like scratch or alpine. The fewer binaries in the container, the better and more secure. This is one of the benefits of golang. You compile it into a binary and copy just the binary into your scratch container. Maybe it is 20MB in size.
- simplecto 6y ago
  This feels very hand-wavey to me. I can patch and ship my docker images the same way I might patch a server. apt-get update && apt-get upgrade rinse, repeat. Secondly, all this cargo-culting around small containers is fine if you are cramming resources. I am not. The reality is that my projects and many others are really, really over-provisioned. Looking at my graphs right now, I am on the front page of HN and my server load is still only 20%.
  - andrewzah 6y ago
    "apt-get update && apt-get upgrade" You can do this exactly the same in alpine, with "apk update" and "apk add". "Secondly, all this cargo-culting around small containers is fine if you are cramming resources. I am not." The default docker python image is 885MB. python:buster-slim is 114MB which is much more reasonable. Even if you're not "cramming resources", pushing 885MB vs 115MB vs 20MB across the wire does add up over time. In my case, we do quickly iterate and pull docker images so it does make a difference for my colleagues if the image is 30MB vs 500MB. Even if we're all on gigabit internet. "Cargo culting" implies doing it without knowing why we're doing it. The benefits of reducing the size of docker images is apparent to everyone, although there are diminishing returns. With dive[0] it is very easy to figure out where the waste is. "The reality is that my projects and many others are really, really over-provisioned. Looking at my graphs right now, I am on the front page of HN and my server load is still only 20%. " Optimizing docker images has nothing to do with being over-provisioned. I will concede that it's very different as a solo developer vs even a small team. [0]: https://github.com/wagoodman/dive https://github.com/wagoodman/dive

capableweb 6y ago

> I cannot imagine building beyond >1000 LoC in interpreted, dynamically typed languages Many have imagined and built valuable stuff in interpreted, dynamically typed languages before you, by being more focused on overall structure and making sure it's strict and resilient. One really doesn't have to search far for successful applications that are certainly way beyond 1000 LoC and still iterate pretty quickly for their size. > significantly easier to dockerize a generated binary from golang or rust Not sure the verboseness of either golang or rust would be worth it if you compare it with python. If you're just launching, your focus should not be on performance or how easy it is to dockerize but to figure out who your user really is. Scaling and deployment issues will happen much further down the road, and iteration speed is more important in the beginning as you have many changes. Your architecture needs to reflect this too, and dynamically typed languages (arguably) makes it easier to change things, as long as you know what you're doing. But together with that, you are eventually gonna have to start leveraging more languages, as you have programmers working on different levels of the overall architecture. Some fit for some tasks, and when it comes to quickly launching and iterating on SaaS businesses, dynamically typed languages are a pretty good fit. In the end, I don't really think dynamic/static typing is the most important consideration, that's such a small part of what you have to think about overall.

cbushko 6y ago
That is a double edged sword. Sure, that dynamically typed language of python or ruby might be quick to develop on but they often contain a lot of surprising bugs. Compilers catch a lot of bugs before your software is in production.
- CameronNemo 6y ago
  Tests catch bugs too. As will pylint and mypy.
  - mixmastamyk 6y ago
    Even pyflakes will catch the most numerous bugs.

arcturus17 6y ago

> I cannot imagine building beyond >1000 LoC in interpreted, dynamically typed languages That would include Ruby, Python, PHP, and JS. GitHub, Shopify, Wordpress, Instagram, Pinterest, Reddit, significant parts of Netflix (Node), Facebook, just off the top of my head. And you can’t imagine writing > 1000 LOC of a startup SaaS product in any of them? Really?

andrewzah 6y ago
Not in 2021, no. I would go with typescript, golang+gin or preferably rust+warp/tide. If you had asked me in 2010, 2015, or even 2018 I would've had different answers most likely. "And you can’t imagine writing > 1000 LOC of a startup SaaS product in any of them? Really? " After working on large rails codebases I get nauseous even thinking about having to safely maintain that level of code in dynamically typed languages.
- mythrwy 6y ago
  I've worked on a few sizable (~100+ tables) Django Rest applications and have yet to run into all these fabled type safety issues that would prevent refactoring. Serializers and hygienic procedures seem to take care of whatever might have been or maybe I'm just really used to the setup.
- acdha 6y ago
  > After working on large rails codebases I get nauseous even thinking about having to safely maintain that level of code in dynamically typed languages. I can’t speak to Rails but this is easy in Python - especially because the addition of typing years back now means that a few annotations will cover most of the common mistakes before leaving your editor. In the Django community there’s a healthy distrust for the heavy levels of magic which are harder to test, which helps a lot.

zmmmmm 6y ago

Sounds like you may not be familiar with Django, but it's honestly an amazing option if you want something that's mature, stable, well documented and full stack (the latter being key - one of the only ORMs I don't hate). The biggest problem for Django and Python in general to me is more in the line of the scalability (performance) question. You are simply forced to put one or even two layers in front of it with a multi-process architecture just to get it to a baseline deployable state (in this case, traefik + gunicorn). But the good news is there are so many people doing that it really isn't a problem. And it turns out you probably want that architecture anyway (probably best if your application server isn't also doing your TLS etc).

turtlebits 6y ago

It's most likely because of Django. Same would be for using Ruby for Rails. It's also very unlikely you are going to write >1000 LoC (or honestly even >100 LoC) for any view function/API endpoint.

lolinder 6y ago
But how many apps have only one view? That a single view is only 100 lines doesn't solve the maintainability problem when you have dozens of views.

nickthemagicman 6y ago

I'm playing devil's advocate here. But Python has a ton of useful libraries that other languages don't have. I'm fully aware you can access those libraries in a serverless function or via docker. But some people may just want all of that native to the code to keep things super streamlined.

acdha 6y ago

You have to reach massive scale before you’re going to see a significant performance benefit from Go, but you’ll see productivity wins from Django from day one. If you’re not targeting that kind of public scale and don’t have a large team, there’s a lot to be said for picking a mature stack on a high productivity language.

simplecto 6y ago
Exactly this. Developers and their managers and the CTO must accept most likely their work/company does operate a huge scale. Once you internalize that your priorities change from all the tech hype (k8s, react, whatever) to actually working on the business problems. Not solving technical ones.
danjac 6y ago
And nothing to stop you from breaking out specific services into Go/Rust where you actually need high performance.
treis 6y ago
I used to think the same way and still kind of do. But you're neglecting another performance benefit. You have ~100 ms to respond to a request before the user perceives slowness. With Go you can do 10-100x more stuff in that timeframe.
- acdha 6y ago
  Or 0 to -100x more stuff. The vast, vast majority of code is limited by the application’s workload and architecture, not the language runtime. I remember a colleague spending 3 months trying to beat Python using Go, eking out a single digit increase because it turns out that the Python stdlib C code is not easy to beat. For web apps, this is especially common: if 95% of your runtime is in the database or other external services, Amdahl’s law reigns supreme. The other experience point which a lot of people forget the first few times is maintenance: if using Go means that you have notably more code to write and integration to support, you’re shipping fewer features and have less time to optimize the architecture. That Go code I mentioned earlier was much larger and required time to identify, integrate, and debug third-party libraries for things which are in the Python standard library. This isn’t to say that Go is a bad choice but again a cue to make sure you’re solving the problems you actually have rather than someone else’s situation. If you’re still exploring the business case you should hesitate before copying a decision made by someone with both a well understood problem, large scale, and more people working on it. In this thread’s context, I would highly recommend focusing on keeping the architecture easy to support and replace components when the business expands to the point where you really need to hammer specific optimizations. This is especially true in the 2020s where a large fraction of problems are either never exceeding single server scale or can be handled by trivially autoscaling containers on-demand for less than it’d cost in developer time to optimize them beyond the level you can hit in a language like Python or Node. Again, that doesn’t mean there’s anything wrong with using Go – it’s a perfectly fine choice and has some great libraries — but it usually won’t be transformative the way some advocates claim. When you hear about huge benefits from rewrites look for how often they mention rearchitecting based on what they’d learned from the first system.

AYBABTME 6y ago

Developing apps in Go is not a high productivity experience, compared to Rails or Django. The framework ecosystem isn't comparable, and you DIY a lot of stuff. I'm saying this in complete self contradiction: my current stack is Next.js with Go/gRPC Web/sqlboiler

AlchemistCamp 6y ago

> I previously worked heavily with ruby and I cannot imagine building beyond >1000 LoC in interpreted, dynamically typed languages. Airbnb, Stripe, WhatsApp and Discord were able to and win in gigantic markets despite fierce competition.

Glyptodon 6y ago

It's very easy to have pretty painless RoR codebases above 1000 LoC without any challenges or problems...

neurostimulant 6y ago

Honestly, django is the only thing that keeps me on python for backend service. With microservice being all the rage these days, I don't see any battery-included framework that can rival django emerging in golang, rust, swift and other new and hip languages.

jgb1984 6y ago

I've been writing python for a living for about 13 years now. I've dabbled in go, but found it incredibly verbose and of a much lower level than python. The error handling alone is enough to turn me off completely. So much boilerplate, so much code and words to express even simple things. No thanks, I'll stick with python, for me it is the perfect balance between expressiveness and being easy to read. Also Django itself and the python ecosystem is hard to beat. It gets out of my way so that I can focus on the business logic, instead of reinventing wheels.

mixmastamyk 6y ago

If compute performance is not a requirement, python is a lot faster to develop in. Once the design has solidified, a few simple techniques can improve reliability to an acceptable degree.