Author's talk at dconf (from today, actually) may be of interest: https://www.youtube.com/live/wXTlafzlJVY?feature=shared&t=24...
(Timestamp is 6:45:08)
2,285 karma · joined January 30, 2017
(Timestamp is 6:45:08)
I haven't really tried to write serious C# code on macOS, but I did write some CLI tools, which was not bad. VSCode debugging works great too.
Obviously .NET is not supported as well as it should anywhere except Windows, but it seems to be getting better.
Apple Silicon Macs on the other hand... I'm still waiting for a Linux device with no fans & comparable battery life + performance.
Apple docs for it: https://developer.apple.com/documentation/metalperformancesh...
PyTorch backend: https://pytorch.org/docs/stable/notes/mps.html
It could just be that they started using other proprietary components in their code though.
Would've loved to read the source code for Doom 2016!
I'm assuming they don't have legal requirements since they owned the old code anyway.
- Kittens: https://kittensgame.com/web/
- Evolve: https://pmotschmann.github.io/Evolve/
[0] https://docs.godotengine.org/en/stable/tutorials/scripting/g...
I haven't seen many people doing ML in Python without one of these libraries, so I'd say it is mostly constructing instructions in Python and offloading the actual intensive work to these libraries (which may or may not run on GPU depending on your hardware).
If your ML model takes hours when it can take minutes, or takes days when it can take hours, you will move away. You could move away to another language or a faster interpreter but that's a different discussion.
> more focus con optimizing the interpreter
This is good but there's an upper bound to performance of interpreted languages. Maybe the Python interpreter could be as fast as V8, but it is unlikely to be fast as JVM. People will need to drop down to C / Fortran for whatever compute intensive work they're doing.
Hopefully Foreign Function & Memory API [0] makes FFI so much easier that we get to drop down to C without much fuss.
Depends on who you think an average HN user is.
How so? It seems to me that actually decreases the burden. For example C# people may not implement the Rust ABI if they don't want to, but since they (and basically every language) already support C ABI, I can implement a library over the existing C ABI so that I can access Rust types.
Prices went up. Inflation is the rate of increase in prices. So slower increase means lower inflation. No increase is 0% inflation, decrease is deflation / negative inflation.
Are you working at a more "serious" company where they only use languages with the safety level of Assembly?
More broadly, are there plans to support C extensions that are available in GCC and clang?
ImportC is basically a C frontend for the D compiler, semantics are close enough but there are some changes to be made still.
Rust is a whole another conversation. You can pretty much do whatever you can do in Zig with Rust, and Rust has the advantage of hardcore memory safety using the borrow checker. It is also a very nice language to use, but it is complicated.
You see, Zig is sort of the C to Rust's C++. I don't mean this in the sense that Zig can't replace C++ (it can) or Rust can't replace C (it can), but it is obvious that C is a simpler language to learn than C++.
So yeah, you kind of don't need Zig when you have Rust and willing to use it for everything, but if you don't want to deal with a complicated language and the borrow checker, Zig is the language for you. It is basically C with some footguns removed + some features added (tagged unions, proper error handling, etc).
Ah, and Rust has long compile times. It is being worked on since 2013 [0] or earlier. Zig is serious about their compile times as you can read about the self-hosted backends for debug compilation speed in the release notes.
I don't know if Rust has any production-ready alternative backends that are fast. People always say LLVM is the reason Rust is slow to compile and you can use cargo check to confirm that, but it is obvious that is more of a priority for Zig team when compared to Rust team.
I sort of don't care about compile times of Rust at this point since the guarentees Rust make is more important to me than the compile times, but that may not be the case for everyone. I'll also use Zig when it is stable enough for my taste for non-safety critical stuff.
Your objects in trees and arrays don't have the same lifecycle?
Quoting GP:
> ... reference counting (RC) have stampeding characteristics similar to GC pauses when releasing large hierarchies e.g. persistent data structures, or large trees of widgets: all the tree is freed synchronously and recursively, if it's large it can be very sensible.
This is mostly where RC & MMM fails. This is also where you are supposed to use arena allocators.
If you have a tree you're constantly adding to / deleting from, you can use a Pool backed by an Arena. At that point you don't use pointers, only indices into the pool. When you want to remove something from the tree, you mark the objects in the pool "deleted" until you want something added back again.