People also said similar things in the past (I'm a musician as well: guitar, piano and bass) about Synths and Drum machines (and things like GarageBand which can do backing drums and even basslines semi-automatically now).
Some of those things enabled others to create new types of music or express themselves in different ways.
Not if you want better fidelity: the VFX industry for film moved from rasterisation to raytracing / pathtracing (on CPU initially, and a lot of final frame rendering is still done on CPU due to memory requirements even today, although lookdev is often done on GPU if the shaders / light transport algorithms can be matched between GPU/CPU codepaths) due to the higher fidelity possible starting back in around 2012/2013.
It required discarding a lot of "tricks" that had been learnt with rasterisation to speed things up over the years, and made things slower in some cases, but meant everything could use raytracing to compute visibility / occlusion, rather than having shadow maps, irradiance caches, pointcloud SSS caches, which simplified workflows greatly and allowed high-fidelity light transport simulations of things like volume scattering in difficult mediums like water/glass and hair (i.e. TRRT lobes), where rasterisation is very difficult to get the medium transitions and LT correct.
> or intentionally don't write const because writing it everywhere clutters up the code
I don't often like being judgemental (at least publicly!), but I'd argue that's just people being very bad developers...
You could argue having to add '&mut' at call sites everywhere (i.e. opposite to the way C++ does const in terms of call site vs target site) also clutters up the code in terms of how verbose it is, but it's still largely a good thing.
It used to in older (pre 2.0) versions, but due to Python's GIL lock (and the fact Python's quite a bit slower than lua anyway), it was pretty slow an inefficient using Python with AttributeScripts, so 2.0 moved to Lua with OpScripts...
Katana uses LuaJIT quite extensively for user-side OpScripts, and previously both DNeg and MPC (they've largely moved on to newer tech now) had quite a lot of Lua code...
As someone who's used Lua a lot as an embedded language in the VFX industry (The Games industry wasn't the only one that used it for that!), and had to deal with wrapping C++ and Python APIs with Lua (and vice-versa at times!), this is indeed very annoying, especially when tracing through callstacks to work out what's going on.
Eventually you end up in a place where it's beneficial to have converter functions that show up in the call stack frames so that you can keep track of whether the index is in the right "coordinate index system" (for lack of a better term) for the right language.
A 256-item float32 LUT for 8-bit sRGB -> linear conversion is definitely still faster than doing the division live (I re-benchmarked it on Zen4 and Apple M3 last month), however floating point division with the newer microarchs is not as slow as it was on processors 10 years ago or so, so I can imagine using a much larger LUT cache is not worth it.
I've tried a lot in the past as well, and after getting annoyed with proprietary OS X software (iBank in particular) back in 2009 or so, and not really liking GNUCash and KDEMoney (at least back in 2009) ended up writing my own open source simple app (native Cocoa, with a more recent Qt port for Linux) that I've been using every since on a daily basis.
In terms of the detail, I used to do very detailed breakdowns of categories, but now I don't really see the point: my app supports 'split transactions' (one of the reasons I actually made it, as existing solutions had poor support for them back in 2009), and I generally just use things like 'Food', 'Drinks', 'Essentials' as categories, as it never really made sense (at least for me) to detail them with such accuracy.
But for things like 'coffee', I do 'Drinks:Coffee', so I can see how much I am spending on fairly specific things, but I guess it's a balance in terms of whether it's worth the effort to record them so accurately compared to making use of the details.
Similarly, things like 'Car:Fuel', 'Car:Service', etc...
That's been within the last year I think - I too have been using Linux and Firefox for calls in Teams meetings from 2020 to last year when I had to move to the Teams Linux client (which they're deprecating, so having to move to Chrome or Edge).
I think the throughput is currently quite limited because of low levels of water in the natural lakes close to Panama which are used for both Panama's drinking water and for the locks in the canal, so they're restricting the number of ships per day...
I mean, it does read badly, and maybe the worst should be assumed, but at the same time:
> You hereby grant to Vultr a non-exclusive, worldwide and royalty-free license to copy, make derivative works, display, perform, use, broadcast and transmit on and via the Internet Your Content, solely for the benefit of You and to enable Vultr to perform its obligations under these Terms.
Given Vultr has a distributed CDN service, could not the "copy", "display", "broadcast" and "transmit" parts be charitably interpreted as part of that agreement? i.e. them serving your content via the CDN?
Edit: it looks like they've updated it already from what the blog post quotes it as?
Yeah, as someone who's been attempting to use VSCode to do Python and Rust dev over the past three years, I'm continually surprised by people who say VSCode and the Rust analyzer plugin is a Good/Great IDE env.
It so often seems non-functional to me: auto-completion just doesn't work consistently, even on really simple things - you firstly normally have to save your file first, and even then often if I restart VSCode it will then work again on something it didn't a minute ago, and other times I can never get it to complete things. And this is happening on two different Linux machines and a MBPro M2 in multiple projects, so I don't think it's just a one-off bad configuration I've somehow got.
Its auto-indenting when writing code is insane as well, it seems everyone must be running rustfmt all the time, even on code as they're writing it? It never seems to get the indents right on new lines for me, I'm either having to add them or remove them.
At the end of the day it's what you get used to I think, but Visual Studio 15-20 years ago was pretty good (other than the bloody pause for "Updating intellisense"), I've yet to find anything as good for Python as PyCharm, and QtCreator (CLion was pretty good as well) is still the best Linux/MacOS-based C/C++ dev env I've found (but recent versions of it are getting worse IMO what with all the complicated "Kit" build config stuff).
Some of those things enabled others to create new types of music or express themselves in different ways.