12 ms·

> Even if they do need to serve tons of requests per second, it's totally reasonable for them to still choose Python/Gunicorn if the cost of the additional serv

> Even if they do need to serve tons of requests per second, it's totally reasonable for them to still choose Python/Gunicorn if the cost of the additional servers is less than the cost of having to support multiple languages. How hard is it to get up to speed on any other tech stack? ASP.NET Core is extremely fast and the learning curve is close to none, for example. If someone was able to wrap his head around backend development with Python I'm pretty sure they have the mental fortitude to onboard a tech stack that doesn't suffer from major performance problems.

stev_stev 6y ago
This is where my head always goes as someone who does mostly Asp.Net Core. Why is it always between something like C++ or something like Python? Nowadays with middleware and endpoint routing, asp.net core can be almost as simple as flask (even if that’s not idiomatic or what the docs show you).
- flyinglizard 6y ago
  Or Azure Functions if you want to go the serverless route. Coupled with Visual Studio, you can build high quality, large scale apps at about the same effort of blinking a LED on Arduino.
  - freeone3000 6y ago
    Are we using the same Azure Functions? I spend more time messing with functions.json and determining binding types and waiting five minutes for error messages to come in than I ever did when I simply provisioned an app service and deployed code.
    - deleted 6y ago
      [deleted]
    - xeroalt 6y ago
      Feel the same way with lambda.
- xeroalt 6y ago
  I’m most comfortable in .net core but I recently learned Django because I kept hearing how productive it was from HN and all the startups around me use it, but Im starting to feel like I chose to move the wrong way. I will say I like how Postgres is the default for python and the library situation is much better over there as well.
  - thdrdt 6y ago
    I am a little confused by your post. Moving to Django is the wrong way?
    - xeroalt 6y ago
      Yeah Django feels terrible to me compared to .net core. I already wrote a similar answer to someone else so I will just paste it here "The developer experience in python was just way worse for me. Autogenerating swagger docs didn't seem possible without manually adding annotations to all my code (for flask at least), the battle-tested python libraries like django and sqlalchemy aren't built for async, mypy is obviously way worse than an actual type system and having static types really helps with understanding a large new code base, model validation (the thing forms/serializers handle) was more tedious, vscode was worse than visual studio (code navigation was very hard to do in python. I could jump 1 layer into library code, but when I tried to jump deeper vscode couldn't find anything.)" I've seen people say you should only choose rails or django for a startup, but .net core mvc provides the same batteries included approach and is built with the modern web ecosystem in mind. It also runs on linux and easily integrates with postgres so its just as cheap now as well. I think people that write off C# haven't really worked with it in its present form. I didn't find python significantly more terse than C# (other than having to define properties on types, which I already stated I prefer), just less feature rich.
  - pdonis 6y ago
    I've tried working with Django and it's always seemed much too heavyweight to me. Flask is my preferred web framework for Python; much easier for me to use and feels like it's helping me where needed and getting out of my way where needed, not weighing me down.
- pjmlp 6y ago
  Same here, for me it has been mostly about .NET, Java or anything else with JIT/AOT compilers out of the box, after my AOLServer like experience. Back then we already had Zope and it wasn't blazing fast.
turtlebits 6y ago
I disagree. I tried to learn F# a few months ago and the experience was horrible. I followed the tutorial using the aspnet CLI tool and got nothing but errors. I Google’d for a while until I gave up.
- jdc 6y ago
  Can you link to the tutorial you followed?
- tasogare 6y ago
  Of course it’s gonna be hard if you are trying to learn a language plus a framework at the same time, especially given that F# is treated as a second class citizen by Microsoft. An easier path is to break that learning into more manageable tasks: on one hand getting familiar with F# (which is already some work as it has both a functional side, and a CLR one; you need more the OOP part for doing ASP.net) and in the other ASP.net, for which the golden road is C#. Otherwise the doc is quite good for ASP.net Core, and it’s rare I get stuck on a problem for too long with it.
