That works only as long as people are employed and there are enough jobs to employ people. Simplest solution for a company is to outsource or automate jobs away as much as possible. After a couple years customers will adjust to the new norm even if it's a worse experience for them.
Isn't VAT generally a regressive tax so does the exact opposite of what the author thinks it does? The rich spend less versus their income than other demographics. I guess the UBI is to offset that but that just doesn't seem like a stable system.
Money attracts those who seek money and those who seek money for the sake of money will as one would expect prioritize money above other things such as ethics as there is a natural feedback loop there.
Exactly, not just money for founders but money for engineers themselves. The same thing that attracted these personalities to other fields in the past (sales, business, etc.) which made the most money now attract them to tech.
Python software is to a large extent either doing things in not-python (c, c++, rust, etc.) or doing things that are not cpu bound (io bound, async, etc.). If you're cpu bound then you can either take a 2x jit improvement or take a 10x non-python improvement. There's few companies of a scale where the non-hot path cost of 2x cpu is so massive as to be worth caring about.
The python overhead of launching big ML jobs is nontrivial, so I think speeding that up would be meaningful. (I mean the initial tracing and other setup, not things once the GPUs are actually doing the work).
That seems more like the tracing overhead than the python overhead. The original jit proposal would I believe not help at all with that since ML workloads basically do their own jit. The post being discussed however pushes for a general framework and good tracing support so might help ML workloads.
I suspect there were people who had alternative proposals which got implicitly blocked by this 5 year effort. Letting a subgroup run wild without proper process is not good for a project this large.
I suspect the recent "we updated the GC without a PEP and it went live and caused massive issues and we need an emergency point release revert" pushed for a greater degree of process overall.
Python isn't a side project to yolo on. Updating the GC without a PEP caused massive issues for actual people using Python. If you want to impact software used by millions of developers then you better be willing to handle a bit of process.
Killing the incremental GC for synthetic benchmarks, not real ones, caused the issues. If the processes are broken and you get nothing done with it, you better step aside and do it without. Fork it, and drive the blockers away.
The README makes me never want to use this. A career of seeing the same style from shit vendor salespeople has made me assume that under the hood is nothing but snakes.
Whenever you are publishing something, whether it be an app, a programming language, ... the examples or screenshots must come first. The reality is that unless you have made a very compelling case beforehand (like with a well crafted screenshot or example), most people will not read your list or description below. Put the examples at the start of the README, they're the selling point of your language not the list of features
For instance, this was the first ever version of the rust-lang.org website:
I remember reading it 14 years ago and it was pretty effective at captivating users towards the language. Notice its terseness and the example at the bottom: a reader will first look at the example, then the bullet points above if they're interested, and then the rest of the docs
- Overly boastful language. Nothing is perfect, everything has limitations, etc, etc. If the creator isn't willing to admit that and be open about it then that just means users will hit those issue instead.
- Saying what others are not versus saying what you are. You're talking more about other languages than your own language. Vendors do that as a cheap marketing trick to use the popularity of others to boost themselves.
reply