ericjmorey

The blog post is the author's impressions of Gleam after it released version 1.4.0. Gleam is an upcoming language that is getting a lot of highly-ranked articles.

It runs on the Erlang virtual machine (BEAM), making it great for distributed programs and a competitor to Elixir and Erlang (the language). It also compiles to JavaScript, making it a competitor to TypeScript.

But unlike Elixir, Erlang, and TypeScript, it's strongly typed (not just gradually typed). It has "functional" concepts like algebraic data types, immutable values, and first-class functions. The syntax is modeled after Rust and its tutorial is modeled after Go's. Lastly, it has a very large community.

Isaac Harris-Holt writes:

Modern software engineering can be a bit of a nightmare. You've got all these different third-party services to keep track of, and often many first-party microservices too! As it turns out, things can be made more simple using Gleam. Let me show you how.

Louis Pilfold, the creator of the Gleam Programming Language, has been maintaining a Youtube Playlist of Gleam videos.

2024-02-29 | Christopher Gadzinski writes:

Physics likes optimization! Subject to its boundary conditions, the time evolution of a physical system is a critical point for a quantity called an action. This point of view sets the stage for Noether's principle, a remarkable correspondence between continuous invariances of the action and conservation laws of the system.

In machine learning, we often deal with discrete "processes" whose control parameters are chosen to minimize some quantity. For example, we can see a deep residual network as a process where the role of "time" is played by depth. We may ask:

1. Does Noether's theorem apply to these processes?
2. Can we find meaningful conserved quantities?

Our answers: "yes," and "not sure!"

Itamar Turner-Trauring writes:

These sort of problems are one of the many reasons you want to “pin” your application’s dependencies: make sure you only install a specific, fixed set of dependencies. Without reproducible dependencies, as soon as NumPy 2 comes out your application might break when it gets installed with new dependencies.

The really short version is that you have two sets of dependency configurations:

• A direct dependency list: A list of libraries you directly import in your code, loosely restricted. This is the list of dependencies you put in pyproject.toml or setup.py.
• A lock file: A list of all dependencies you rely on, direct or indirect (dependencies of dependencies), pinned to specific versions. This might be a requirements.txt, or some other file dependencies on which tool you’re using.

At appropriate intervals you update the lock file based on the direct dependency list.

I’ve written multiple articles on the topic, in case you’re not familiar with the relevant tools:

• “Faster Docker builds with pipenv, poetry, or pip-tools” covers using those three tools to maintain lockfiles.
• For Conda, see “Reproducible and upgradable Conda environments with conda-lock”.

Read NumPy 2 is coming: preventing breakage, updating your code

Source by joedeandev

Update: !ios_dev@programming.dev has been created, temporarily managed by @Ategon@programming.dev until some mods volunteer for it