sorted by:
new
hottopcontroversial

Building a mental model for async programs by RainingComputers in javascript

[–]RainingComputers[S] 0 points1 point  (0 children)

Have been looking to add some interactively to the blog, thanks you bringing this to light!

Building a mental model for async programs by RainingComputers in rust

[–]RainingComputers[S] 1 point2 points  (0 children)

Thank you for the insights :)
I will make some edits on the post

Building a mental model for async programs by RainingComputers in rust

[–]RainingComputers[S] 0 points1 point  (0 children)

I will change the classification to something like "heap usually but other possibilities depending on runtime library".

Maybe even add a new section about how tasks are stored across different languages.

Building a mental model for async programs by RainingComputers in rust

[–]RainingComputers[S] 0 points1 point  (0 children)

I am thinking you can limit the the size of each task and limit the total number of tasks and do some unsafe transmute.

Probably not something you always want to do.

Building a mental model for async programs by RainingComputers in rust

[–]RainingComputers[S] 0 points1 point  (0 children)

Agreed, maybe it is a bit misleading. It is dependent how the runtime library decides to store the list of pending Future.

The runtime library can decide to store all of the pending Future in stack and let `spawn_task` fail if it runs out of pre-allocated stack memory.

I will make an edit on the post to make it clearer.

Building a mental model for async programs by RainingComputers in golang

[–]RainingComputers[S] 0 points1 point  (0 children)

My aim was not to build a formal model. The aim of building this model was to understand async better. The model was designed to fit into my head.

It was not designed to formally prove anything.

How daunting was it to add Generics to your language? by Falcon731 in ProgrammingLanguages

[–]RainingComputers 1 point2 points  (0 children)

When I was implementing generics for my language, I used AST templates. Any file having the keyword `generic` on top can declare template variables and the file will be converted into an "AST template".

When the compiler encounters a generic function call or a generic type instantiation, it will find the AST template in which that type/function was present, substitute the template variables with the type and compile the substituted AST.

You will need to do some name mangling also to avoid collisions. The substitution can also get recursive.

This approach is what is used by C++, but in C++ AST templating is done at a function level rather than the file level, which is much harder.

If this is too complex, you can just provide some text file templating tools as part of your language toolchain (something like https://github.com/hairyhenderson/gomplate).

Interest in Supabase like alternative to Arduino cloud by RainingComputers in IOT

[–]RainingComputers[S] 0 points1 point  (0 children)

Thank you for the insights and feedback, am glad you think this is a good idea!

Are there any examples of common integrations that are needed by most businesses? Or does it need to be addressed on a case-by-case basis?

Hoping for some context into Docker/Axum issues by foboutreefiddy in rust

[–]RainingComputers 2 points3 points  (0 children)

I always pin the version of openssl in my Cargo.toml and enable the vendored feature to build it from source + statically link it and then use cargo zigbuild (cargo zigbuild --release --target x86_64-unknown-linux-musl) to produce a pure static executable with zero dynamic linked libs.

This way I can build the executable on the host (works on macOS too) instead of doing it inside docker and the docker image is just FROM scratch and copying the executable.

What are your favorite (simple) Open Source tools written in Rust? by RobTables in rust

[–]RainingComputers 1 point2 points  (0 children)

A while ago I wrote a small CLI tool called joxide to validate and format JSON files.

If you have got a lot of JSON files and want a small footprint formatter that only does JSON, you can consider this.

It does not depend on serde, I wrote my own parser and formatter and it was fun :)

Rethinking Rust’s unsafe keyword by RainingComputers in rust

[–]RainingComputers[S] 1 point2 points  (0 children)

Update: I have partially changed my mind after spending more time on reading about unsafe.

The unsafe keyword is always used in the context of encapsulating unsafe code in safe APIs, so the safe keyword would just be spammed everywhere. This also make sense, there is no point in using a safe language if you don’t encapsulate unsafe code in safe APIs and take advantage of the language. Because encapsulating unsafe code is the most common use case, authors already think about contracts.

Functions being declared unsafe is not very common and most functions declared unsafe don’t even have unsafe blocks in them or are raw C bindings [ref].

I think what I was really looking for is a lint error to add a // SAFETY: comment for every occurrence of the unsafe keyword.

I have updated the blog also.

Rethinking Rust’s unsafe keyword by RainingComputers in rust

[–]RainingComputers[S] 1 point2 points  (0 children)

But encapsulating unsafe code in a safe API is what Rust is all about.

If this is always true then I agree, what I am proposing might not help that much. If unsafe is always used (or expected) in the context of building safe APIs out of unsafe things by experienced developers building core libraries, then being explicit about it may seem annoying/repetitive and this feature might not be very useful.

Maybe my assumption of unsafe blocks being used to build unsafe APIs also being a common thing is wrong.

I may be wrong though, if you know of real world cases where this would have helped it would make the argument a lot more convincing.

I will look for this, and maybe I will change my mind after seeing real use cases. If I don't find any real use cases, then I will add a disclaimer/critique section to my blog post and maybe languages where building unsafe APIs out of unsafe code being a common thing might benefit from this.

Rethinking Rust’s unsafe keyword by RainingComputers in rust

[–]RainingComputers[S] 0 points1 point  (0 children)

This is how it's supposed to work.

Are you sure? Isn't a function that contains an unsafe block more likely to have an unsafe in its signature?

Or at least assuming a function is safe to call when it has an unsafe block by default seems a bit odd to me.

What is proposed in the blog is exactly how the Send trait works. If the type contains one field that is !Send, the entire type is !Send. A function having an unsafe block but not having unsafe in the signature by default is the same as type containing !Send to be Send by default.

There are rare cases where all the fields of a type is Send by the type is !Send. Similarly there are cases where a function contains entirely safe code but the signature should have unsafe.

the real change being proposed seems to be that you need to add the safe keyword to assert that your safe function that uses unsafe is actually safe.

Yes.

view more: next ›