- rumanator 6y ago
  > I tried to learn F# a few months ago and the experience was horrible. Switching to a programmig language based on an entirely different programming paradigm is not comparable to switching to a language based on the exact same programming paradigm to develop the exact same application using the exact same design patterns.
  - turtlebits 6y ago
    I’m completely comfortable with the language coming from Elixir. The problem was the tooling/docs didn’t match the experience. This was from the official site and many of the commands threw errors. I think it was a case of incomplete Mac support, which should have been called out. IIRC I posted on HN about it and got an apology for the state of tooling
hedora 6y ago
> How hard is it to get up to speed on any other tech stack? If I find myself debugging python tools, I usually just add debug statements to figure out WTF it is trying to do, and reimplement it in bash. It invariably is less than 10% as many lines of code, and also more debuggable / readable than the original. Granted, most of the python scripts I see these days are build processes or cluster coordinators.
- EdwardDiego 6y ago
  > reimplement it in bash > more debuggable / readable More debuggable / readable for you, perhaps.
  - arpa 6y ago
    Hey, for me too. But then again I used to write bash frameworks for fun so there's that.
- pjc50 6y ago
  Given how badly bash goes wrong if spaces in filenames sneak in, or if you want to do error handling, at several places I've had a policy of rewriting scripts from bash into python. It has the advantage that it's usually a better cross-platform solution than running bash on Windows.
heelix 6y ago
I'll find out myself. Just got handed a codebase that is a mix of Python/Gunicorn/node when this sprint started off. I've seen the word gunicorn in the repo... but still don't know what it does yet. First time for this old back end Java/C++/XQuery programmer, so how hard can it be? (On the plus side, seems my Jetbrain kit includes PyCharm, so I've even got an IDE!)
- neurostimulant 6y ago
  Gunicorn is just a WSGI server, basically used to spawn a pool of webserver processes for your python backend. A python webserver is more optimal when used in multiprocess configuration (as opposed to multithreaded configuration, where python sorely suck at), and gunicorn will do that for you automatically, routing each http request to available worker process in the pool.
  - pdonis 6y ago
    > Gunicorn is just a WSGI server, basically used to spawn a pool of webserver processes for your python backend. Or a pool of asynchronous "green threads" using any of a number of libraries (gevent is the one I'm most familiar with). The thing to avoid is mixing the two (multiple processes and green threads). > A python webserver is more optimal when used in multiprocess configuration For CPU bound worker tasks, yes, this is true. For I/O bound applications, not so much; asynchronous I/O can handle the same I/O load with much fewer resources (particularly as forking Python processes uses a lot more memory because so much of the memory in the Python interpreter is dynamic, so you don't get a lot of benefit from what in a compiled language would be shared read-only code that doesn't need to be copied for every fork). > (as opposed to multithreaded configuration, where python sorely suck at) Yes, the limitation of the GIL is one of Python's worst warts. (It looks like there are finally efforts to remove it, but it's taken a long, long time.)
    - neurostimulant 6y ago
      Ah yes, I haven't used gevent for years and now associate gunicorn with wsgi. I have far easier experience with nodejs and golang when I need to do async parts on the backend (usually for websocket stuff), then use some message queue/passing system with celery or zeromq to communicate back and forth with the python backend.
deleted 6y ago
[deleted]
neurostimulant 6y ago
That's because I'm more productive with Python (been using it for ten years to implement many backend services), never hit any of its performance limitation yet (I mostly use it to develop b2b app with medium traffic at most, and always leverage distributed task queue for anything that might excessively blocks the webserver process), and also didn't want to maintain a fleet of windows servers (at least in the past when .net was windows only).
PeterisP 6y ago
It does not take that much time to get up to speed on another tech stack, but it does take some time, and servers are really cheap. Even if the learning curve is close to none, it's just cheaper to rent a dozen machines than have an engineering team spend a day or two looking into a new ecosystem.
pmoleri 6y ago
Learning curve close to none? I like that many times there's "the way" of doing things, but when I have to do something slightly outside the recommended way, I feel that the effort required outweights all the benefits.
- rumanator 6y ago
  Isn't that true for all frameworks?
- tarsinge 6y ago
  “The way” of doing things depends on the language, and for example for me Python is very hard. It’s not my main stack but I use it regularly and after years I still can’t find "the way" of doing things by myself, I feel like I end up on stackoverflow way too often because of anxiety of not being idiomatic. It’s like there is an enormous meta knowledge very specific to the language. That’s not something I experience with other stacks.
29athrowaway 6y ago
1) .NET APIs change very frequently. 2) C# is a very verbose language, that requires a lot of typing. 3) F#, the best language in .NET, is largely ignored by the .NET community.
- EdwardDiego 6y ago
  I can't speak from recent experience, but on point 1) when I was teaching myself to code, I focused on .NET due to its prevalence in my local market. I took part in the .NET user group (called DUG, natch), attended the meetups etc. And this was at the time when MS would announce a new blessed way to do things on a reasonably frequent basis. When I started, the blessed way to access data was DAOs, then it was ADO.NET (note, those could be around the wrong way, I have trouble figuring it out now in hindsight), then it was Linq2Sql, then that was deprecated for Entity Framework (which, I'll give credit, they seem to have stuck with, even if it does feel like a half-cribbed NHibernate). I was frantically trying to learn the blessed thing, because the MS shops I was familiar with only used the blessed thing - the server was IIS, the database was SQL Server, the language was C# (I was the only member of the DUG who coded in F#, and few others knew of it), and you used the blessed patterns and the blessed frameworks. Incidentally, this is why FOSS has had such a hard time in .NET, as soon as MS releases something that is reasonably feature complete, a lot of single-vendor minded companies switch to it. And I met a lot of developers in their early 40s who were quietly terrified of getting left behind on the MS technology treadmill, and trying just as frantically to learn the new blessed thing as I was. And then I got hired by a Java shop, and faced a paradigm where shit code cough java.util.Calendar, java.util.Date cough stuck around for yonks because it was good enough and replacing it had to be done very thoughtfully and gently. Point #2 isn't super relevant in the age of IDEs, but I agree wholeheartedly that F# deserves a lot more love than it gets.
