I code in C# and I find the language and its ecosystem lack luster. There are lots of packages that are not active. Also, the language doesn't have good generics, no sum types, no decorators support
Can you help me understand your point of view a little bit more? I’ve been working for decades in C# professionally with a few stints in other languages and plenty of smaller side projects in any number of different ecosystems. I always find myself frustrated with “the experience” of working with many other languages. They all have their own pros and cons of course, but saying you don’t like the language because it doesn’t have sum types feels like saying you don’t like a Prius because it doesn’t have a pickup bed. Not a perfect analogy, but there are so many other features of C#’s type system that make it amazing to work with and it’s continually being improved year over year. I would be interested in knowing what types of things about the generics system you wish could be improved.
I find a need for specialisation at a lot of places and it simply doesn't exist in C#. Meta programming in C# almost everytime requires reflection which adds to uncertainty and compromises on readability. Other two are what I posted in original comments.
Struct generics in C# are monomorphized - exact same as in Rust.
Combine that with pattern matching and you can go quite far. In place of macros you can use source generators, although they are both weaker and stronger than proc macro depending on what you use them for.
Not totally sure what you're looking for, but what I did when I made a package for arena allocators in Julia, I made the arena task-local rather than global.
That means that if you spawn a concurrent task and then request the arena to allocate something to, you'll be writing to a completely separate chunk of memory than the memory used by the arena in the parent task.
Users can still cause race conditions by explicitly passing an existing arena across task boundaries, but if they use the function to fetch the currently-active task-local allocator, it's naturally threadsafe without any slow locks or atomics required.
My experience with arena allocators comes from Bloomberg's C++ libraries[1].
For example, here's the documentation[2] for a thread safe heterogeneous allocator and header[3] for the underlying thread safe pool.
It uses a mutex, but at a glance only when it needs to consult the fallback allocator (which could involve a system call). If you knew that the fallback allocator were a pre-allocated arena, maybe you could do with atomics only. The free list is already lock-free, and so too could be the block list.
A bump allocator can be implemented using atomics, but it does not support freeing individuals elements. I have seen some CAS heaps (linked list like) but I never had to implement them.
Heroku is not Fly.io. Heroku was bought by the MBAs a while back, and they do something different than generic cloud hosting (they are closer to a hosted EBS). If you bother scrolling at all, you'll notice immediately below the fold that the pricing is not remotely as clear as you're pretending it is.
I have seen company say utter bullshit in similar questions. I got smart replies from HR when asked tough and later fired me in an event with opposite experience compared to what they promised.
Yes. You choose a standard version (usually the latest stable 3.12 currently) that it downloads at setup or it downloads and sets up the pinned version from your pyproject.toml.
reply