Victorien Elvinger
@conaclos.bsky.social
@biomejs founder & lead maintainer - @Inria R&D engineer - PhD in Computer Science.
TypeScript & Rust 🦀 programmer.
Researcher in distributed systems 🕸️, embedded systems, #CRDT.
TypeScript & Rust 🦀 programmer.
Researcher in distributed systems 🕸️, embedded systems, #CRDT.
According to the articles you shared, free will makes us better individuals. However, I believe that, as a society, we should consider determinism if we are to build a fairer, more pragmatic and compassionate society.
November 2, 2025 at 10:30 PM
According to the articles you shared, free will makes us better individuals. However, I believe that, as a society, we should consider determinism if we are to build a fairer, more pragmatic and compassionate society.
Personally, I think that, given the amount of scientifically discovered determinism (physical, social, etc.), it is difficult to believe in free will. I can believe in some randomness at small scale, however if we define free will as random will, it is no longer free will...
November 2, 2025 at 10:23 PM
Personally, I think that, given the amount of scientifically discovered determinism (physical, social, etc.), it is difficult to believe in free will. I can believe in some randomness at small scale, however if we define free will as random will, it is no longer free will...
Taking your words, if you made your choices based on a framework of thoughts that is determined by your experience/knowledge, where does that leave free will?
November 2, 2025 at 10:18 PM
Taking your words, if you made your choices based on a framework of thoughts that is determined by your experience/knowledge, where does that leave free will?
I don't get the paradox part. If you believe in full determinism, then free will is an illusion as well as the choice of believing or not in that.
November 2, 2025 at 10:14 PM
I don't get the paradox part. If you believe in full determinism, then free will is an illusion as well as the choice of believing or not in that.
You can also be interested in:
- alloc_instead_of_core
- default_numeric_fallback
- float_arithmetic
- format_collect
- inefficient_to_string
- large_include_file
- large_stack_arrays
- std_instead_of_alloc
std_instead_of_core
- struct_excessive_bools
- trivially_copy_pass_by_ref
- alloc_instead_of_core
- default_numeric_fallback
- float_arithmetic
- format_collect
- inefficient_to_string
- large_include_file
- large_stack_arrays
- std_instead_of_alloc
std_instead_of_core
- struct_excessive_bools
- trivially_copy_pass_by_ref
September 4, 2025 at 7:07 PM
You can also be interested in:
- alloc_instead_of_core
- default_numeric_fallback
- float_arithmetic
- format_collect
- inefficient_to_string
- large_include_file
- large_stack_arrays
- std_instead_of_alloc
std_instead_of_core
- struct_excessive_bools
- trivially_copy_pass_by_ref
- alloc_instead_of_core
- default_numeric_fallback
- float_arithmetic
- format_collect
- inefficient_to_string
- large_include_file
- large_stack_arrays
- std_instead_of_alloc
std_instead_of_core
- struct_excessive_bools
- trivially_copy_pass_by_ref
Yes, this is BARE's first announcement. I later helped improve its specifications and shape its current form.
June 26, 2025 at 11:46 AM
Yes, this is BARE's first announcement. I later helped improve its specifications and shape its current form.
I was just wondering. Were you aware of baremessages.org when you started postcard?
BARE Message Encoding
baremessages.org
June 26, 2025 at 9:33 AM
I was just wondering. Were you aware of baremessages.org when you started postcard?
Yeah, I agree. Many libraries don't comply with `exactOptionalPropertyTypes`. I had to disable it because of this.
Also, I agree that `noUncheckedIndexedAccess` is really picky. I am unsure whether it is possible to easily write code that deals with arrays when this option is enabled.
Also, I agree that `noUncheckedIndexedAccess` is really picky. I am unsure whether it is possible to easily write code that deals with arrays when this option is enabled.
June 7, 2025 at 11:13 AM
Yeah, I agree. Many libraries don't comply with `exactOptionalPropertyTypes`. I had to disable it because of this.
Also, I agree that `noUncheckedIndexedAccess` is really picky. I am unsure whether it is possible to easily write code that deals with arrays when this option is enabled.
Also, I agree that `noUncheckedIndexedAccess` is really picky. I am unsure whether it is possible to easily write code that deals with arrays when this option is enabled.
There are some rationales here in the relevant issue.
> these options are annoying to enable later, but straightforward to comply with in a greenfield situation. It'e best to start with them on and turn them off if you don't like them.
> these options are annoying to enable later, but straightforward to comply with in a greenfield situation. It'e best to start with them on and turn them off if you don't like them.
tsc --init update 2024 · Issue #58420 · microsoft/TypeScript
Acknowledgement I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion. Comment Following up from #58417 Note: This is only for argum...
github.com
June 7, 2025 at 10:56 AM
There are some rationales here in the relevant issue.
> these options are annoying to enable later, but straightforward to comply with in a greenfield situation. It'e best to start with them on and turn them off if you don't like them.
> these options are annoying to enable later, but straightforward to comply with in a greenfield situation. It'e best to start with them on and turn them off if you don't like them.
I think exposing types from dependencies to consumers breaks encapsulation. Of course, there are cases where it is acceptable. In general, though, it seems like poor practice to me.
May 29, 2025 at 9:55 PM
I think exposing types from dependencies to consumers breaks encapsulation. Of course, there are cases where it is acceptable. In general, though, it seems like poor practice to me.
I am a bit surprised by the number of NPM dependencies of tsdown (about 40). Because it builds on Rolldown, I was expecting many fewer. However, this is still an improvement on the unbuild, which had hundreds of dependencies.
May 23, 2025 at 8:10 AM
I am a bit surprised by the number of NPM dependencies of tsdown (about 40). Because it builds on Rolldown, I was expecting many fewer. However, this is still an improvement on the unbuild, which had hundreds of dependencies.
I watched three seasons. I might come back one day. The end of the third season was pretty tough.
May 8, 2025 at 8:35 PM
I watched three seasons. I might come back one day. The end of the third season was pretty tough.
It seems that the Records & Tuples proposal is withdrawn in favor of Composite Keys.
docs.google.com/presentation...
docs.google.com/presentation...
Composite April 2025
'Composites' proposal For stage 1
docs.google.com
April 13, 2025 at 7:43 PM
It seems that the Records & Tuples proposal is withdrawn in favor of Composite Keys.
docs.google.com/presentation...
docs.google.com/presentation...
It could be nice to see if codegen could be easier and quicker with Facet avoiding proc-macro and the like.
April 11, 2025 at 12:47 PM
It could be nice to see if codegen could be easier and quicker with Facet avoiding proc-macro and the like.
Do the use cases always use runtime reflection or do they generate code at compile time using the const data provided by Facet?
April 11, 2025 at 12:15 PM
Do the use cases always use runtime reflection or do they generate code at compile time using the const data provided by Facet?
It also allows you to write enum flags more easily: you can declare a composite flag that corresponds to the union of several flags.
April 5, 2025 at 10:35 AM
It also allows you to write enum flags more easily: you can declare a composite flag that corresponds to the union of several flags.
From an implementation point of view it is not totally true. Engines do many optimizations to use actual arrays. They even have dedicated optimizations for holey arrays (arrays with holes aka sparse arrays).
April 2, 2025 at 9:03 PM
From an implementation point of view it is not totally true. Engines do many optimizations to use actual arrays. They even have dedicated optimizations for holey arrays (arrays with holes aka sparse arrays).
They are good days because you realize that you still have so much to learn. This is the prerequisite for acquiring new knowledge :)
April 2, 2025 at 8:55 PM
They are good days because you realize that you still have so much to learn. This is the prerequisite for acquiring new knowledge :)
True. Note thta 21.x is no longer maintained.
March 22, 2025 at 10:03 AM
True. Note thta 21.x is no longer maintained.
For anyone wondering: `require(esm)` is enabled by default since Node.js 20.19.
Node.js — Node v20.19.0 (LTS)
Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine.
nodejs.org
March 19, 2025 at 7:35 PM
For anyone wondering: `require(esm)` is enabled by default since Node.js 20.19.
For those wondering what a dual-package hazard is, take a look at
GitHub - nodejs/package-examples: Repository documenting package shipping patterns
Repository documenting package shipping patterns . Contribute to nodejs/package-examples development by creating an account on GitHub.
github.com
March 14, 2025 at 8:25 PM
For those wondering what a dual-package hazard is, take a look at