aaai

EXACTLY!

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).

Why do ppl like Django and Flask so much? They're heavy awkward dinosaurs with nasty codebases perpetuating really bad coding patterns (globals?! (multiple)inheritance-till-your-head-spins?! - that's what that soup of whateverMixins is, let's stop pretending... serializers that DE-serialize and different stuff depending on situation?! ...stuff you couldn't add type annotations too because the types would depend of calling contexts far away etc. etc. etc.).

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.

...what would "feature parity" even mean? There's no universal checklist of api frameworks "required" features.

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.

Everybody's starting to figure out that to get affordable development you need:

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...).

Can "Machine Learning Engineer" positions be remote for 2020? (can fly in to meetings ~twice a month or so, but for personal reasons + covid I'm only looking for remote or Bucharest, RO this year)

    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: io@neuronq.ro
    ---

...if you consider quality a lever, you're not the kind of person anyone should want to work with!

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!

Thanks! Will digg more into Cortex and/vs MLflow now ;)

"Approachable" means that it might require some effort from the reader (eg. in worst case scenario, a reader not familiar at all with the domain would have to look up the definition of every word in a sentence and do that recursively a few steps, until he/she gets some domain familiarity by reading the equivalent of a few hundreds pages or less), but you can approach it, and in exchange it gives precise and rich information!

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.

May be hard to understand for ppl. with no background, but that description includes the crucial bit of information that OPs "easy to grok" simplified description lacks:

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."

You're probably lucky to have that use-case.

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...

Senior Software Engineer with 7+ yrs experience, looking to do more machine-learning engineering and data-science engineering work:

Location: Bucharest, Romania

Remote: Y

Willing to relocate: N

Technologies:

    - OOD / SOLID, functional-programming principles, Microservices, REST APIs, TDD
    - Languages and Frameworks:
      + Python (5+ yrs xp):
        * Django, Flask, FastAPI, aiohttp
        * scikit-learn, Pandas, TensorFlow (2.x)
      + Node.js
      + Other: SQL, React
    - Machine-Learning & Data-Science:
      + basic DS w/ Pandas & related tools
      + classic supervised-learning and clustering (GMLs, SVMs, RFs, Bayesian)
      + deep-learning (w/ Keras/TensorFlow): dense-NNs, conv-nets, LSTM RNNs
      + basic NLP models
    - Cloud & DevOps: AWS (EC2, RDS, EMR), Google Cloud (Compute, SQL), Docker, Linux/Debian
    - Tools: Git, Bash, Jupyter/iPython

Email: io@neuronq.ro

I feel like the developer experience is much worse than let's say Django REST Framework

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!

FastAPI is awesome and dev experience is much much better than the heavy not-really-built-for-this-use-case Django + DRF mostruosity. But what I'm using it for is very low load... more like "internal use app" level of traffic. Can't say much about performance yet.

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