ccanassa

Beni creator here.

This is a language/research project. I want to explore what a combination of a purely functional language and a very advanced compiler is capable of generating in terms of JS.

One novel idea (AFAIK) is adding a borrow checker. Other languages targeting the browser have added borrow checkers, but that's been driven by WASM. In Beni, lists are immutable, but instead of being implemented using tries, they use regular JS arrays with in-place mutations. The borrow checker guarantees that ownership isn't shared and that it's safe to update them. One concern I have is that this could cause DX issues due to borrow checker errors. I don't think that's going to be an issue given that the language is functional, but it's still an open question.

The "Platforms" concept is an idea I borrowed from Roc, which also inspired many of Beni's design decisions. In Beni, you can't call JS directly, just like in Elm. Platforms wrap the JS ecosystem in a safe way so that it can be consumed by Beni. There's currently no way to install third-party JS libraries. I believe the NPM ecosystem is broken: even small libraries pull in hundreds of indirect dependencies. With AI, new CVEs are being found every week, and keeping `npm audit` clean has become a daily struggle.

The irony is that updating dependencies to fix these mostly harmless CVEs just increases the risk of supply chain attacks. My idea for Beni is to make it "batteries included" so that people need fewer third-party dependencies. For everything else, I think the correct approach is to vendor the code you need.

This is very sus, I got almost the same pelican with Fable 5.1.

I got a lot of my taste in music from my father. Over time, I started discovering things on my own and branching out, but he definitely laid the groundwork. Led Zeppelin is still my favourite band. We didn't have the best relationship, to put it mildly, but I still think of him when I hear these songs, and I remember him fondly.

That exists, it's called code.

I think LLMs have solved that for Nix. I recently moved my homelab from an Ansible/Debian setup to NixOS. As long as I understand at a high level what Nix is and what problems it solves, I can let the LLM deal with the configuration language.

I’ve been reverse-engineering an obscure childhood game called Entomorph:

https://github.com/entomorph/reverse-engineering

I started the project when ChatGPT 4 was first released, using it as a way to explore what LLMs could actually do. I also find working on it very relaxing, there is something cool about uncovering secrets hidden in code for more than twenty years.

The main advantage of an ORM isn’t query building but its deep integration with the rest of the ecosystem.

In Django, you can change a single field in a model, and that update automatically cascades through to database migrations, validations, admin panels, and even user-facing forms in the HTML.

FastAPI/SQLAlchemy won’t be more scalable than a typical Django setup. The real bottleneck is the threading model, not the few microseconds the framework spends before handing off to user code. Django running under uWSGI with green threads can outperform Go-based services in some scenarios, largely thanks to how efficient Python’s C ABI is compared to Go.

Sounds like a hammer-and-nail problem to me.

Django works perfectly with green threads. It’s a superior model to async and avoids the whole function-coloring mess. I’ve seen Django setups outperform Go-based services running under similar conditions.

JavaScript is a terrible language and should only be used when there’s absolutely no alternative, such as in browsers.

In Brazil, you are expected to bring food or drinks when you are invited as a guest to a party. If you stay until the end, you are also expected to help clean up the place. Guests will often take over certain parts of the party without even asking, such as preparing drinks, taking care of the barbecue, serving people, or going to the store to buy more drinks.

That's why I still use two editors: IntelliJ for when doing "serious" work and Sublime when I need to edit random files or a huge JSON. I don't need anything in between.

The only thing that kept me from choosing Elixir was the lack of a type checker. Has that changed?

I work with Node every day, and the library ecosystem is a nightmare. Just keeping a project from falling apart takes a huge amount of effort. Libraries are either abandoned when the author moves on, or they push major releases almost every month. And there’s a new CVE practically every week.

Python libraries are much more stable and reliable.

That’s called Python or Ruby.

I’ve been building web apps since the ’90s, and I never understood the appeal of PHP. It was always a terrible language, and there were usually better alternatives available.

Nah man, I work with them daily. For me, the ceiling was reached a while ago. At least for my use case, these new models don’t bring any real improvements.

I’m not even talking about large codebases. It struggles to generate a valid ~400 LOC TypeScript file when that requires above-average type system knowledge. Try asking it to write a new-style decorator (added in 2023), and it mostly just hallucinates or falls back to the old syntax.

I love that the creators are considering adding gradual types.

Given TypeScript’s popularity, it’s clear that developers really appreciate types. Honestly, the lack of types is what eventually drove me away from Clojure.

In my country, the internet was frustratingly slow and expensive. To enjoy online gaming with my friends, we resorted to hosting LAN parties at someone's house. These gatherings were incredibly enjoyable, far surpassing the experience of playing alone online.

