Hovering over the "6 months" bit displays a hint, "Monday, 13 October 2025 at 23:30:00". (ETA: though it doesn't say in which timezone.)
.
As for the bit of content we are allowed to see, it certainly didn't sell me on Rust... but sure confirmed my resolution to avoid JavaScript at all cost.
Yes, and the video is available in full right now. That’s my current business model. (I’m the author but I didn’t post the article here — I would expect older articles to show up)
- I've found a total of one use case for Object.freeze until today. Since exported modules are live bindings and are mutable, exporting a global object which is not intended to change during the runtime (e.g. an application wide config) is a bad idea. Exporting the object after wrapping it in Object.freeze can help avoid unnecessary mutations to it.
Same as @conradludgate's answer, but stated differently. If you say you need &String in your function, then you can pass only &String in a function call. But if you say you need &str in your function, then you can pass either &str or &String. Rust will automatically convert the &String to &str using a mechanism called 'Deref coercion'.
And if you are wondering what the difference between &String and &str is, you need to start with a regular String. Strings are utf-8 encoded strings that may be modified at runtime. They are made of 2 parts in the memory. The first part is on the heap memory - a memory buffer of specific size that is filled partially or fully with utf-8 encoded text. The second part is usually (but not always) on the stack frame of the current function. It holds the metadata about the heap memory text buffer I mentioned earlier - that is, the pointer to the start of the buffer, the full size of the buffer and the size of the text currently occupying that buffer. (If you are wondering why you need the metadata part, it's because it has a fixed size and structure known at compile time, unlike the actual text buffer). When we take the reference &String, we get a safe pointer to the second part (the metadata).
Now &str. It's a reference to a fixed sized sub-string (slice) of a full string somewhere in the memory. (That sub-string can be the full string too). Since it points to a fixed-size portion of a string, it has only a pointer to the beginning of the sub-string and the size of the sub-string. (It's not concerned with the buffer's size at all).
The Deref coercion of &String to &str converts the pointer pointing to the metadata part of the String, to a pointer pointing at the buffer containing the actual text. This happens transparently.
This long an answer is irrelevant to the topic in the article. That's perhaps why it's omitted.
It's not too important. String is a String-Builder, it is a pointer+length+capacity. &String is thus a pointer to a pointer.
The idiomatic solution is to use &str, which is a string-view or string-slice, which is only a pointer+length.
&String can implicit cast to &str via deref-coercion, which means that it's free for APIs to only accept &str. Accepting &str is more correct in the idea that not all strings need to be allocated individually, some might be sliced from a larger string, and losing that generality would be a shame.
After a promising start, it says:
"The rest of this article is exclusive!
This article will unlock in 6 months"
Hovering over the "6 months" bit displays a hint, "Monday, 13 October 2025 at 23:30:00". (ETA: though it doesn't say in which timezone.)
.
As for the bit of content we are allowed to see, it certainly didn't sell me on Rust... but sure confirmed my resolution to avoid JavaScript at all cost.
Yes, and the video is available in full right now. That’s my current business model. (I’m the author but I didn’t post the article here — I would expect older articles to show up)
Not the point of the article but just two cents about the JS part:
- While not part of the ECMAScript spec, there is a Web API called structuredClone for deep copying objects. It's implemented in major runtimes like Node (17+), Bun and Deno. https://developer.mozilla.org/en-US/docs/Web/API/Window/stru...
- I've found a total of one use case for Object.freeze until today. Since exported modules are live bindings and are mutable, exporting a global object which is not intended to change during the runtime (e.g. an application wide config) is a bad idea. Exporting the object after wrapping it in Object.freeze can help avoid unnecessary mutations to it.
Not sure if the article mentions this later but JS has structuredClone now which should be better than the stringify/parse dance in the example: https://developer.mozilla.org/en-US/docs/Web/API/Window/stru...
> // note: taking `&String` is needlessly restrictive, but one thing at a time
Why? Even the video doesn't explain it, but I feel that's quite important to the article/video.
Same as @conradludgate's answer, but stated differently. If you say you need &String in your function, then you can pass only &String in a function call. But if you say you need &str in your function, then you can pass either &str or &String. Rust will automatically convert the &String to &str using a mechanism called 'Deref coercion'.
And if you are wondering what the difference between &String and &str is, you need to start with a regular String. Strings are utf-8 encoded strings that may be modified at runtime. They are made of 2 parts in the memory. The first part is on the heap memory - a memory buffer of specific size that is filled partially or fully with utf-8 encoded text. The second part is usually (but not always) on the stack frame of the current function. It holds the metadata about the heap memory text buffer I mentioned earlier - that is, the pointer to the start of the buffer, the full size of the buffer and the size of the text currently occupying that buffer. (If you are wondering why you need the metadata part, it's because it has a fixed size and structure known at compile time, unlike the actual text buffer). When we take the reference &String, we get a safe pointer to the second part (the metadata).
Now &str. It's a reference to a fixed sized sub-string (slice) of a full string somewhere in the memory. (That sub-string can be the full string too). Since it points to a fixed-size portion of a string, it has only a pointer to the beginning of the sub-string and the size of the sub-string. (It's not concerned with the buffer's size at all).
The Deref coercion of &String to &str converts the pointer pointing to the metadata part of the String, to a pointer pointing at the buffer containing the actual text. This happens transparently.
This long an answer is irrelevant to the topic in the article. That's perhaps why it's omitted.
It's not too important. String is a String-Builder, it is a pointer+length+capacity. &String is thus a pointer to a pointer.
The idiomatic solution is to use &str, which is a string-view or string-slice, which is only a pointer+length.
&String can implicit cast to &str via deref-coercion, which means that it's free for APIs to only accept &str. Accepting &str is more correct in the idea that not all strings need to be allocated individually, some might be sliced from a larger string, and losing that generality would be a shame.
I confess to feel weird at the idea to need a copy to print something twice
References avoid this:
That should feel weird because it is inefficient & unnecessary
https://news.ycombinator.com/item?id=41770479 > Re paywalls: if there's a workaround, it's ok. ...
> The converse is also true: if there's not a workaround, it's not ok.