- rumanator 6y ago
  > 1) .NET APIs change very frequently. ASP.NET Core 2.1 was released in 2018 and will be supported until late 2021. ASP.NET Core 3.1 was released a few months ago and there is no end of support in sight. Moreover, the changes between 2.1 and 3.1 were not that many. I've migrated a whole ASP.NET Core 2.1 web service to 3.1 in less than 1 hour. > 2) C# is a very verbose language, that requires a lot of typing. Nonsense. The only added verbosity to C# when compared with Python are the type declarations, which arguably are a problem plaguing Python. The first class support for events and async programming and properties in C# more than make up for it. > 3) F#, the best language in .NET, is largely ignored by the .NET community. I fail to see what point you were trying to make.
vidarh 6y ago
A lot of developers never get proficient on one stack. Much less more than one.
- rumanator 6y ago
  You don't need to master one stack to get up to speed. For that investment to pay off you only need to be almost as good as you were with your old stack, which isn't hard if you already are not proficient.
  - vidarh 6y ago
    I'd argue that time would be better spent actually learning any single stack properly.
tetha 6y ago
Writing code is one thing though. Now you have to figure out how to run a CI on a build server. Deployment on your production systems, be it containers or even not. Monitoring, alerting, profiling, tuning under load. You have to support a new database connection library with new shenanigans. In general, you need to integrate the new language into the existing ecosystem. The latter may even be impossible depending on the stack and solution chosen. Just look up those weird Java only caching servers. All of that is possible, sure. Due to company acquisitions and specialized teams in some areas, we're kinda running the full bingo card of languages. But there's little denying: We overall spent less time handling language runtimes and language-specific monitoring back when we were java+mysql and that's it.
- rumanator 6y ago
  > Now you have to figure out how to run a CI on a build server. Deployment on your production systems, be it containers or even not. Monitoring, alerting, profiling, tuning under load. You have to support a new database connection library with new shenanigans. Most if not all of those items are either trivial or non-issues. In fact, I would argue that deploying a Python app is a far more convoluted process than getting an ASP.NET Core app up and running. With Docker, the problem simply disappears. Getting it to build and test on a CICD pipeline is as hard as typing $ dotnet build, or $ dotnet test. > All of that is possible, sure. Not only it is possible, it's laughably easy. We are supposed to avoid our problems, not perpetuate and aggravate them as eternum because we are too lazy to look for ways to make our life easier.

