There is actually work on adding autodiff to Rust, maybe not really first class citizen, but at least build in: https://doc.rust-lang.org/std/autodiff/index.html (it is still at a pre-RFC stage so it is not something that soon will be added)
Incredible, I have never heard of std::autodiff before. Isn't it rare for a programming language to provide AD within the standard library? Even Julia doesn't have it built-in, I wouldn't expect Rust out of all languages to experiment it in std.
It makes use of https://github.com/EnzymeAD/enzyme which is an LLVM plugin and since Rust also uses LLVM in its backend, we can enable this plugin in our Rust toolchain when autodiff is enabled. So, it is a bit of compiler black magic rather than a direct implementation in the standard library.
Right - nobody who’s had a formal education in engineering would think that way, because cost considerations are part of the curriculum from the start.
I don't think a lot of formal education places teach AWS's resource pricing structure, which can be incredibly confusing, but can be boiled down to: if you want to be as cheap as possible, just use EC2 for everything and maybe S3 for storage.
I'm very surprised you expect any formal education to teach any specific pricing structure. You teach how to evaluate solutions for their price impact. No one was claiming any curriculum includes AWS's resource pricing structure.
I can't recall cost ever coming up as a consideration during my years of formal computer science studies in school. Big-O efficiency, sure, but the cost of compute, storage, bandwidth, nope, not once.
It was absolutely hammered into me in the years of working for startups that followed, though.
Publisher gives you development budget because most games arent made by one person and you need money. At least $50,000 - $150,000 for a small PC games.
Then publisher takes 70-90% before recoup and 50% afte of what remain after VAT, refunds and Valve's 30%.
Problem is when you spent $100,000 and sold lets say for $400,000:
* Valve gets $133,000
* Publisher gets $100,000 + $90,000
And you get $90,000 and real number would be much worse because VAT, refunds, etc.
Oh, dont forget to pay your taxes on $90,000. Good luck!
A moat is protection so you can keep your ARR up or increase it over years. Arguably only google have a moat with their TPUs. NVidia has a moat. But the others who just train some models on NVidia hardware have no moat.
I still don't understand how people can run Debian/Ubuntu. Every single time I have tried my environment in the span of a few months turns into a wet ball of mud with various levels of breakages. It's honestly astounding how bad it is. Once in a while I install a newly released version and naively think "Surely this problem is now fixed". But no, it's terrible.
I have used in my life many different Linux distributions: Slackware, Red Hat, Ubuntu, Debian (professionally or privately). My private choice is the only one not driven by marketing: Debian.
You have three main Debian releases:
SID (if you need to be as close as possible to upstream versions)
Testing (the same as above but a few days after SID)
Stable (you sacrifice the latest software versions for insane stability)
Which one did you use ?
And please don't mix Debian and Ubuntu.
Canonical is commercial company driven by profit (and CEO's bonus).
Debian is driven by community and (mostly) engineers.
I used Stable and SID. The reason I mixed Debian and Ubuntu is because I perceive the root of shittiness to be apt and how it can, and often does, poison your system.
running apt install can brick your system in both large ways, it just stops booting. Or small ways, breaking existing packages or a myriad of other ways. On the one hand this is the fault of apt itself. It allows package scripts to do way too much. And on the other hand package maintainers write honestly brain damaged scripts a lot of the time.
Sounds similar to my experience with other systems (like Red Hat).
Amazing - you've just realised that IT systems don't always work.
Welcome to IT world !
"welcome to IT world" is just dismissive and needlessly aggravating. Just because systems can break doesn’t mean we should throw up our hands and accept the terrible state Debian package management is in. Debian-style package management has specific architectural issues, combined with maintainers writing poor package scripts, that make breakage seem far more common than it should be.
I asked you to be very specific. And you refused. You are criticizing "apt" for "specific architectural issues" but it is still very, very vague. Once again - be specific please. Can you? What exactly are the "specific architectural issues" ?
If you worked for a politician, you would look like hired by PR agency to throw a sh..t on someone else. I believe (and hope) you are not ?
I didn't refuse, I gave a very specific answer, namely that debians package manager can brick your system at any time because there are literally no safety mechanisms. That is the "specific architectural issues" I'm talking about. What more do you want? The code to prove it? Here it is: https://gist.github.com/rowanG077/27cd0a9417dd48593e63018783...
You are right: you didn't refuse, you are cheating (especially people who don't understand nuances)
You provided a content of a deb package that is intentionally malicious.
It is like a saying that car from specific car manufacturer is dangerous for people. When asked "why" your answer is: "Because you can suddenly turn the car and hit people waiting at a bus station".
BTW, I hope you already know that in i.e. Red Hat you don't need rpm package to brick your system. It's much, much easier.
Back in the 1990's I was fond of it for the community spirit, the attention to detail, the way things "just worked" even it had a particular take on some things. Over time it felt like it became burderned with design-by-committee decisions, maintainers leaving and abandoning packages faster than they could replace them, and just a bit too political.
For me this is all about team size. It works if you have small teams, maybe max 6 people. But anything above 8-10 this is a total no go. Because management tasks just are not able to be done well at that point.
You right, but there is a very real coordination problem above the team when you're doing bigger things. I've recently experienced an organization with approx. 25 teams of 5-8, and because of their organization they had way too many concurrent initiatives. It was very hard to effectively swarm multiple teams on fewer (bigger) projects.
Sure it can be zero. It can even be negative. As larger player numbers, including piracy, are a natural form of marketing. That means it's not hard to see this additional marketing could lead to larger sales figures compared to if piracy was not possible.
I would personally vastly, vastly prefer to go to a robot doctor, who diagnoses, treats and nurses me. What exactly do I need from a human here? Except of course being the one making the system.
Emotional support. Some human doctors absolutely radiate confidence and a kind of "you're gonna be okay" attitude. For me, this helps a lot. I'm not sure a machine can do this.
But I hate if the human doctor "radiates confidence" when I know he is not doing the proper scan, because I have to get back with worse symptoms first for him to take it serious. I don't need emotional support from a human doctor. I need the adequate scans and a proper analysis. I am pretty sure that a competent human will be still way better than AI, but AI even now will likely be better than a doctor not really paying attention.
reply