They didn’t say calories are addictive. They clearly said certain foods are addictive. Those foods should be more regulated like cigarettes and companies take more responsibility as a first or at least concurrent step to everyone taking more drugs.
Jetbrains and rust have brilliant refactoring. No idea how it compares to kotlin, but I can confidently move methods to other modules and files, rename anything, navigate to definition with no fear. Auto complete / auto import is also insanely good and is almost to the point where I’m auto completing almost every symbol because the IDE knows what I want precisely.
> if you're head and shoulders above any of your competitors, you're able to get away with things like this.
The hubris of Tesla is still believing this to be the case. I personally cancelled my cybertruck order from lack of interest. better competition exists in 2022 that wasn’t the case years ago.
No but I have been through exchange mandated confiscation of crypto wallets. Be your own bank you say? Keep my own keys you say?
You think the average person from the article would hold their own keys? No the reality is if crypto was adopted en-mass, people would use services to manage their keys and you literally solve zero problems.
That’s literally just another way of saying you are using Bitcoin to break the law.
Also in the US, transferring Bitcoin to say Russia is sanctioned and illegal. Is it technically possible to push the button and the transaction go through? 100%.
Does it mean it that you wont get in trouble for it? Absolutely not. Congress has an entire page about it. 1 year, 5 years down the line as soon as the govt gets a whiff, all your past dubious transactions that you used to evade sanctions are now Public and used as evidence against you at your trial.
I can write a Graphql endpoint in python (Using Django-Graphene). I can write python functions that return data to the graphql. I can write ORM queries that write data to grapqhl. I can specify access, permissions and certain queries based on the user.
Graphql is more of a relational FFI than a SQL replacement.
Also the frontend never sends SQL to get data because it is unsafe. This is what a GraphQL framework allows you to do, clean up and filter queries so they are safe and then translate them into efficient lookups in a RDBMS.
Say you have a REST interface for Student and Class.
What do you do in rest if you want to get just a class? What do you do if you want to get a class and its students? What do you do if you want to get a Student and also its class?
For every iteration of the way you need to access the data you have to modify and extend your REST endpoint or do separate queries. Every time the frontend devs want new data related to existing data, they have to do another query or ask the backend to include it.
Or lets say Class has 1000 attributes. Does your REST interface return all 1000 every time? Or can the frontend specify which attributes to load? Things like computed attributes and functions that return data related to the object. GraphQL allows this.
In graphql doing these relationships is dead easy. You define a class and how a student is related to it. Then you could even ask a query like “give me the classes of a student. For each class give me all the students in those classes. For each of those students, give me their classes”. Without the backend having to add anything. All the backend has to do is define the relationship and permissions about how to access the data.
Most GraphQL libs provide helpers for avoiding n+1 queries also, so things get optimized in the above case by only making 4 queries to the DB. Obviously thats a contrived example and most nested things wont go so crazy. But it goes to show how a powerful the API can become from defining such a simple relationship.
As a backend dev you just have to work on transforming data, defining the relationships and checking permissions. You let the frontend determine what data they want to access.
Before working with REST almost every page seemed to need a specialized endpoint to be implemented for the frontend to work, but with GraphQL, the frontend can work much more independently without having to ask the backend to provide a specialized view for more data.
Great to see improving support for async here. I am a big fan, but IMO python async code is just different from other async langauges. I used async extensively in python and compared to other languages it is a pain to use because unless 100% of the the libs you want support it you will get stuck on some sync library. Async in python is not even a 2nd class citizen. Its more like a 3rd class citizen. Its gets better every year but it is minuscule compared to regular sync code, so very few tutorials mention it and nobody teaches it as the default way of doing things.
In order for async to be popular it needs to be the default way of writing python. Right now its an after thought for writing “high performance” python. For example asyncio version of redis got 72,114 downloads this month. The sync version got 26,825,663. Thats not even in the same universe.
Historically, using something like gevent is a more drop-in solution for python if you want lightweight threads, but it comes with its own problems. Gevent gives python what Zig has that automatically turns all sync IO calls to async and your app is now magically using greenthreads.
However I think gevent in the past was the crutch that prevented a lot of lib authors from writing async libs.
I think my experience in async in other languages has shown how rough async in Python is.
Unless async is the default python, it will always be an after thought and introduce needless complexity when working on large projects that require a lot of external libs.
Why do they need Async templates? When a template renders it should be pure data and fully on the CPU. It seems Async templates would encourage a bad behavior of doing n+1 queries inside the HTML.
? With Graphql and Phoenix you use a RDBMS to provide data for the queries you write. Its not a replacement.
Its also not even much a paradigm shift in my experience. Queries are simply analogs to GETs and Mutations are analogs to POSTS. Thats about all you need to know to get started. To convert a REST app to a GraphQL app is ridiculously straight forward. What it does much better than REST is nested lookups, being typed, and being able to request more than one piece of data at a time.
From my perspective I wouldn’t choose CouchDB. For one, its a pretty obscure DB that doesn’t have a lot of support. For example almost all major hosting providers now allow you to launch an app with Postgres hosting out of the box.
Way way way way more tools and articles for building an app with postgres.
Also I would recommend Postgres to take full advantage of Phoenix and Ecto (the ORM). In Elixir GraphQL and Ecto are deeply integrated to avoid n+1 queries when you are writing nested lookups.
In my opinion having used Django, RoR, frameworks in Go and Rust, Elixir has the most robust and powerful ORM out of any language and it would be a shame to miss out on it by using CouchDB.
I prefer GraphQL over REST tremendously. For a large site, in REST we had this process of the Frontend would have to tell the backend what data they wanted, the backend would make the endpoint and then the frontend would consume it.
With Graphql the backend just defined all available data and the frontend picks and chooses what it needs. GrqphQL also prevents weird n+1 requests where you need to request the data of the children from a previous REST result.
GraphqL + Phoenix + Postgres is a game changer IMO
People complained about cigarette taxes wouldn’t be effective but they are.
The stock market didn’t crash either despite the multibillion dollar tobacco companies being affected.