I went to college starting 2007 (right when CUDA was released) and recall a few things about python that made it attractive in both the comp sci and math departments at my school.
- python integrated well with lesson plans instructors had
- python integrated well with the software math departments were using (like MATLAB)
- python had a very easy to use interpreter environment that worked well on linux, mac, and windows
- python had (for the era) a massive standard library, making it way easier to consume and process
common data file formats like XML or CSV without having to install any extensions
(installing extensions usually required admin permissions and... very few at school had those for very good reasons)
- exposing c/fortran libraries into python was pretty straightforward to do and was relatively stable compared to alternatives.
Around 2007, the main competitors in the scripting space had a lot of issues:
- tcl - somewhat popular for embedding but didn't really have a standalone interpreter that made it easy to interact
with and the syntax didn't really look like C, and really not much of a library to work with
- lua - similar to tcl, popular for embedding but didn't have a popular standalone runtime and interpreter.
syntax was closer to C though. didn't have much of a library to work with
- ruby - had a runtime for experimenting but a less stable API for integrating, plus the language was pretty
different from C. the library was large but had a larger reliance on installing extensions than python at the time.
- perl - both unstable and had a horrible reputation by this point as a standalone language that outside of some obtuse
systems scripting, most people didn't want to touch this with a 12-foot pole. standard library was small and relied a lot on extensions.
- php - similarly unstable (at the time... i think 5.3 had just come out) and had a horrible reputation... also not even
sure it had a runtime that worked outside of an apache/nginx context... exposing a c library to PHP at this time was pretty
straightforward though. relied very heavily on extensions at this point.
- javascript - node.js hadn't come out at this point... so the idea of running javascript outside of a browser window wasn't really a thing yet.
If one were looking to expose CUDA to programmers who didn't want to work in C during this era, I'd argue that python was just the best option at the time.
I believe that led to a first-mover advantage that has held over time.
Would cast iron pots and pans count as thick-bottomed in this case?
I usually use these with electric stoves since they retain heat pretty well. They take a while to warm up though, so there's both time and energy lost in that warming process.
Yeah... Bird configurations are a little rough to learn. The examples they have on the website are pretty lacking. Their mailing list is usually helpful though.
Quagga is usually easier to find examples for since it's modeled after Cisco switch syntax for configuration (same basic syntax of arista switches).
Both of these really suck to learn as a programmer since you're usually coming into these without much of a network engineering background. I remember struggling a lot with both of these config syntaxes until a network engineer took me under his wing and taught me basics, principles, the engineering challenges of packet switching at scale, etc.
It should be noted that an EXPIREAT triggers a deletion if the timestamp being set is in the past and could lead to an increase in memory and disk pressure during script execution. Worth checking if the behavior there differs in any meaningful way since y'all made the change. EXPIRE usually just marks a key and relies on either subsequent operations to the same key or garbage collection to actually excise the entry and do the subsequent bookkeeping, I believe.
It's been a while since I had to deal with this kind of problem though, so please tell me if things are different now.
I'm kind of shocked no one brought up protobufs yet. protobuf libraries are available in pretty much all mainstream languages and the textproto format is pretty mature.
It's albeit clunkier and less freeform than YAML. And if you ever only plan on using rust the proposed solution here is probably cleaner.
Having portability over multiple languages maintained by large organizations can be useful in some cases though.
Interestingly, I've found that studying other engineering disciplines outside of software engineering to be best. The best explanations and modeling frameworks for concurrency I learned were from network engineering books and a couple hardware design classes I took.
Re: principles around performance analysis and diagnostics, Brendan Gregg is a name you should look up. His book on systems performance is a tremendous resource in both principles and methodology. Even though it's not focused on coding specifically, the same principles apply.
I think ineffectual is wrong here, re: Trump. By State Department metrics alone, we pay more now for less people and less passports processed than before Trump took office. Anecdotally, we tend to have less State department representation at trade and industry conferences around the world. It's not very clear to my why we're spending more on the State department under Trump than any year under Obama if we're doing less with it...
Around 2007, the main competitors in the scripting space had a lot of issues:
If one were looking to expose CUDA to programmers who didn't want to work in C during this era, I'd argue that python was just the best option at the time.
I believe that led to a first-mover advantage that has held over time.