stev_stev 6y ago

This is where my head always goes as someone who does mostly Asp.Net Core. Why is it always between something like C++ or something like Python? Nowadays with middleware and endpoint routing, asp.net core can be almost as simple as flask (even if that’s not idiomatic or what the docs show you).

flyinglizard 6y ago
Or Azure Functions if you want to go the serverless route. Coupled with Visual Studio, you can build high quality, large scale apps at about the same effort of blinking a LED on Arduino.
- freeone3000 6y ago
  Are we using the same Azure Functions? I spend more time messing with functions.json and determining binding types and waiting five minutes for error messages to come in than I ever did when I simply provisioned an app service and deployed code.
  - deleted 6y ago
    [deleted]
  - xeroalt 6y ago
    Feel the same way with lambda.
xeroalt 6y ago
I’m most comfortable in .net core but I recently learned Django because I kept hearing how productive it was from HN and all the startups around me use it, but Im starting to feel like I chose to move the wrong way. I will say I like how Postgres is the default for python and the library situation is much better over there as well.
- thdrdt 6y ago
  I am a little confused by your post. Moving to Django is the wrong way?
  - xeroalt 6y ago
    Yeah Django feels terrible to me compared to .net core. I already wrote a similar answer to someone else so I will just paste it here "The developer experience in python was just way worse for me. Autogenerating swagger docs didn't seem possible without manually adding annotations to all my code (for flask at least), the battle-tested python libraries like django and sqlalchemy aren't built for async, mypy is obviously way worse than an actual type system and having static types really helps with understanding a large new code base, model validation (the thing forms/serializers handle) was more tedious, vscode was worse than visual studio (code navigation was very hard to do in python. I could jump 1 layer into library code, but when I tried to jump deeper vscode couldn't find anything.)" I've seen people say you should only choose rails or django for a startup, but .net core mvc provides the same batteries included approach and is built with the modern web ecosystem in mind. It also runs on linux and easily integrates with postgres so its just as cheap now as well. I think people that write off C# haven't really worked with it in its present form. I didn't find python significantly more terse than C# (other than having to define properties on types, which I already stated I prefer), just less feature rich.
- pdonis 6y ago
  I've tried working with Django and it's always seemed much too heavyweight to me. Flask is my preferred web framework for Python; much easier for me to use and feels like it's helping me where needed and getting out of my way where needed, not weighing me down.
pjmlp 6y ago
Same here, for me it has been mostly about .NET, Java or anything else with JIT/AOT compilers out of the box, after my AOLServer like experience. Back then we already had Zope and it wasn't blazing fast.

turtlebits 6y ago

I disagree. I tried to learn F# a few months ago and the experience was horrible. I followed the tutorial using the aspnet CLI tool and got nothing but errors. I Google’d for a while until I gave up.

jdc 6y ago
Can you link to the tutorial you followed?
tasogare 6y ago
Of course it’s gonna be hard if you are trying to learn a language plus a framework at the same time, especially given that F# is treated as a second class citizen by Microsoft. An easier path is to break that learning into more manageable tasks: on one hand getting familiar with F# (which is already some work as it has both a functional side, and a CLR one; you need more the OOP part for doing ASP.net) and in the other ASP.net, for which the golden road is C#. Otherwise the doc is quite good for ASP.net Core, and it’s rare I get stuck on a problem for too long with it.
rumanator 6y ago
> I tried to learn F# a few months ago and the experience was horrible. Switching to a programmig language based on an entirely different programming paradigm is not comparable to switching to a language based on the exact same programming paradigm to develop the exact same application using the exact same design patterns.
- turtlebits 6y ago
  I’m completely comfortable with the language coming from Elixir. The problem was the tooling/docs didn’t match the experience. This was from the official site and many of the commands threw errors. I think it was a case of incomplete Mac support, which should have been called out. IIRC I posted on HN about it and got an apology for the state of tooling

