Airflow helped my team out a lot a couple years ago mainly for the simplicity of the topdown UI-based view of a complicated ETL AND the ability to retry parts of the ETL.
We had lots of lessons learned. For instance, why does PythonOperator even exist? It takes a callable and thus you're likely not going to see good coding pattern emerge for something that needs to be 1000+ LoC. Instead, we just subclassed BaseOperator and used tried-and-true OO principles.
Totally agree on hoping there is at least some movement forward on async--particularly async ORM. I love Django and DRF. It is my go-to for a lot of things, but the lack of async support is increasingly a problem for more organizations. Honestly, it would not surprise me that if a solid, kitchen sink web framework emerges in golang, Django will be abandoned rather quickly.
I've been writing web applications using python and django for close to 15 years now. Smooth, concise and stable. Doing the same using a verbose and boilerplate heavy language like golang doesn't sound attractive to me, at all.
Not sure I understand the fuss about upgrades either, at my current job I've gone from python 2 to 3 and from Django 1.8 all the way to 3.2 LTS without too many headaches. The release notes provide detailed instructions on what is deprecated and what you should do to fix it.
Yes, maybe in 10 years when this Go framework catches up with all the features and becomes as battle proven, well documented, maintained and funded as Django and somehow we know is not yet another thing that will be abandoned next year.
The Go hype is as bad as the frontend hype in my opinion.
If you're replacing Django with Go then either you never needed Django, or you have no idea what you're getting into.
At a previous job backend team decided to replace rails "because monolith slow ruby not fun anymore" with Go. Three years later they were still reimplementing things rails gives you since day 1. I've seen abominations as doing migrations as SQL scripts ran by cobbled together bash scripts because "as we don't have orms then orms are bad".
No need to say now they're about 4 years in and the one still running the business and making all the money is the monolith, not all the Go microservices around it.
Go is a replacement for c/c++, maybe java and for building infrastructure probably.
If you're using it for doing CRUD forms, you're using it wrong.
GP (BiteCode_dev) made a valuable comment for how we can build a easily deployable python application with
>web framework, db, caching, task queues, static file serving, which can handle around 100k visitor each day without a sweat.
i.e. with 4-5 large dependencies of frameworks, libraries, software etc.
In Go you can off the bat reduce those dependencies to 1 or 2, even completely eliminate them, you get deployable package and async for free with faster development cycle and lesser headaches of managing dependencies in the long run.
Out of curiosity: what features from Ruby are they reimplenting? I have no experience in Ruby but in a few other languages and framworks. And having encountered something missing yet when writing Go web services.
Rails. Features of rails.This is exactly the problem...people focus so much on the language they forget the ecosystem they're in, and the ecosystems matters a lot more than the syntax or the performance.
> And having encountered something missing yet when writing Go web services
How do you do form validations, translations, database access, migrations, email sending, background jobs that don't die on a deployment, user authentication, file uploads, caching, etc?
Of course all of this can be done, you just need to take 100 decisions and tie together 256 libraries many of them probably abandoned in a few years from now.
If you don't need any of that, then just what I said before: ok, you never needed rails from the get go.
Rapid7 | Senior Software Engineer | REMOTE or Arlington, VA | Full time
The Rapid7 Labs team uses our experience, expertise, and passion for cyber security to establish a leading understanding of worldwide emerging attacker methodologies.
In this senior role, you will cover multiple disciplines. This includes Data Engineering to enable and enhance our petabyte-scale internet scaling platform (Project Sonar) and our global honeypot network (Project Heisenberg) which drive research, enhance products, and empower the community. This role requires being a seasoned Software Engineer too as we build out proof of concept projects that may later become Rapid7 products. As a strong software engineer, you have experience in writing maintainable code that is properly instrumented and tested. You should love being always on the lookout for better solutions and keeping technical debt at bay.
I've messaged you guys a couple times, but never heard anything! I'm a seasoned Django developer, led some teams, and have a bit of experience in public health (mainly disease surveillance) platforms. I'm located in Austin.
Just fyi, depreciating the property isn't a choice in the US. When you sell, the government assumes you did depreciate on your previous tax returns. If you didn't, you missed out on those deductions and depreciation will be reclaimed regardless.
This is true, and I love DRF but I find it unfortunate then that the concept of Serializer exists. Tom Christie essentially says that Serializers can and should be used outside of views (REST) to decouple and encapsulate business logic. He seems to believe models are database operations-only. This view is fine (e.g., data mapper) but then it seems the scope of DRF is beyond REST and should be part of core.
I'm not sure if this is exactly where al2o3cr was going, but a Ruby (or whatever) application would normally include such things as caching and queueing. Despite the slowness of Ruby et al, I actually would expect a modern application with these layers to handle load much better than straight database calls. So I guess I would consider the PostgREST implementation a bottleneck because you can't add any of these layers.
I'm really excited about the idea of groups that may be coming to Docker. It seems like a great primitive around which to build tools like fig and tug and perhaps other tools to orchestrate production.