Moreover, our LAN parties had an unexpected benefit: we all became TCP/IP network experts. Each of us knew how to construct our cables.

That's basically how the Django admin works. It's just HTML rendered at the backend. They had to add some javascript here and there but it's very minimal.

I worked on some REALLY big Flask projects over my carrer and I came up with my rule for it:

"Any sufficiently large Flask project contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Django."

Just sticky with Django. It's stable, well-maintaned and includes most batteries out-of-the-box.

I spent 3 years building a high scale crawler on top of Celery.

I can't recommend it. We found many bugs in the more advanced features of Celery (like Canvas) we also ran into some really weird issues like tasks getting duplicated for no reason [1].

The most concerning problem is that the project was abandoned. The original creator is not working on it anymore and all issues that we raised were ignored. We had to fork the project and apply our own fixes to it. This was 4 years ago so maybe things improved since them.

Celery is also extremely complex.

I would recommend https://dramatiq.io/ instead.

[1]: https://github.com/celery/celery/issues/4426

My job as a dev is literary to automate human work.

My first job was to write C code for industrial machines that replaced humans doing manual work. Sometimes I even had to go watch them work so I could fully understand what they were doing.

In my second job as a developer, I wrote a Django application that automated away a whole department in the company. I saw 100 people getting fired due to a script that I wrote.

That was all happening in the third world country were I came from. These were real people getting fired, with families that depend on them. Most of them were already in poverty even before being fired.

These artists complaining sound like a very 1st world problem to me. I doubt that anyone actually "lost a job" because of this technology so far.

Damn! They managed to update the graphics while keeping the "feel" of the original game, that's quite an impresive feat.

Yes, I also think that the art didn't age very well, the 3D world being quite confusing to navigate IMO.

I forked an open source reversed engineered implementation of that game some time ago, you can see it in here: https://github.com/canassa/betrayal-at-krondor

My hope was to get it working and eventualy update some of its graphics but I never had the time to properly work on it.

Experience told me to be very conservative when picking frameworks. For small projects and personal, sure, just pick whatever you want and have fun! But for serious projects, you should stick with old and stable software.

I made the mistake of picking Flask for a really big project when these microframeworks were a fad and everyone was dismissing the big ones like Django and RoR. That was a very costly mistake. I learned the hard way provides way so many things out-of-box that I always took for granted but I had to manually implement in Flask.

Take tests for example, Django automatically makes sure that any DB operation is cleaned by the end of the test. That's sometimes that I never gave a thought until our Flask tests started leaking everywhere. The way that Django handles that problem is very clever and we had to manually do it Flask.

I am Python dev and I never heard of someone using brew to install virtualenv before. I think that you are using brew for the wrong purposes, I suggest the following instead:

- Python already includes the venv module, you don't need to install anything, just run `python -m venv <venv_dir>`

- You should manage multiple versions with pyenv instead of brew. Pyenv can be installed with brew.

It's unbeliable how many things Django gets right out-the-box. I am talking about things like i18n and i13n which are usually are afterthought for most of these frontend frameworks but Django already includes a amazing system for it.

I wouldn't advise using anything other than the tools blessed by the PSF for mission-critical stuff. Using Poetry for local development is fine but don't build a huge infrastructure around it and don't use in production.

I migrated the CI/CD of my company to Poetry some time ago, it worked fine for some time until we needed a feature that Poetry didn't support. I submitted a PR adding the feature to Poetry but their sole developer was apparently taking some time off and the project remained without any development for several months.

I migrated the CI/CD to use my own Poetry fork but it was very cumbersome, Poetry has a very weird build system so forking it is not simple.

At this point, I realized that I was just wasting time. There is nothing that Poetry does that the other (old and stable) tools don't do. Poetry was the result of me falling for the shiny toy syndrome.

I usually buy the best tool that I can afford, my reasoing is:

- This forces me to research first, if I am dropping €500 on a new piece of woodworking equiment I want to make sure that's not going to be wasted.

- There is a better market for used expensive tools and they can sell for a even higher price than a new one (I am looking at you Festool Domino)

- I pet my expensive tools. The cheap stuff just get throw around and get lost.

- There is a argument about buying a cheap one first and then once it breaks you get a better one. That doesn't really work for me, several of these cheap tools can last for ages.

- Good tools requires less skill to use; they just do their job. With cheap tools you have to account not only your lack of skill but also deviations introduced by the tool.

Yeah, me too. I do have some experience with functional languages (Clojure) but I never enjoyed languages with these "Railway-Oriented" constructs.