hedora 6y ago

> How hard is it to get up to speed on any other tech stack? If I find myself debugging python tools, I usually just add debug statements to figure out WTF it is trying to do, and reimplement it in bash. It invariably is less than 10% as many lines of code, and also more debuggable / readable than the original. Granted, most of the python scripts I see these days are build processes or cluster coordinators.

EdwardDiego 6y ago
> reimplement it in bash > more debuggable / readable More debuggable / readable for you, perhaps.
- arpa 6y ago
  Hey, for me too. But then again I used to write bash frameworks for fun so there's that.
pjc50 6y ago
Given how badly bash goes wrong if spaces in filenames sneak in, or if you want to do error handling, at several places I've had a policy of rewriting scripts from bash into python. It has the advantage that it's usually a better cross-platform solution than running bash on Windows.

heelix 6y ago

I'll find out myself. Just got handed a codebase that is a mix of Python/Gunicorn/node when this sprint started off. I've seen the word gunicorn in the repo... but still don't know what it does yet. First time for this old back end Java/C++/XQuery programmer, so how hard can it be? (On the plus side, seems my Jetbrain kit includes PyCharm, so I've even got an IDE!)

neurostimulant 6y ago
Gunicorn is just a WSGI server, basically used to spawn a pool of webserver processes for your python backend. A python webserver is more optimal when used in multiprocess configuration (as opposed to multithreaded configuration, where python sorely suck at), and gunicorn will do that for you automatically, routing each http request to available worker process in the pool.
- pdonis 6y ago
  > Gunicorn is just a WSGI server, basically used to spawn a pool of webserver processes for your python backend. Or a pool of asynchronous "green threads" using any of a number of libraries (gevent is the one I'm most familiar with). The thing to avoid is mixing the two (multiple processes and green threads). > A python webserver is more optimal when used in multiprocess configuration For CPU bound worker tasks, yes, this is true. For I/O bound applications, not so much; asynchronous I/O can handle the same I/O load with much fewer resources (particularly as forking Python processes uses a lot more memory because so much of the memory in the Python interpreter is dynamic, so you don't get a lot of benefit from what in a compiled language would be shared read-only code that doesn't need to be copied for every fork). > (as opposed to multithreaded configuration, where python sorely suck at) Yes, the limitation of the GIL is one of Python's worst warts. (It looks like there are finally efforts to remove it, but it's taken a long, long time.)
  - neurostimulant 6y ago
    Ah yes, I haven't used gevent for years and now associate gunicorn with wsgi. I have far easier experience with nodejs and golang when I need to do async parts on the backend (usually for websocket stuff), then use some message queue/passing system with celery or zeromq to communicate back and forth with the python backend.

deleted 6y ago

[deleted]

neurostimulant 6y ago

That's because I'm more productive with Python (been using it for ten years to implement many backend services), never hit any of its performance limitation yet (I mostly use it to develop b2b app with medium traffic at most, and always leverage distributed task queue for anything that might excessively blocks the webserver process), and also didn't want to maintain a fleet of windows servers (at least in the past when .net was windows only).

PeterisP 6y ago

It does not take that much time to get up to speed on another tech stack, but it does take some time, and servers are really cheap. Even if the learning curve is close to none, it's just cheaper to rent a dozen machines than have an engineering team spend a day or two looking into a new ecosystem.

pmoleri 6y ago

Learning curve close to none? I like that many times there's "the way" of doing things, but when I have to do something slightly outside the recommended way, I feel that the effort required outweights all the benefits.

rumanator 6y ago
Isn't that true for all frameworks?
tarsinge 6y ago
“The way” of doing things depends on the language, and for example for me Python is very hard. It’s not my main stack but I use it regularly and after years I still can’t find "the way" of doing things by myself, I feel like I end up on stackoverflow way too often because of anxiety of not being idiomatic. It’s like there is an enormous meta knowledge very specific to the language. That’s not something I experience with other stacks.

29athrowaway 6y ago

1) .NET APIs change very frequently. 2) C# is a very verbose language, that requires a lot of typing. 3) F#, the best language in .NET, is largely ignored by the .NET community.

