Curious choice of backend python. Indeed Flask is a famous python framework but it seems it has been completely overshadowed by FastAPI.
I would suggest "HyperFastAPI"
A lot of people moved from Flask to FastAPI because the latter is built for async workloads by default. So, people expected massive performance improvements because the word async was associated with performance.
In reality, people ended up having to deal with weird bugs because asynchronous Python isn't the most ergonomic, while having negligible to zero performance improvements. Proof that most people are terrible at choosing tech stacks.
Then, AI came into the scene and people were building APIs that were essentilly front-ends to third party LLM APIs. For example, people could build an API that will contact OpenAI before returning a response. That's where FastAPI truly shined because of native asynchronous views which provides better performance over Flask's async implementation. Then people realized that can can simply access OpenAI's API instead of calling another front-end API first. But now they're already invested in FastAPI, so changing to another framework isn't going to happen.
Either way, I like FastAPI and I think Sebatian Ramirez is a great dude who knows what he wants. I have respect for a person who know how to say no. But it's unfortunate that people believe that Flask is irrelevant just because FastAPI exists.
> In reality, people ended up having to deal with weird bugs because asynchronous Python isn't the most ergonomic
That is an understatement. I loathe working with async Python.
> For example, people could build an API that will contact OpenAI before returning a response. That's where FastAPI truly shined because of native asynchronous views which provides better performance over Flask's async implementation.
TO be fair there are lots of other things that require a response from an API before responding to the request and therefore async reduces resource usage over threads or multi-process.
> TO be fair there are lots of other things that require a response from an API before responding to the request and therefore async reduces resource usage over threads or multi-process.
Agreed. However, these are rare and many people have been abusing asynchronous views instead of delegating the task to a background worker when multiple external requests are required. Showing a spinner while polling a synchronous view is dead simple to implement and more resilient against unexpected outages.
I agree with this. For real life stuff, Flask (or Django for that matter, my preference) is preferable over FastAPI. I used FastAPI recently for something that needed super fast (relatively speaking) async. And you just need to build a lot of stuff yourself which wastes time, comparatively speaking. If I had known, I'd probably have done it in Django and rather used Daphne or something.
Interesting. But is it also not just that Flask was build more for making websites in general, and FastAPI for making REST APIs specifically? I would say that if you want to make a REST API, that FastAPI is easier and more convenient to use.
After using both Flask and FastAPI extensively I can attest that Flask is the better technology. Flask is extremely stable and has solid organization around them via Pallets. This is a great benefit as they are keeping the ecosystem moving forward and stable.
Versus FastAPI which is lead by a single maintainer which you can search back on HN about opinions on how he's led things.
Flask also has at time of writing only 5 open issues and 6 open PRs, while FastAPI has over 150 PRs open and 40 pages(!) of discussions (which I believe they converted most of their issues to discussions).
Lastly on the technical side, I found Flasks threaded model with a global request context to be really simple to reason about. I'm not totally sold on async Python anymore and encountered odd memory leaks in FastAPI when trying to use it.
flask-openapi3 looks good but has only 246 stars. Would be worried using it in production. flask-pydantic has no openapi tie-in. Oh look, there's me bumping the openapi request that's been an issue since 2020: https://github.com/pallets-eco/flask-pydantic/issues/17 which has an open PR since 2022.
It's possible between Quart and svcs (for DI) and some Pydantic/Marshmallow/OpenAPI extension you might be able to mimic what FastAPI does. But I'd just use FastAPI. I use async too. It's a lot easier to scale in my opinion.
Do none of these pieces matter to you? Like do you not do any data validation or care about OpenAPI?
Dependency injection in fastapi honestly feels like a horrible afterthought. Flask's g is much easier to reason about, and 99% of projects don't need the 'performance improvements' of async.
Flask is old. It's mature, nothing left to add, little if anything remains to fix because nothing is really broken. OTOH its static typing story is pretty weak, and this is likely unfixable by design. Its use of one-letter global objects also feels a bit weird.
It's the "choose boring technology" poster child, of sorts: get things done reliable, without using any design younger than 15 years ago.
Looks really nice.
Too bad you take businesses into hostage regarding the SSO. This is even one one the main argument in your Enterprise plan.
I know this is common behavior but I find it sad to have such an important security feature proposed only on latest plan.
Many people complain about the time you need to have a proper vim.
In computer security, I learnt to make my own tools, to develop my own script that match what I want to do/scan.
For vim, this is exactly the same. I started with Python so my vim became the best Python IDE (for me) and that's all. What I said to junior dev is "Here my vim conf, you are allowed to copy/paste only what you understand". Then I did some Typescript and added a configuration that works for me. Thus, some pain point came from my old config in python, I found new good plugins and added them. And so on with rust and ruby.
Everything is commited so now, on a new machine, it takes me the time to copy/paste my config and write :PlugInstall.
Everytime I test vscode, it does not do what I want and when I look into it, I can't configure it correctly. Vim has always my back.
Indeed, yet I switched to vscode after 10 years of vim because it is next in line to vim when powerfull editor is in question, and once you set it up you can have it 0 on-boarding everywhere else working on ANY machine you use, including browser. I use a lot of machines and I want my editor with me. Its mind blowing that you can just login in GitHubs vscode within a web browser on any repository and have your own vscode with config, hotkeys, extensions and whatnot, the same as on the desktop.
I do miss vim editing constantly, and I could never feel vim emulations as a native thing, but vscode is really awesome, particularly its keyboard centric design and sync.
Once vim has this "works everywhere and my setup installs in 1 command" I will get back to it.
> Just copy/clone the dotfiles, launch neovim and run a command to update the plugins and everything is good to go.
The last time I did anything like this was back in 2016, where I'd cribbed a relatively customized vim config that my boss had rigged up for python and C++ development. I spent so much time troubleshooting plugins and integrations across the various systems I was trying to do development on, I've been burned out on "just install a plugin and update stuff."
Even now, working with Ruby and VS Code, I feel like I have to troubleshoot my plugin stack once every other month because some behavior isn't working quite right. I loathe the idea of ever having to set this up on another machine, and I miss when I was a Mac developer who just (had to) use XCode. It was flawed, certainly, but the base function set Just Worked.
I used to have the stomach for having to chase down config issues and customizing my esoteric editor, but now I get extremely suspicious whenever someone says something like "just copy the files and re-run the install command". It's never been that simple in my experience.
Imagine if you had to do that to every program you want to configure. Sure, rsync/git cloning your config may be less straightforward than logging in somewhere, but it's far more convenient when you have to configure dozens of programs anyway.
And then a coworker/boss is at your desk with you and needs to show you how to do something and cannot for the life of them grok wtf your personalized bs is, requiring them to go get their own absurdly personalized mess to show you, and still you both have problems because the workload they showed you tonsave an hour a day would require you to pull out massive chunks of your personalized bs in order to add in a huge chunk of their personalized bs.
And that doesn't even get into what happens on shared machines (servers etc) where your entire workflow either doesn't work or entirely prevents others from being able to get anything done on the machine.
Really.... we all recognize the value of standardization when it comes to our code but yall fight tooth and nail about standardization in other aspects of the profession.... and then wonder why everything is a buggy unintelligible mess at 99% of workplaces and projects...
Why do people keep making value judgements about people that built tools they trust like they should be ashamed or something like that?
Parent simply explained his process and why he uses vim like that and why he doesn't like VSCode. There's nothing there that says "macho" in any shape or form. I don't understand this need to put labels on others like this. Maybe it makes people feel better about their own choices? Helps with insecurity? I don't know.
Whatever it is, this doesn't add to the conversation at all.
I think it’s because of the statement “you can only copy what you understand”. I get the sentiment, but comes off as paternal rather than collaborative.
If anything, it's sound advice. Most of my early day colleagues copy/pasted everything from StackOverflow without understanding any of it, causing huge issues down the line.
They were the classic duct-tape programmers and that didn't help them at all to grow as programmers and even impacted their careers.
Labeling this as "macho" implies that properly understanding your tools is actively bad. Couldn't be further from the truth.
This sounds like a refutation, but it's also in the same spirit as the parent. "No need to deal with insane complexities, I'll stick with my simple editor." Whether that's vim or Sublime, that answer works, and that's pretty cool.
That makes sense, and I definitely wasn't trying to denigrate ST. Having not touched Windows since 2003, and having come from the vim world I had to learn a few aspects of Sublime to help my coworkers out, and just like you say, having to learn a new set of keybindings was a pain.
I don't believe in 10x programmer and know this term only from HN.
I live in France and after 10years programming, I never heard a collegue said "I am a 10x programmer". However, I always make sure any git project can be worked on with any IDE. I use vim, some use PyCharm and most of them use VScode and it works fine.
However, I can tell you my main pain point in using VS code vs vim: project switching. Many times I have to go quickly to another project and close it. When I code in vim this this :
ctrl+Z (go back to term)
workon project_2
vim
ctrl+P (select the file I need to see or quickly edit or show to a colleage to explain)
:q! (let's say I didn't edit anything)
fg (Go back to my main task)
Did not know how to be that fast to open/close project with a _real_ IDE.
To oppose this, there is one feature I envy of vs code: code in docker through ssh seamlessly. Unfortunately this is not even available in vscodium.
This exists in VSCode, it's called workspaces. You save a .workspace file, then with either an extension like this one[1] bound a key (very easy to do), or just using the command pallette to open it, you can switch to any workspace you want; in the same window or a new window, and you can have the exact files/layout/tabs you had open the last time you were using that workspace open automatically.
It's very simple. It's certainly more simple from first principles than your method, but if you are adept at using the shell as you clearly are, then your 'fg && vim ctrl-p` certainly must feel pretty natural; but I hope you understand that this is only because you have probably lived on the shell for many years. I used to do that too, with tmux and vim configs, but now I find it much simpler, faster, and better to use VSCode. I'm not saying you should switch, I'm only saying that just because it's not on the shell doesn't mean it's worse.
what's the current recommended package manager for vim? I used to use vundle but that seems to be unmaintained/deprecated and has broken on recent installs.
Breaking changes are very common with Python Azure SDK.
First version where not pep8 compliant so when they decided to respect it, everything broke.
Azure servicebus in python went from version 0.50.3 to 7.0.0 with almost everything renamed, class moved and so on.
One use case it is you can share different number of key shard to individuals. Thus, they have more "power" based on how much you trust them.
If this is your will, you can give 3 shards to your sister (that you trust absolutely) and requires 4 shards to decrypt it. Your "semi-trusted" friends needs to be 4 to decrypt it, but your sister only needs to know one of your friend to access.
Sure! Our model is focused on making sure that data gets encrypted before it hits our customers' infrastructure, so that there's nowhere on the backend where the data exists in plaintext. This isolates developers from misconfiguration and key management.
