NeutralForest

It felt to me like they wanted to be the language for ML/DL, which they haven't achieved. They clearly have been working more towards scientific stuff + ML, all the differential equations and math packages are a testament to that (as well as the pharma stuff with Puma).

I'm not aware of what the vision is currently tbh

I like the language but I can't help but feel it missed the train and that the ergonomics improvements it offers are too small to switch over from Python.

Sounds like about one of the most insecure way to go about it since agents are unreliable and prompt injection is still an unsolved problem.

Yup then I'm with you

A track I'm quite interested in and that I plan to go to so I wonder if other people will join?

I'm firmly in the camp that you shouldn't mock the DB and have a local instance for testing but for external resources that you can't reproduce locally I think that's fine.

Otherwise I agree with you.

I just read the article, I agree with pretty much everything in there. Imo TDD (not really mentioned here but in the other article in the beginning) is still a good idea because it forces you to think about your design before getting bogged down into implementation details.

What often misses from such articles though is an example of how to get there. Nobody sets out to write bad code or brittle tests. So following along a codebase that used to suck and is slowly getting better would be great! Though I understand it's a much more involved exercise, I'm not holding it against the author.

Let's not "both sides" this issue.

I'm in Europe and I also have the democrat hashtag hidden but not the republican one. Between this and Musk salutes, it's very concerning.

I don't know the story but why does a language ever fail? Lack of good tooling support, lack of buy-in from large projects, lack of use-cases, crowded market, etc. Not only does every new language (at the time) need to have similar ergonomics to the existing landscape, they also need compelling features to escape the inertia that keeps developers within one ecosystem.

Looks fun!

If you could configure a fleet of machines from a browser window, over the network; that would be pretty cool. No clue how that would work in practice here though.

I mean, they're pretty much the same right? You can't abstract away the services and you need to pass arguments to the executable (ntpd in this case).

I don't see more or fewer issues, but I also don't see the value to using Scheme instead of a conf. file like format.

At the end, there's talk about adding the possibility to live reconfigure services, which is pretty cool but I don't really see what kind of users are targeted by that use-case, at least not regular users like me who's running Linux on a single laptop.

The link at the end (https://spritely.institute/news/spritely-nlnet-grants-decemb...) is IMO much more interesting since it would make it possible to orchestrate several machines and their services as well. If you have live reloading as well, I think it would make for good developer experience.

My main gripe with Guile is its ergonomics and tooling: no LSP, no linter, no step-debugger that I know of and the docs are often unhelpful imo.

Maybe I'm not Scheme brained enough but I think it's a shame because there are some really cool projects out there (anything https://spritely.institute/ really).

P.S: I know that some people will tell me to get used to REPL based development which I think is fine for small-ish projects but I can't understand the flow one uses for larger projects where many components might need to talk to each other.

Then I wish we had a higher bar for content.

I think the Austral language tries to do some capability based things: https://austral-lang.org/.

Thanks for all the write-ups on LLMs, you're on top of the news and it makes it way easier to follow what's happening and the existing implementations by following your blog instead.

From my experience, uv is way better and it's also PEP compliant in terms of pyproject.toml. Which means in cas uv isn't a big player in the future, migrating away isn't too difficult.

At the same time, poetry still uses a custom format and is pretty slow.

I feel like this as well sometimes. I have a pretty good setup there's been instances where things like activating the correct Python environment, have the LSP work properly or understand some arcane docs has been an issue. I don't see how Guile fixes any of this and it also suffers anemic docs imo.

Amazing, I'm really hoping Astral will stay in the game for long!

Nice thanks!

I know, not an amazing alternative imo as they're also saying it takes a long time. I just wish I didn't need to be all in into Guix to easily play around with such projects, which aside from that, look really cool.

Looks cool but I wish it were available with other package managers than guix :'( It makes a kinda hard to try out just for fun.

My bad, thanks for the correction.

I thought that was interesting and I definitely get the frustration in some aspect. I'm mostly familiar with Python and the function "coloring" issue is so annoying as it forces you to have two APIs depending on async or not (look at SQLAlchemy for example). The ergonomics are bad in general and I don't really like having to deal with, for example, awaiting for a result that will be needed in a sync function.

That being said, some alternatives were mentioned (structured concurrency à la Go) but I'd like to hear about people in BEAM land (Elixir) and what they think about it. Though I understand that for system languages, handling concurrency through a VM is not an option.

I've quickly skimmed the comments and haven't found a mention of briefcase (https://beeware.org/project/projects/tools/briefcase/) which is a tool to build standalone apps in Python.

Very cool to see public econ and history of economics represented! On top of the popular release, there's usually some advanced background info (https://www.nobelprize.org/uploads/2024/10/advanced-economic...) which is admittedly pretty massive but gives a lot of background about the Prize.

Looks interesting, thanks for sharing!

The abstract for the curious:

> Permacomputing is a nascent concept and a community of prac- tice centred around design principles that embrace limits and con- straints as a positive thing in computational culture, and on creativ- ity with scarce computational resources. As a result, permacomput- ing aims to provide a countervoice to digital practices that promote maximisation, hyper-consumption and waste. It seeks to encourage practices as an applied critique of contemporary computer tech- nology that privileges maximalist aesthetics where more pixels, more frame rate, more computation and more power equals more potential at any cost and without any consequences. We believe that such a critical practice can be relevant to artists, designers and cultural practitioners working with computer and network tech- nology who are interested in engaging with environmental issues. This is particularly relevant given the tendency in art, design and cultural production to rely on tools and techniques designed to maximise productivity and mass consumption. In this paper, we argue for the potential of permacomputing as a rich framework for exploring creative design constraints building on a long history of applying constraints in art, design and cultural practices. Because of the need to reconfigure the modes of produc- tion and organisation within computational practices, this calls for a different understanding of aesthetics, one that goes beyond the formal evaluation of how things look, but addresses how aesthetics can also be systems of relations, sensing and making sense that are already present in the process of making. We will also discuss the challenges faced by permacomputing practitioners, such as the complicated link with retro-computing, post-digital culture and nostalgia, as well as the problem of constraints in relation to the aesthetisation of poverty, and more generally what it means to work with self-imposed limits in a more privileged socioeconomic context.

Thank you!

I'd like to start with something that's more DB oriented like SQLite both locally and in the browser for example but I understand a documented-oriented approach might make more sense.

I've been hanging local-first circles but haven't made to switch to write anything with it yet. Is there a typical stack people recommend to get started? I'm not really sure where to start, especially in terms of backend.