OK, even though it does not seem like that game was very notable, will give you that one game. Rust has at least ~5-6 game engines though, so you will have to come up with 4-5 more.
As someone who is actively working on the Bevy Book, the next engine release should include the first public release of the Bevy Book. And once it's out, then we'll be doing our best to keep it updated and expand it alongside the Bevy engine.
Great news, thanks. I have to say that several times I tried to invent something from scratch only to eventually find, reading the documentation/examples, that Bevy already has that part covered.
I now default to the examples, but a book would greatly help.
Hi! Love to see that C# language designers are here on HN :)
Just wanted to add just another opinion on a few things.
I think many people already mentioned it, but I also don't feel to good about non-boxed unions not being the default. I'd personally like the path of least resistance to lead to not boxing. Having to opt-in like the current preview shows it looks like a PITA that I'd quickly become tired of.
Also, ad-hoc union types could be really nice. At least in Python those are really nice, stuff like `def foo(x: str | int)` is just very nice. If I had to first give this union type a name I'd enjoy it way less.
But I'm aware that you are trying your best to find a good trade-off and I'm sure I don't know all the implications of the things I wish you'd do. But I just wanted to mention those to have another data point you can weigh into your decision process.
> Having to opt-in like the current preview shows it looks like a PITA that I'd quickly become tired of.
My belief is that we will have a `union struct` just like we have `record` and `record struct`. Where you can simply say you want value-type, non-boxing, behavior by adding the `struct` keyword. This feels very nice to me, and in line with how we've treated other similar types. You'll only have to state this on the decl point, so for each union type it's one and done.
> I think many people already mentioned it, but I also don't feel to good about non-boxed unions not being the default. I'd personally like the path of least resistance to lead to not boxing. Having to opt-in like the current preview shows it looks like a PITA that I'd quickly become tired of.
The problem is that the only safe way for the compiler to generate non-boxed unions would require non-overlapping fields for most value types.
Specifically the CLR has a hard rule that it must know with certainty where all managed pointers are at all times, so that the GC can update them if it moves the referenced object. This means you can only overlap value types if the locations of all managed pointers line up perfectly. So sure, you can safely overlap "unmanaged" structs (those that recursively don't contain any managed pointers), but even for those, you need to know the size of the largest one.
The big problem with the compiler doing any attempt to overlap value types is that if the value types as defined at compile time may not match the definitions at runtime, especially for types defined in another assembly. A new library version can add more fields. This may mean one unmanaged struct has become too big to fit in the field, or that two types that were previously overlap compatible are not anymore.
Making the C# compiler jump though a bunch of hoops to try to determine if overlapping is safe and even then leaving room for an updated library at runtime to crash the whole things means that the compiler will probably never even try. I guess the primitive numeric types could be special cased, as their size is known and will never change.
Of course the "wait 7 days" are not a silver bullet, but it gives automated scanners plenty of time to do their work. Those automated scanners surely catch this `eval(base64.decode("..."))` stuff that some of those attacks used so in my book this dependency cooldown is a net win. I guess the skilled malicious actors will then up their game but I think it's okay to kick off an arms race between them and the security scanners in the dependency world.
That's a good point. In some level I'd prefer the delay to happen on publication of the package itself. Do any of these scanners have cryptographic attestations or similar?
I tried Swift a few months ago in a project that made use of a bunch of bigger dependencies and I was instantly shocked by the compilation times. It's quite unimaginable to me using Swift for everyday work because of that. Especially when coming from the fast compile times of Go. But it's really unfortunate because I really enjoyed writing Swift because it feels like a very well made language. But iterating on some code and trying to get quick feedback is pure pain.
About the lag, I didn't bother looking into it, but I suspect they log every single action you do and require that the request to their servers was confirmed before allowing to do the next action. They probably face a lot of traffic right now, which could cause the lag. Just speculation though.
I can't help myself but see this as a very strangely written article that does not meaningfully contribute anything? Did the author didn't bother to do some basic research and just dumped a bunch of thoughts, speculation and questionable code/command snippets?
Definitely pixi imo. At least for me it works just as well as uv and imo does even more than uv by giving you the ability to mix dependencies from pypi.org and Conda. And the great thing about Conda is that they still build PyTorch for Intel Macs or OpenCV for macOS 11+ which is not the case for the wheels you'll find on pypi.org so it's really great if you want to build software that is shipped to a variety of old platforms.
Can highly recommend pixi. It really is the "uv but for Conda" and actually quite a bit more imo. Don't know how relevant this is for you, but many packages like PyTorch are not being built for Intel Macs anymore or some packages like OpenCV are built such that they require macOS 13+. That's usually not too much of a problem on your most likely pretty modern dev machine but when shipping software to customers you want to support old machines. In the Conda ecosystem, stuff is being built for a wide variety of platforms, much more than the wheels you'd find on pypi.org so that can be very useful.
So I can really recommend you trying pixi. You can even mix dependencies from pypi.org with the ones from Conda so for most cases you really get the best of both worlds. Also the maintainers are really nice and responsive on their Discord server.
reply