aaai

But... don't bother too much trying to explain this to ppl who don't intuitively grok it right away... some just seem to never get it no matter how hard you try and explain it to them, it's like their brains are "wired differently" when it comes to reading and understanding code, they don't get the advantage and meaning of unification / universality / "one solution for many problems" etc.

Go is NOT my favorite programming language, but there's a stroke of simple genius in it that probably only got materialized bc its creators were left alone to work on it their way inside Google and just implemented their solution to things without being bothered by "language experts"...

EDIT+: not saying "colorless + channels" is always better or anything like that, all's tradeoffs... probably async/await code is much more readable than channels hell for many/most cases (but because it's less powerful - no true parallelism possible).

If you code Python, at least take some time to read more modern code: see responder (not my favorite but cool), fastapi, starlette, asyncio http examples etc... Or see older examples (as old as Django) like web.py.

Short answer: no, bc FastAPI makes no assumption about your ORM (bring whatever, use none... your responsibility, your choice - I use sqlalchemy core + databases module for async support, no ORM, but but full use of Pydantic for enforcing schemas, just "divorced" from persistence layer, maybe you don't even need any), or your anything else.

I actively dislike DjangoREST and tbh Django too... but I admit that in combination they can save A TON of time when prototyping something.

1. fast development (both Python and node)

2. boring platform where it's usually OK to leave smth unupgraded for >5 yrs (Python wins here hands down)

3. cheap devs (good Node.js devs have a lot of option to "jump around" between front and back and frameworks so higher room for leverage ...with Python you can hire cheapest newly grads since it's now taught in most unis)

...on top of this:

- performance in terms of "requests served per CPU power" does NOT matter for most apps (and when it does caching saves most situations) - and if it does, modern Python can deliver now (async is mature)

- using same stack as ML and datasci comes as a bonus - you can have backend-full-stack-devs jumping between data pipelines, APIs/web, ML models, data analysis code etc. who can stay separate from frontend-full-stack-devs doing web frontends + mobile hybrid etc.

It would be great if we could also standardize on a static high performance language common to all (eg. usable for special-performance-sensitive-code either standalone services or Python-modules or node-modules) ...this area's a mess, too much overlap, duplicated work, and too hard for devs to jump from one ecosystem to another (Rust and C++ as lib/extension langs... Java/Kotlin or Go or C#/F# for standalone services... now Swift an option too...).

    Location: Bucharest, Romania (UTC+3)
    Remote: Yes
    Willing to relocate: not in 2020, possibly later
    Technologies: { solid: [ Python, Keras, TensorFlow, Pandas/Numpy/scikit-learn,
        Jupyter, Django/Flask/FastAPI/asyncio, REST, Docker, AWS, Google Cloud,
        SQL, Postgres, MySQL, MongoDB, Linux ],
      minor: [ Go, Fastai, Pytorch, R, Node.js, React/Redux/Vue/Svelte, Java, Bash ] }
    Résumé/CV: Upon request
    Email: [email protected]
    ---

You agree on quality standards before you begin, and you deliver the quality level that you agreed beforehand, not more, not less (you deliver sooner if it goes better than expected giving the product-owner ability to add features or redirect effort actually using your "superpowers" if any to give the business a real advantage), at a profit or at a loss. Otherwise you're not a professional, you're either an amateur or maliciously dishonest/exploitative!

I like Wikipedia as it is, let's not make it into IdiocracyPedia for the sake of accessibility... if you're not lazy and you're willing to put some focus and time into your research you'll be able to understand quite unfamiliar subjects from Wikipedia, there's nothing blocking you, as opposed to eg. lots of academic articles that may contain un-google-able jargon and unexplained/unmentioned domain specific assumptions.

> inhibit the [...] RNA polymerase of the [..] virus

If it would just simply stop RNA synthesis (eg. inhibit any RNA-polymerase) or if it would actually break RNA in general, it would kill HUMANS just as well!

The point of antiviral compounds is to selectively inhibit/kill mechanisms/components of the virus and not the human host... there's hundreds of thousands of antiviral and antibiotic compounds that are not very useful because they'd kill humans just as well or give them horrible cancers or god knows what else...

As the saying goes... "Everything should be made as simple as possible, but not simpler."

Most problems I had where with:

(1) deeply nested tree-like objects updates - model serializers have limited support for nested updates, but it breaks down fast, if your frontend-exposed data looks more like trees than tables you'll be fighting it all the way

(2) REST semantics can only get you that far! You end up doing some form of domain-driven-design sooner or later and your verbs are no longer (just) create/read/update - you have "approve", "reject", "approve with comment", "flag for review", "restore to version 123" etc. REST is not CRUD, you can have REST semantics with only R from the default actions and everything else can be domain specific.

In general I prefer to (a) not expose to the API the actual backend's data model in all its gory complexity and (b) figure out what actions make sense for the application domain, drop the CRUD handcuffs.

Once these choices are made, which I now prefer to do early on, pre-emptively, something like DRF becomes pure-pain, 0% gain: I use nothing from it, and it's too dumb to autogenerate stuff like validation or to offer some structural patterns from which to hang code for things like sub-object permission checks or anything like that...

Give FastAPI a try! You probably have DRF-Stockholm-syndrome like many do. The joy of having all pieces fit right in and be understandable and have validation auto-generated from type annotations (if you choose to) is a-f-mazing!

After using DRF quite a lot for quite a while I can clearly self-diagnose myself as being abused by it - such ugly patterns you always end up coding around and fighting the framework everywhere...

Use Flask if you're afraid of Python async, there's probably good reasons to be, never had to debug it in production... but LIKING DRF?! I cannot fathom that, I mean, one can like Django itself, it's good for what it was built to do, but what abominations ppl built on top of it instead of starting from scratch... ugh!

But it's lovely and a pleasure to work with, most developer friendly thing I've ever touched lately!