Are you referring to the taxpayer support of state (not private) colleges, which subsidizes the tuition of in-state students? Foreign student don't get that subsidized rate.
Or do you mean the taxpayer-supported research - that anyone with an internet connection can download the results of, from anywhere in the world, without paying a penny of tuition?
If we were to compare it to a transaction, I think something like California exporting alfalfa to Saudi Arabia might make more sense. We've only but so much water to use and it's far from absurd to question if it makes sense to let our limited resources get drained for exporting things elsewhere.
I spent some time attempting to "derive" a theme given a primary and secondary color, but realized my color theory wasn't strong enough to build something reliable (I tried with both hsl and oklch). Curious if that's really possible.
Would it be possible to embed Bitrig in an existing app? Similar to how you might embed React Native into a portion of your app to accelerate development in a specific area, it’d be awesome to preserve the mature areas of our apps and use Bitrig to quickly iterate on new features.
Yes, we think that could be a really cool way to allow mocking up changes to parts of an app, especially for non-technical members of the team. We're not set up for that yet, but it's on our roadmap.
One of the core things Node.js got right was streams. (Anyone remember substack’s presentation “Thinking in streams”?) It’s good to see them continue to push that forward.
I think there are several reasons. First, the abstraction of a stream of data is useful when a program does more than process a single realtime loop. For example, adding a timeout to a stream of data, switching from one stream processor to another, splitting a stream into two streams or joining two streams into one, and generally all of the patterns that one finds in the Observable pattern, in unix pipes, and more generally event based systems, are modelled better in push and pull based streams than they are in a real time tight loop. Second, for the same reason that looping through an array using map or forEach methods is often favored over a for loop and for loops are often favored over while loops and while loops are favored over goto statements. Which is that it reduces the amount of human managed control flow bookkeeping, which is precisely where humans tend to introduce logic errors. And lastly, because it almost always takes less human effort to write and maintain stream processing code than it does to write and maintain a real time loop against a buffer.
Streams have backpressure, making it possible for downstream to tell upstream to throttle their streaming. This avoids many issues related to queuing theory.
That also happens automatically, it is abstracted away from the users of streams.
A stream is not necessarily always better than an array, of course it depends on the situation. They are different things. But if you find yourself with a flow of data that you don't want to buffer entirely in memory before you process it and send it elsewhere, a stream-like abstraction can be very helpful.
Why is an array better than pointer arithmetic and manually managing memory? Because it's a higher level abstraction that frees you from the low level plumbing and gives you new ways to think and code.
Streams can be piped, split, joined etc. You can do all these things with arrays but you'll be doing a lot of bookkeeping yourself. Also streams have backpressure signalling
Backpressure signaling can be handled with your own "event loop" and array syntax.
Manually managing memory is in fact almost always better than what we are given in node and java and so on. We succeed as a society in spite of this, not because of this.
There is some diminishing point of returns, say like, the difference between virtual and physical memory addressing, but even then it is extremely valuable to know what is happening, so that when your magical astronaut code doesn't work on an SGI, now we know why.
