" Integer representation – two’s complement Floating point – IEEE 754 Power-of-two byte/word sizes – There’s other good choices, but 8 bits per byte and 2^N bytes per word is a pretty good one Byte endianness – not universal, but basically settled on little endian for processors and I only foresee it becoming more universal with time. Network protocols are big-endian by default but that’s at least well defined, and not enough of an impediment to matter UTF-8 – You’re going to have a hard time coming up with a better variable-length integer representation that prefers small integers. There’s others that are just as good, or better for some specific purposes, but UTF-8 still has some nice properties. Serial connections and UART’s, whether RS-232 or TTL or whatever. There’s a million little variations but the basic setup is perfectly good for what it does. ELF executable format. Some improvements could be made, I’m sure, but all in all it’s pretty Fine. Paging over segmentation for memory management. There’s nothing fundamentally wrong with segmentation, but at least on any 32-bit chip, either you are an embedded system without much memory and don’t need an MMU, or you’re large enough to afford an MMU with paging. It’s still used on 8-bit microcontrollers but basically no popular 32+ bit CPU developed since the VAX has used segmentation. " -- https://wiki.alopex.li/ThingsWeGotRight
--- ---
~ mwcampbell 8 hours ago
| link | flag |
Mistake 7 : Build lifetime heavy API
I’ve struggled a bit with this. More generally, as a newcomer to Rust, I’ve found myself acting as if the slightest compromise in efficiency is a slippery slope straight to the excesses of Electron. Rust promises zero-overhead abstractions, so sometimes I try too hard to use the zero-overhead solution for everything. Another example is trying to make a struct or function generic instead of just using Box<dyn MyTrait?> or even Arc<dyn MyTrait?>.
6
zaphar 16 hours ago | link | flag | Rust exposes the fact that memory management for a linked list is hard. You can implement a linked list but satisfying the borrow checker while doing so is difficult. Many times you’ll just drop to some form of weak reference handle system backed by a vec. Which gives you the ergonomics of the linked list and less fighting the borrow checker.
~ fouric 8 hours ago
| link | flag |
Start by implementing a graph based algorithm.
My favorite personal projects are all intrinsically graph-based. Is Rust a poor fit for me?
~
gpm 7 hours ago | link | flag | Use something like petgraph you will be fine. Or if you’re implementing it by hand, store the nodes in an arena/vec and instead of pointers use indicies.
It’s a bit of a bigger step for newcomers, because you’re learning both “rust” and “how to deal with graphs in rust without fighting the borrow checker” at the same time, instead of one and then the other.
~ denys_seguret 19 minutes ago
| link | flag |
Same for me and I still manage to write them. Simply be sure to understand that you’ll have to suffer more than other people learning Rust if you start here. The best working approach is the arena+index one but it needs you to be very cautious (test units help, of course) as it means you’re going around the protection given by the ownership model.
---
generic design template:
(core) data structures; use cases; questions; UI screens/modes and flows between them; ui views / filters / queries; questions; inspirations; prime priorities and non-priorities; to do for design; notes/thoughts/main pages; documents/log/fAQ about design decisions that are supposedly finished and in the main pages; list of parts of the design (for example for a programming language, type system, syntax, control flow, etc) or maybe you don't need a list just look at the files that exist for main pages/thoughts/notes. Toreads. Free text introduction, free text why, free text status / to do. User situations (like user stories but less emphasis on the type of user/marketing)
---
"The entire C separation of preprocessor, compiler, assembler, and linker exists because each one of those could fit independently in RAM on a PDP-11 (and the separate link step originates because Mary Allen Wilkes didn’t have enough core memory on an IBM 704 to fit a Fortran program and all of the library routines that it might use). Being able to fit an entire program in memory in an intermediate representation over which you could do whole-program analysis was unimaginable." -- David Chisnall
---
" In defense of complicated programming languages ... What then, would happen if we were to ban classes from Python?
Oh, it would make the language so much simpler! ... users would find the number of variables would get out of control. Until one day, some programmer gets the neat idea that they could reduce the number of variables to keep inside their head if only they grouped variables in a dict:
def bark(dog_dict): print("WOOF!" if dog_dict["weight_kg"] > 25 else "Woof")
rex = {"name": "Rex", "weight_kg": 35}
And so they would have accidentally re-introduced classes, only this time the existence of classes would have been implicit in the code, and their behaviour ad hoc defined, their invariants spread all over the source files, and with no language-level tooling or introspection to help the programmer. Classes would still exist, but as implicit patterns.
These kinds of structures emerges spontaneously and constantly, all over code.
Programming languages used to not support functions, but then it was discovered that instructions tended to be grouped in blocks by their functionality, and that conceptualizing it as a function made the code easier to reason about. The introduction of functions did not make programming more complex, on the contrary, it became simpler in the way that matters.
Languages used to not have structs, but then programmers discovered the usefulness of grouping sets of data into an abstract, higher-order kind of data called a struct. And again, this feature did not make programs more complex, but made them simpler. ... Julia has a complicated type system. Types like AbstractSet?