That's an interesting place to investigate. The Amish don't seem to depend
on technology they can't create and they tend to develop their own food source.
Yeah you have a point, hmmm, wish there were a way to somehow generate those garbages with minimum bandwidth. Something like, I can send you a very compressed 256 bytes of data which expands to something like 1 mega bytes.
there is -- but instead of garbage expanding data, add in several delays within the response so that the data takes extraordinarily long
Depending on the number of simultaneous requesting connections, you may be able to do this without a significant change to your infrastructure. There are ways to do it that don't exhaust your number of (IP, port) available too, if that is an issue.
Then the hard part is deciding which connections to slow, but you can start with a proportional delay based on the number of bytes per source IP block or do it based on certain user agents. Might turn into a small arms race but it's a start.
We have people who deliberately modify their cars, trucks, and motorcycles to make them even louder. If EVs really caught on to the point most people had them, I would not put it past them to mod theirs to play loud vroom-vroom noises over speakers to match the volume level of ICE cars.
Silicon Valley existed before billionaires and plenty of university/government funding flowed in. Silicon Valley doesn’t require billionaires but billionaires require Silicon Valley.
Yeah Silicon Valley got started through government-funded research into applied materials science. The inventor of the transistor worked at a university before he struck out on his own to build a company, and his research started at that university on a grant-funded project.
I would wager most of what you take for granted out of "Silicon Valley" started as fundamental or applied research funded by a government. The current generation of AI hype certainly did.
I started using it recently for a prototype of something I'll eventually rewrite in C++ at work. I really like it.
Discarding the preprocessor and replacing it with a proper module system is huge. I got burnt by templates and horrifying compile times in C++, but haven't had any problems with D templates. The module system makes templates feel much more natural to use. The syntax for templates is a huge improvement, and throwing `static if` into the mix results in concise and easy-to-read code.
I also quickly realized (with the help of some people on the D discord) that the garbage collector is fine for my needs. So I don't have to spend any time thinking about memory management... put stuff on the stack when I can for speed, othrewise just GC and don't think about it. I think there may be some issue with multithreading and the GC, but this is supposed to get fixed with the new GC that's on the way.
There are a few other nice QOL improvements. Getting rid of `->` is honestly worth its weight in gold. There's nothing difficult about forgetting to change a `.` to a `->` or vice versa in C++, but not having to trip over it periodically when you're compiling makes the language that much smoother. I was also initially confused by the `inout` keyword but have come to really like that, as well. Little niceties like `const(T[])` are small but, again, reducing just a little bit of friction like this across the language makes D much, much more pleasant to deal with than C++.
I think the main challenge the language is facing right now is that it's huge and a lot of it is still getting worked out. I never thought I'd pine for C++'s "rule of 3/5/0", but it's a lot tighter and more logically consistent than the equivalent in D. But part of that is there being a huge community of C++ developers who have taken the time to promulgate rules of thumb in the community. I'd kill for an "Effective D" book to short circuit some of this process... after all, I'm trying to write code, not play at the margins, tinkering with D's idiosyncracies.
I'm open to it but I don't know enough about the options, other than the Boehm GC. If people know of good GC-in-C++ options, I'd love to hear about them.
In my area (numerical methods and computational geometry), I do not need anything to run in real or soft real time. The GC pauses aren't a concern. In which case, there is no real performance concern other than what I mentioned about the pauses being effectively single-threaded (my understanding... maybe this isn't exactly right). But this is supposed to be improved at some point, so whatever. Not having to explicitly think about memory management is a pure win.
On the other hand, my understanding is that using a GC in C++ could confuse things like Valgrind and ASan. Converting the entire codebase to use a GC is infeasible; so, if it made things more difficult for others by making these tools harder to use, it would be a nonstarter. But maybe this is just an imagined difficulty.
Another option is to just implement some scoped allocators. Everything I'm working on at the moment is "pure": some complicated operation applied to some fixed data. So, use an allocator to simulate GC within the scope of what I'm doing.
If anyone has thoughts here I'm definitely interested to here. Not that I'm looking forward to a C++ rewrite. :`(
I've been playing with it hacking a compiler written in C++ to be sort of transliterated to D. Just to see if it then makes the compiler easier to read, while not worrying about the performance yet.
So far in converting the lexer it does make it more comprehensible, it will probably do the same for the parser and AST. The real interesting bit will be once I tackle the later stages.
reply