The Problem with Using a UUID Primary Key in MySQL.
https://planetscale.com/blog/the-problem-with-using-a-uuid-primary-key-in-mysql
https://planetscale.com/blog/the-problem-with-using-a-uuid-primary-key-in-mysql
Planetscale
The Problem with Using a UUID Primary Key in MySQL β PlanetScale
Understand the different versions of UUIDs and why using them as a primary key in MySQL can hurt database performance.
π1
Writing an LLVM backend for the Move language in Rust
https://brson.github.io/2023/03/12/move-on-llvm
https://brson.github.io/2023/03/12/move-on-llvm
π1π₯1
π₯2
You should make a new programming language
https://ntietz.com/blog/you-should-make-a-new-terrible-programming-language/
https://ntietz.com/blog/you-should-make-a-new-terrible-programming-language/
π€5
Why I am not yet ready to switch to Zig from Rust.
https://turso.tech/blog/why-i-am-not-yet-ready-to-switch-to-zig-from-rust
https://turso.tech/blog/why-i-am-not-yet-ready-to-switch-to-zig-from-rust
turso.tech
Why I am not yet ready to switch to Zig from Rust
Building a better-sqlite3 compatible JavaScript package with Rust
Bridging Ousterhout's Dichotomy
Andy Grover
the origin of system programming and scripting programming term
https://www.slideshare.net/slideshow/bridging-ousterhouts-dichotomy/1610818#1
Andy Grover
the origin of system programming and scripting programming term
https://www.slideshare.net/slideshow/bridging-ousterhouts-dichotomy/1610818#1
SlideShare
Bridging Ousterhout's Dichotomy
Bridging Ousterhout's Dichotomy - Download as a PDF or view online for free
Compsci Library π
Bridging Ousterhout's Dichotomy Andy Grover the origin of system programming and scripting programming term https://www.slideshare.net/slideshow/bridging-ousterhouts-dichotomy/1610818#1
Scripting: Higher-Level Programming for the 21st Century
John K. Ousterhout
https://web.stanford.edu/~ouster/cgi-bin/papers/scripting.pdf
John K. Ousterhout
https://web.stanford.edu/~ouster/cgi-bin/papers/scripting.pdf
Compsci Library π
Ousterhout, John K - A Philosophy of Software Design: page 13.
Ousterhout,_John_K_A_Philosophy_of_Software_Design_2018_2019,_Yaknyam.pdf
1.6 MB
A Philosophy of Software Design
Ousterhout, John K.
Ousterhout, John K.
π«‘2π1π₯1
Compsci Library π
Ousterhout,_John_K_A_Philosophy_of_Software_Design_2018_2019,_Yaknyam.pdf
Software is Malleable
Different with physical design, software is easy to change. It smoothly adapt to change program structure rather structure in building or hardware while construction. For example, it easy to change your navbar website from top to left side in construction even production! (do with your own risk) rather changing Steel material into Titanium in Eiffel tower.
So, how to design and develop software need to address this nature? Incremental design, first start from small design then compounding by redesign and redevelop to adapt with change until grow big, similar with Snowflake method in writing fiction.
Before dive to incremental design, let see the predecessor: Waterfall design. Waterfall design is way to design software and engineering stuff, start from requirement analysis phase, planning, design, develop and release.
Pretty simple and make sense, yes. There a catch, each phase can not backtrack to previous step and change any definition from that phase. Like, there something planning requirement not possible in design phase.
It possible to change it by yourself, but that not how management works. In waterfall each phase done mean that no go back, fire and forget sort like that. The name waterfall imply this, the no water jump back to it belong after fall to ground.
If you do change that will affect budget, deadline and resources which is pain in ass, in other word start fresh cycle.
Ok, maybe you thinking about if there change or not comply each phase, why not put it to next development cycle to address ?
This what Incremental development for, it continously design and develop. These approach address malleablility in software. Such Agile, Rapid Application Development, XP, you name it.
Quite different with waterfall that once design and develop then done, so in certain case it done - clearly define planned design which is rare, human want A but stated B or C or else.
Different with physical design, software is easy to change. It smoothly adapt to change program structure rather structure in building or hardware while construction. For example, it easy to change your navbar website from top to left side in construction even production! (do with your own risk) rather changing Steel material into Titanium in Eiffel tower.
So, how to design and develop software need to address this nature? Incremental design, first start from small design then compounding by redesign and redevelop to adapt with change until grow big, similar with Snowflake method in writing fiction.
Before dive to incremental design, let see the predecessor: Waterfall design. Waterfall design is way to design software and engineering stuff, start from requirement analysis phase, planning, design, develop and release.
Pretty simple and make sense, yes. There a catch, each phase can not backtrack to previous step and change any definition from that phase. Like, there something planning requirement not possible in design phase.
It possible to change it by yourself, but that not how management works. In waterfall each phase done mean that no go back, fire and forget sort like that. The name waterfall imply this, the no water jump back to it belong after fall to ground.
If you do change that will affect budget, deadline and resources which is pain in ass, in other word start fresh cycle.
Ok, maybe you thinking about if there change or not comply each phase, why not put it to next development cycle to address ?
This what Incremental development for, it continously design and develop. These approach address malleablility in software. Such Agile, Rapid Application Development, XP, you name it.
Quite different with waterfall that once design and develop then done, so in certain case it done - clearly define planned design which is rare, human want A but stated B or C or else.
How I write HTTP services in Go after 13 years.
https://grafana.com/blog/2024/02/09/how-i-write-http-services-in-go-after-13-years/
https://grafana.com/blog/2024/02/09/how-i-write-http-services-in-go-after-13-years/
Grafana Labs
How I write HTTP services in Go after 13 years | Grafana Labs
Mat Ryer, principal engineer at Grafana Labs and host of the Go Time podcast, shares what he's learned from more than a dozen years of writing HTTP services in Go.
β€βπ₯1π1
π€1