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.
As far as I can tell, our social policies don't really work for managing addiction. We just hook up a vacuum cleaner to people's pockets and suck the money out of them if they smoke. Call it a "sin tax". But the problem is that people prioritize their next fix above other things; would you rather get some cigarettes or pay your rent, many people choose the cigarettes. I'm not sure how that helps anyone, and I'm not sure how expanding it to sodas or doughnuts would help anyone.
Regressive taxes also don't work well. I don't always eat super healthy. Making unhealthy food cost more wouldn't have any measurable impact, except maybe tanking my 401k because half the Fortune 500 goes out of business.
I'm not sure I buy that argument though. The idea that you can squarely blame the obesity epidemic on some foods and not others.
Hell I'd be ok with banning all forms of food advertising and requiring that all foods be blank packages with nothing but the ingredients, nutrition facts, and a short description of how they were prepared. I'd prefer that world on general principle. But I don't think it would fix the obesity epidemic.
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.
That's a JetBrains thing - they added loads of fantastic refactoring options to Visual Studio for C# which have now largely been integrated into the IDE directly. I've had an all-products subscription for close to a decade now and it's money well spent.
ReShaper was what kept JetBrains alive 10+ years ago and Microsoft couldn't release a new version of Visual Studio until ReSharper was ready for it due to how many people used/depended on it.
> 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.
Tesla's are outselling every other manufacturer (ICE or otherwise) in many countries for the last quarter and they are still severely supply constrained; your personal antidotal data point doesn't serve much purpose in the broader context.
But the best selling EV manufacturer in Norway is Volkswagen. Volkswagen has four EVs in Norway's top 10 sellers: VW ID.4, Skoda Enyaq, Audi Q4 e-tron, and the Audi e-tron.
The VW ID.4, Skoda Enyaq, and the Audi Q4 e-tron are different versions of the same car. Rather than selling just one model Volkswagen's approach gives you the choice of more options.
Add in ICE vehicles and it's not even close. Volkswagen sells 10 million per year globally across all of its brands (VW, SEAT, Cupra, Skoda, Audi, Porsche, Lamborghini, Bentley, Ducati, Scania, MAN, etc.).
One of the weird things about Tesla is that, in general, supply side constraints are widely regarded as a flashing warning light that a firm can’t execute. Yet Tesla is just given an “I’m sure they’ll work it out.”
I've yet to be in a country were sales are not skewed toward local cars. Sweden lots more Volvos than anything else (and definitely Teslas), France, lots more Citroen and Peugeot than anywhere else, Australia: Holden and Ford, US: lots of cars that drive nowhere else (GM, Chevy...).
Regarding outselling most other car manufacturers: this seems to be the Tesla realitity distortion, it is likely true for electric cars but for all cars VW delivered ~5 M cars in 2021 vs Teslas 900k
Australia with its long drives if you leave a city and lack of infrastructure doesn't suit electric cars at the moment. Will change eventually, but likely lagging the rest of the world.
> Australia has no local car manufacturers and hasn't for some time. Toyota is by far the biggest car seller , followed by Mazda and Hyundai.
I know Toyota closed it's Melbourne plant in 2017 (Holden and Ford had stopped manufacturing even earlier IIRC). I would argue though that Ford and Holden (which I just read ceased operating in 2020) are still perceived as Australian car manufacturers by most. They definitely had some cars specifically for the OZ market.
"Car leases trough employers are only for German cars" - that is not true, as a German company you can lease whatever car you want for your employees. They are predominantly German cars for the obvious reasons. :)
While there is a preference for VW group in the corporate leasing market, theybare far from the only ones. Your first argument doesn't make any sense whatsoever so.
“In Q3, we began transitioning to a more even regional mix of vehicle builds each week, which led to an increase in cars in transit at the end of the quarter. These cars have been ordered and will be delivered to customers upon arrival at their destination” - [0]
In other words, they said all of the cars had been ordered, although many were in transition at the end of the quarter.
I mean isn’t that the same thing for traditional dealerships? They order the cars and they’re waiting to be sold. A good amount of Teslas end up rejected for whatever reason and show up on the existing inventory page. You can often find new cars in socal with delivery that week. I got my model s that way.
I'm pretty sure you can't stuff your supply chain like that.. Sunbeam got caught once doing that so I'm pretty sure it's a major no no. If it's ordered then it's ordered by someone. Not by a dealer etc? Plus Tesla have no dealers except themselves? so at most it'd be bunch of rejects?
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.
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.
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.
SQL is a leaky abstraction, which makes your system more brittle. The front-end now has intimate knowledge about the physical data management. You don't want that. If later you decide you want to change your physical data layout to improve data storage and retrieval performance then your queries have to be modified. The front-end and data tier can't vary independently from one another. That's what makes your system brittle.
That's not even getting into the tremendous attack surface you've just opened leaving your application vulnerable to SQL injection attacks. SQL injection is a real problem and scrubbing all the inputs is a pain and you can never be sure you got everything. One mistake and congratulations! - you've made headline news!
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.
Hey, I wanted to chime in and say that I too am underwhelmed with the support for async in Python libs. Coming from a node.js background, it falls short because you constantly have to think about whether async code is calling sync code, or vice versa, and whether you need an executor, threadpool, etc. Just a mess that gets in the way of productivity IMO.
However, things have been getting better, and in case you haven't seen it, AIORedis[0] appears to be the de facto standard for async in Python (a little better with 1,724,389 downloads this month). It's popular enough that it's been merged with the official redis-py driver[1].
> 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.
Might this have to do with the fact that the (lack of) performance of asyncio is exactly the issue here?
I remember reading a blog post by zzzeek (the SQLAlchemy author who's also participating in our discussion here) about precisely this issue a while ago. Not sure but it might have been this one:
Yes, though I do think the python async ecosystem is gradually moving from a "3rd class citizen" to a "2nd class citizen". There are sync+async libraries like HTTPX that are gaining support. I don't expect it to really ever be a "1st class citizen" (supported as well as sync in pretty much every library everywhere) because of backward compatibility and ultimately async is just harder to program. Sometimes developer time is more important than the performance wins of async.
> Sometimes developer time is more important than the performance wins of async.
Also, a fair fraction of applications don't see a meaningful benefit compared to other things the developers could be spending time on. Async is not only harder to write in many cases but can force you to deal with new problems which might be harder to manage (e.g. if you use non-trivial amounts of memory, bounding your peak usage can be a challenge).
I've used async a fair amount and it's worked really well in network-heavy uses (HTTPX is really great) but outside of those the savings have been a lot less than people thought, independent of the language used (I'm thinking of a colleague who spent a lot of time trying to beat classic Python with Go and ended up with about a 10% win after a month or so of work because the problem had enough CPU/memory contention to prevent greater savings — that's not a trivial win but it definitely wouldn't have been enough to justify changing languages on its own).
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.
My immediate thought would be custom template tags. Like `{% popular_articles %}` would have to connect to the DB and load the articles. I am sure there are other reasons too.
? 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.