EdwardDiego 6y ago
I can't speak from recent experience, but on point 1) when I was teaching myself to code, I focused on .NET due to its prevalence in my local market. I took part in the .NET user group (called DUG, natch), attended the meetups etc. And this was at the time when MS would announce a new blessed way to do things on a reasonably frequent basis. When I started, the blessed way to access data was DAOs, then it was ADO.NET (note, those could be around the wrong way, I have trouble figuring it out now in hindsight), then it was Linq2Sql, then that was deprecated for Entity Framework (which, I'll give credit, they seem to have stuck with, even if it does feel like a half-cribbed NHibernate). I was frantically trying to learn the blessed thing, because the MS shops I was familiar with only used the blessed thing - the server was IIS, the database was SQL Server, the language was C# (I was the only member of the DUG who coded in F#, and few others knew of it), and you used the blessed patterns and the blessed frameworks. Incidentally, this is why FOSS has had such a hard time in .NET, as soon as MS releases something that is reasonably feature complete, a lot of single-vendor minded companies switch to it. And I met a lot of developers in their early 40s who were quietly terrified of getting left behind on the MS technology treadmill, and trying just as frantically to learn the new blessed thing as I was. And then I got hired by a Java shop, and faced a paradigm where shit code cough java.util.Calendar, java.util.Date cough stuck around for yonks because it was good enough and replacing it had to be done very thoughtfully and gently. Point #2 isn't super relevant in the age of IDEs, but I agree wholeheartedly that F# deserves a lot more love than it gets.
rumanator 6y ago
> 1) .NET APIs change very frequently. ASP.NET Core 2.1 was released in 2018 and will be supported until late 2021. ASP.NET Core 3.1 was released a few months ago and there is no end of support in sight. Moreover, the changes between 2.1 and 3.1 were not that many. I've migrated a whole ASP.NET Core 2.1 web service to 3.1 in less than 1 hour. > 2) C# is a very verbose language, that requires a lot of typing. Nonsense. The only added verbosity to C# when compared with Python are the type declarations, which arguably are a problem plaguing Python. The first class support for events and async programming and properties in C# more than make up for it. > 3) F#, the best language in .NET, is largely ignored by the .NET community. I fail to see what point you were trying to make.

vidarh 6y ago

A lot of developers never get proficient on one stack. Much less more than one.

rumanator 6y ago
You don't need to master one stack to get up to speed. For that investment to pay off you only need to be almost as good as you were with your old stack, which isn't hard if you already are not proficient.
- vidarh 6y ago
  I'd argue that time would be better spent actually learning any single stack properly.

tetha 6y ago

Writing code is one thing though. Now you have to figure out how to run a CI on a build server. Deployment on your production systems, be it containers or even not. Monitoring, alerting, profiling, tuning under load. You have to support a new database connection library with new shenanigans. In general, you need to integrate the new language into the existing ecosystem. The latter may even be impossible depending on the stack and solution chosen. Just look up those weird Java only caching servers. All of that is possible, sure. Due to company acquisitions and specialized teams in some areas, we're kinda running the full bingo card of languages. But there's little denying: We overall spent less time handling language runtimes and language-specific monitoring back when we were java+mysql and that's it.

rumanator 6y ago
> Now you have to figure out how to run a CI on a build server. Deployment on your production systems, be it containers or even not. Monitoring, alerting, profiling, tuning under load. You have to support a new database connection library with new shenanigans. Most if not all of those items are either trivial or non-issues. In fact, I would argue that deploying a Python app is a far more convoluted process than getting an ASP.NET Core app up and running. With Docker, the problem simply disappears. Getting it to build and test on a CICD pipeline is as hard as typing $ dotnet build, or $ dotnet test. > All of that is possible, sure. Not only it is possible, it's laughably easy. We are supposed to avoid our problems, not perpetuate and aggravate them as eternum because we are too lazy to look for ways to make our life easier.