- It is typically neither free nor open to develop on consoles. As in, you pay to access developer tools.
iOS and Android less so (even if there is a one time charge for Android and a yearly charge on Apple). OTOH I have not heard of them usually reaching out to more than a handful of devs for promotion purposes.
- Jim Keller goes into some detail about what difference the ISA makes in general in this clip https://youtu.be/yTMRGERZrQE?si=u-dEXwxp0MWPQumy
Spoiler, it's not much because most of the actual execution time is spent in a handful of basic OPs.
Branch prediction is where the magic happens today.
- That would probably be preferable from a PR standpoint.
- None of those games are made for children. Particularly not CoD and Battlefield.
That doesn't mean kids don't want to play them. But Roblox is pitching itself as a safe space for kids.
- "People Make Games" on YouTube made some videos about it. Recommended watching for any parent who is trying to figure out if they should allow their child on Roblox. (Spoilers, the answer is "no".)
- There are Python bindings for the framework as well.
Personally I could see Go being quite nice to use if you want to deploy something as eg a compiled serverless function.
I'm assuming the framework behaves the same way regardless of language so you could test using Python first if you want and then move over to eg Go if needed.
- I have a M4 Max with 128 GB memory. Even on that machine I would not consider 70B+ models to be useable. Once you go below 20 tokens/s it becomes more like having a pen pal than an AI assistant.
MoE models can still be pretty fast. As are smaller models.
(This is mostly a warning for anyone who is enamored by the idea of running these things locally to make sure to test it before you spend a lot of money.)
Currently I'd probably say the Nvidia RTX pro 6000 is a Challenger if you want local models. It "only" has 96 GB of RAM, but it's very fast (1800 GB/s). If you can fit the model on it and it's good enough for your use case then it's probably worth it even at $10k.
- It depends on the model.
It's typically ok for MoE models but if you try to run something non-MoE the speed will plummet. In that same thread there are people getting 50 tok/s on MoE models and 5 on non MoE. (https://www.reddit.com/r/LocalLLaMA/comments/1n79udw/comment...)
And while it has unified memory the memory is quite slow. 250GB/s compared to 500+ for M4 Max or 1800 GB/s for a 5090. So it's fast for a CPU, but pretty slow for a GPU.
(That said, there are not a lot of cheap options for running large models locally. They all have significant compromises.)
- Using chip and pin is what makes the system secure. The PIN is verified by the chip on the card so it can't be skimmed. (You can copy the PIN of course, but you also need the same physical chip to clone a transaction.)
Signing the recipe is a useless security theatre. That's why it's not done in Europe.
- Git won't catch new files the agent is adding. To get around that you can of course always add all new files, but then you'll potentially have your repo polluted with a bunch of temporary scratch files instead.
You can typically go back and edit git history. But it will require force push and breaking changes. And a few sacrifices to ensure that it doesn't make a mistake because then your repo is potentially broken.
Best way to do that is probably to have it work on branches and then squash merge those.
- The problem is Dunning Kruger effect.
The people who shouldn't disable these security features tend to be the first to do so. And then complain the loudest when the enter the "find out" phase.
- As someone who used to work for a bank building applications I would say no. This is definitely a feature companies and organizations like banks would request if it wasn't available.
There are a lot of scams targeting vulnerable people and these days attacking the phone is a very "easy" way of doing this.
Now perhaps there is a more forgiving way of implementing it though. So your phone can switch between trusted and "open" mode. But realistically I don't think the demand is big enough for that to actually matter.
- As someone who developed in it at the time I found the reason it died was because they made new, slightly incompatible, versions every new Windows release.
After a while people got tired of doing updates.
- From what I've seen immediate mode seems suitable for less fancy UI requirements. If you want to start having a framework solve things like animations and such then you'll probably end up with some form of retained mode.
Over my years making UIs I've found most of the bugs you get is due to incorrect state handling in applications. Having a framework you use which is opinionated and helps you solve that is pretty nice. (If your UI requirements are such that you need it.)
- After being stuck in XML land for making UI for almost two decades I couldn't be happier to leave it behind.
Spreading your code over multiple languages means you now have a bunch new fun edge cases to deal with when things get stuck and don't update correctly. With everything in one language that means all debuggers and other tools work the same regardless of where in the app I'm debugging.
I've found it fascinating to see UI building come full circle. I started in code (C), then using various XML schemes and now back in code (Kotlin, Flutter, Swift). But a big part of why it's nice now is because C is a pretty horrid language for making modern applications.
- On Android (and I'm pretty sure iOS) you have WYSIWYG editors for UI layouts for jetpack compose and flutter (and on iOS it would be Swift UI).
These all go direct to code instead of XML or some other extra layer of code.
What I would probably focus on is better integration with Figma and similar tools. Use that to do the WYSIWYG part and then generate corresponding code (possibly with LLMs).
The biggest limitation you tend to have in WYSWIG is that at some point you really need to have the true data the user sees to ensure everything looks good. That becomes a bigger hassle than coding the UI manually. (Particularly when doing multi-platform things.)
- Kotlin multiplatform has been around for some time if you want that. But I guess it makes sense to be able to approach it from the other end as well if you're mainly an iOS shop.
- It's "Tools as a service", so it's really trying to make tool calling easier to use.
- I suspect that Waymo car's could operate in a lot more areas than they do. The issue is that Waymo are trying to sell the service of safe travel and not a car with an addon you can pay for which doesn't actually work.
In other words, since they accept liability for their cars it's not in their interest to roll out the service too fast. It makes more sense to do it slow and steady.
It's not really a strong argument that their technology is incapable of working in general areas.
"I want you to do feature X. Analyse the code for me and make suggestions how to implement this feature."
Then it will go off and work for a while and typically come back after a bit with some suggestions. Then iterate on those if needed and end with.
"Ok. Now take these decided upon ideas and create a plan for how to implement. And create new tests where appropriate."
Then it will go off and come back with a plan for what to do. And then you send it off with.
"Ok, start implementing."
So sure. You probably can work on this to make it easier to use than with a CLI chat. It would likely be less like an IDE and more like a planning tool you'd use with human colleagues though.