Rust is an engineering tool, a really good modern tool (but still just a tool, not an egregor), applied and adopted already in many critical areas (like cyber security, distributed systems, cryptography, decentralised financial systems, AI), a type safe language, which respects safety, and way much better designed than C++, or Go (inconsistent data structures implementation, where behaviour depends on implementation, implicitly satisfied interfaces, is a truly nightmare), or even C. There's no usable system level language with integrated non-optional type safety on a type system level (rather than having all that kind of external tools, like linting, fuzzying, sanitizers, etc.). Probably from modern languages only Mojo and ATS can be accompanying Rust in this group (a type safe language with static typing and static memory management).
And thus learning curve is pretty steep and entry barrier is pretty high for Rust ecosystem.
The C language is a basis, fundamental technology, it's pretty simple, sharp, and dangerous, where freedom == responsibility.
The only cool thing of C++ is SFINAE. But it's a dynamic implicit thing for types coercion, thus completely eliminated by Rust type system.
#Rust
#CPP
#C
#Notes
#Thoughts
And thus learning curve is pretty steep and entry barrier is pretty high for Rust ecosystem.
The C language is a basis, fundamental technology, it's pretty simple, sharp, and dangerous, where freedom == responsibility.
The only cool thing of C++ is SFINAE. But it's a dynamic implicit thing for types coercion, thus completely eliminated by Rust type system.
#Rust
#CPP
#C
#Notes
#Thoughts
Technologique
Python 3.14 https://blog.miguelgrinberg.com/post/python-3-14-is-here-how-fast-is-it In short - new Python 3.14 it's awesome! Worth to update immediately! 3.14 is way much better in performance than any previous versions, has optionally enabled JIT (doesn't…
NoGIL is definitely a huge leap forward!
From 3.13 GIL can be disabled... but for this we need customly build interpreter from sources. That's the point should be refined.
Cause not every main Linux distro now provide prebuilt packages, only Fedora (
This will provide
But... free-threaded CPython build is not thread safe!
Thread safety, i.e. managing shared mutable state for simultaneous threads, using locks, mutexes and other synchronization primitives - are fully on developer. Python code is thread safe. But CLang code (via FFI) and Python interpreter code itself, that written in CLang, can allow access to the same memory, for pointers in several threads, lead to data race and deadlocks. Also can lead to dead/hanging objects in memory and thus memory leaks in long uptimes.
And this will affect run-time and revealed only in run-time.
(While in Rust for example pointers/references are typed and type-safe, thus allocations/deallocations, objects lifetimes tracking, pointers/references to same data and memory regions, are tracked in compile time, via move semantics, which completely prevents dangling pointers.)
Thus memory sanitizers and threads sanitizers should be used for free-threaded CPython. And not all main/core libraries in PyPI now support free-threading.
https://docs.python.org/3/howto/free-threading-python.html
https://py-free-threading.github.io/installing-cpython/
https://py-free-threading.github.io/running-gil-disabled/
https://py-free-threading.github.io/debugging/
https://py-free-threading.github.io/thread_sanitizer/
#Python
#notes
From 3.13 GIL can be disabled... but for this we need customly build interpreter from sources. That's the point should be refined.
Cause not every main Linux distro now provide prebuilt packages, only Fedora (
python3.14-freethreading package), OpenSUSE (python314-nogil package), Ubuntu (python3.14-nogil package through external PPA) and Nix (python314FreeThreading package), in Gentoo via own ebuild, or in Arch via own pkgbuild script.This will provide
python3.14t with NoGIL enabled by default, and we can enable GIL with PYTHON_GIL environment variable or the command-line option -X gil for CPython.But... free-threaded CPython build is not thread safe!
Thread safety, i.e. managing shared mutable state for simultaneous threads, using locks, mutexes and other synchronization primitives - are fully on developer. Python code is thread safe. But CLang code (via FFI) and Python interpreter code itself, that written in CLang, can allow access to the same memory, for pointers in several threads, lead to data race and deadlocks. Also can lead to dead/hanging objects in memory and thus memory leaks in long uptimes.
And this will affect run-time and revealed only in run-time.
(While in Rust for example pointers/references are typed and type-safe, thus allocations/deallocations, objects lifetimes tracking, pointers/references to same data and memory regions, are tracked in compile time, via move semantics, which completely prevents dangling pointers.)
Thus memory sanitizers and threads sanitizers should be used for free-threaded CPython. And not all main/core libraries in PyPI now support free-threading.
https://docs.python.org/3/howto/free-threading-python.html
https://py-free-threading.github.io/installing-cpython/
https://py-free-threading.github.io/running-gil-disabled/
https://py-free-threading.github.io/debugging/
https://py-free-threading.github.io/thread_sanitizer/
#Python
#notes
Python documentation
Python support for free threading
Starting with the 3.13 release, CPython has support for a build of Python called free threading where the global interpreter lock(GIL) is disabled. Free-threaded execution allows for full utilizati...