I have the feeling that social media adoption can be very volatile - that makes me hope that something decentralized and healthier could take over soon.
Regarding Bluesky-based Flashes, there is an ongoing GoFundMe campaign, but it's been there for 7 months and hasn't reached its 40k goal. Regardless of the funding goal, aren't there enough people interested in this to make it happen?
I think that's indeed one of the main problems, although I think people don't care because they don't understand what are the risks that directly concern them. A valid question would be at what point (if ever, and I want to believe that is going to happen, sooner or later) is the average user going to perceive the problems associated with centralized, censoring, opinion-steering platforms?
I very much agree. I think that one of the fundamental things that would make it easier for a healthier way forward would be the ability to more easily move from one platform to the other, hence reducing inertia-induced monopoly. Bluesky's At Protocol baked in interoperability seems like a step forward.
It’s worrying how much control platforms like Meta have over what people see. Their moderation and ranking systems often act as invisible filters—shadowbanning, or quietly removing reach without transparency.
This kind of centralization makes open discourse fragile. It’s why I think distributed and independent ways of sharing information are becoming essential—so no single company decides which voices are amplified or buried.
Thanks for the answer! What I would find very useful is an API that allows one to call directly BLAS/LAPACK routines. Is that possible in SciNim? If not, how difficult would it be to write the necessary wrappers? I had a quick look at the repo, but could not find the answer myself :p
Pretty cool. Would love to use Nim for scientific computing, but I am not sure how mature are, e.g., Neo (https://github.com/andreaferretti/neo) and alike. Any positive feedback?
I agree that error handling is one of the main things to be improved. The problem is that in some cases the AST walker ends up in unhandled states and prometeo throws a generic exception with a line number only. Are you looking at something in particular? With basically 0 users at the moment, this kind of feedback is quite useful.
Anyway, the main point is to give it a name that is as informative as possible. If I read "transpiler" I immediately make the connection with the fact that it translates a high-level language into another high-level language (which is what prometeo does)- but maybe I am biased.
No, that's not the timescale of interest, I would say. However, if the big chunk of computations is delegated to HPC libraries I would say that NumPy could be rather competitive there (although still not easy to embed). If instead you need to run many times the same piece of code where a large fraction is pure Python, of course, it would not change the picture with respect to the "small" computations scenario.
I though about using Nim as a host language for the DSL for a while, but then decided to rely on Python simply because it is more mature (and I had already partially figured out how to manipulate Python ASTs to generate C code).
Right, for sure I would not need to re-invent the machinery to translate a class into a glorified C struct. The whole thing started with C in mind for portability arguments, but it might be a good idea to keep an eye on C++ as an option.
Intrinsics (or directly assembly) are used in BLASFEO (https://github.com/giaf/blasfeo) the linear package used by prometeo. It would be cool to generate assembly directly for a few things, but that would require quite a bit of work!
Thanks for the question! My background is in numerical optimization for optimal control. Projects like this https://github.com/acados/acados motivated the development of prometeo. It's mostly about solving optimization problems as fast as possible to make optimal decisions in real-time.
Not sure what a "superoptimizer" would look like in this context. For a reference, I know for sure that this https://github.com/giaf/blasfeo (which beats Intel MKL) was coded entirely by hand.
if we are arguing that implementing a numerical algorithm in C is as easy as implementing it in Python - I would disagree. But maybe I am just wrong :)