ugly code
Perfect code doesn’t guarantee success if you haven’t solved a real problem for real people. Pursuing elegance in a vacuum leads to abandoned side projects or frameworks nobody uses. By contrast, clunky but functional code often comes with just the right compromises for quick iteration. And that in turn means a lot of messy code powers products that people love — something that’s a far bigger challenge.
Are you shipping a product and racing to meet user needs? Or are you building a reusable library or framework meant to stand the test of time?
Both mindsets are valid, but they rarely coexist harmoniously in a single codebase. Flamework is a reminder that messy, simple solutions can be powerful if they solve real problems. Eventually, when the time is right, you can clean it up or rebuild from the ground up.
no_std rust
| feature | no_std | std |
|---|---|---|
| heap (dynamic memory) | note 1 | yes |
| collections (Vec, BTreeMap, etc.) | note 2 | yes |
| stack overflow protection | no | yes |
| run init code before main | no | yes |
| libstd | no | yes |
| libcore | yes | yes |
| firmware, kernel or bootloader | yes | no |
note 1: only if you use the
alloccrate and use a suitable allocator likealloc-cortex-mnote 2: only if you use the
collectionscrate and configure a global default allocator.note 2: HashMap and HashSet are not available due to a lack of a secure random number generator.
ref
most popular spanish names
| female | male |
|---|---|
| maria: sea of sorrow | jose: god will increase |
| carmen: garden, guard, and song | luis: renowned warrior |
| ana: grace, mercy | manuel: god is with us |
| isabel: god is my oath | francisco: free man |
| maria carmen: sea of sorrow, garden | juan: god is gracious |
| dolores: sorrow | javier: new house |
| pilar: pillar | miguel: who is like God |
| teresa: harvester | carlos: free man |
| rosa: rose | angel: messenger |
| lucia: light | alberto: nobel and bright |
| esther: star | ramon: wise protector |
| luz: light | diego: teaching |
parallelism models: actor, CSP, multithread
- actors model: erlang, scala, rust
- CSP: go
- threads: java, C#, C++
multithread: deadlocks, bad scaling, shared state.
Both CSP and actor-based parallelism models are based on message passing. In both models, the receiver is synchronous: when it’s ready to listen for messages it blocks until it gets a message (although variants allow for them to do a non-blocking poll or have a time out).
CSP is fully synchronous. A channel writer must block until a channel reader reads. The advantage of that blocking based mechanism is that a channel only needs to ever hold one message. It’s also in many ways easier to reason about.
With actors sending is asynchronous. A message sender will not block whether the reader is ready to pull from the mailbox or not, instead the message goes into a queue usually called a “mailbox”. Which is convenient, but it’s a bit harder to reason about and mailboxes potentially have to hold a lot of messages.
In CSP processes communicate using channels. Program can create and pass them around as first class objects. Actors have an address system and inboxes. Only one address per process.
In CSP send and receive operation may block. In Actors Model only receive operation may block.
In CSP messages are delivered in order they were send, in Actors model it’s not the case. In fact system may not be able to deliver some messages at all. So far CSP model works best on one machine, while Actors model scales easily across several machines.
In a conclusion: Actors are more appropriate for distributed systems. Because of blocking nature of CSP, it’s hard to use them across several machines/runtimes.