How speedy is the rust-language tooling itself these days? I remember wishing for a 'optimize nothing' or even 'just interpret' mode. Compile times noticably contributing to the feedback loop are a serious killjoy.
Compile times are still a bit much, but there are ways around it:
- The insanely long times are only for the initial build. Further builds are incremental and more tolerable.
- Compilation errors can be checked using 'cargo check'. It avoids the code generation step that's part of a build. I find myself doing it way more often than builds. So it's a time saver depending on how frequently you use it.
- You can extend the incremental build mentioned above using sccache [1]. At the minimum, it allows you to share the build cache between all your local projects. So it saves time if your projects or other builds share a lot of common libraries (that's very common in Rust, though). But sccache can go further by using online build caches (for example, using S3) that can be shared between hosts. Finally, sccache also supports distributed builds if you have a few machines sitting idle. (This is like distcc with extra features).
There have been significant (if not earth shattering) improvements in the compiler itself. But for me at least, the bigger change has been from better hardware. I now have a processor (Apple M1 Pro) that's 10x (multi core) / 2x (single core) faster than the one I had when I first started programming using Rust (intel dual core processor in a 2015 MBP) and that seems to have translated almost perfectly into faster compile times.
Hm i haven't checked the svelte 5 runes yet but last time I checked i also felt that solids reactivity concept is just beyond what svelte offers. If i wasn't that much in love with solidjs i'd probably pick svelte though. But i already see it coming that i won't be able to let it go until i checked the new runes now...
2. The way to present your ideas does matter. You can cheer for the beauty and elegance of something without throwing dirt at another thing
3. Devs who claim themselves to be ts-demigods (also counts for other tech ofc) but are only hunting for the newest hackiest way of creating code that noone besides them understands, can kill ur project in the same way as the java8 dev who hasn't looked at different languages or tools in 10 years and is busy debugging nullpointers for 10h a day.
Bit biased, but I'd say this is an non-technical article about overthinking terminologies. As others already mentioned, we use techie /non-techie to quickly categorize people into coders and non-coders, but techie also works for the embedded-guy or the kick ass devop or Linux neckbeard.
"Tech" has also become an allegory of topics that we can discuss where there is a clearer right and wrong. It's still subjective and opinionated of course but at the moment when your mind is really soaked into tech, everything feels so simple and ultimatively true. It's probably part of the God-complex/imposter-syndrome that so many coders experience, but that's another topic...
I just merged a bigger pr last week where I used quillv1.
My feature was fairly straight forward - I added a DSL so that users could build custom filter expressions for our trace-data analysis (automotive). I wanted to be tight with my business logic so I added my own lexer, parser and grammar evaluation with neat compiler hints and such - was a joy.
But when it came to the frontend it was infuriating. All I wanted was to hightlight the idex of my "compiler-error" but it was just a mess (every once in a while the text-cursor would jump around, sth I simply couldnt fix entirely).
Ontop of that this [issue](https://github.com/quilljs/quill/issues/3806) exists - which forces us to upgrade once primeNg lets us. Anyone knows a good alternative? I am done with quill and would love to use something more stable.
Really sounds as if your made up story is deeply rooted in your own experience. I am sorry if something like a new guy taking your position and claiming to be smarter has happened to you but creating imaginary stories is not quite what this comment section needs and you'd probably be better off dealing with this in a different way
Not at all. Nothing personal. Although, it looks like you are the one self-projecting here.
It’s simply how times change and people with it. Knowledge is lost when people move on and the reasons why certain decisions were made are not transferred.
At any rate, I imagine people at Google are trying to figure out why there is such a negative opinion on their search results lately.
It's the red waving flag of this project. I cannot understand how people are still arguing for this kind of stuff or stick with this dinosaur language at all.
I am sorry but I have such an aversion against the attitude of "we use xy because of historic reasons but hey actually it is really good because the design pattern that has proven crucial over the last 50 years imo is just overhead and you can just put some files here and there copy a bit of that and... "
> I am sorry but I have such an aversion against the attitude of "we use xy because of historic reasons but hey actually it is really good because the design pattern that has proven crucial over the last 50 years imo is just overhead and you can just put some files here and there copy a bit of that and... "
My criticism is that php was designed to be a violation to mvc. The <?php> file header already a commitment to mixing front- and backend code (HTML + php in one file) inevitably leading to spaghetti code.
The $annotation an inheritance from perl imo also a major distraction.
also Laravel, other frameworks and newer php versions might try to tackle some of the historical tech debt embedded into the language but I personally don't see a point in revival of php altogether.
I guess my point is to some degree subjectal and shaped by some major crimes I have stumbled upon when debugging. Even though the code in this repo looks fine, the mere use of php is reason enough for me to stay away from it altogether
I mean, you can do MVC in PHP if you want. I used perl long before I used PHP so the $annotation never bothered me.
I personally like mixing frontend and backend. I get why it's anathema to some, but there are simply tons of use cases where I think the simplicity it offers - being able to capture an entire page of functionality in a single file - outweighs the disadvantages because of the simplicity it offers.
For larger scale applications it's easy to make terrible mistakes leading to spaghetti code - I feel your pain about major crimes and have witnessed a few (and been responsible for some) myself. But this is possible in many languages if you're not using a framework, and modern PHP gives you way more tools to avoid it, even before you look at frameworks, which almost completely obviate the problem.
I remember being shocked about it when i heard that on ts-congress by, Nathan Sanders a ts contributor, around 4-5 years ago.
I find the ts-enums incredibly poorly designed and advice my juniors to stay away from them generally.
It's almost similar for interface (https://shively-sanders.com/types-vs-interfaces.html)
reply