non-technical gripes with rust specifically
the language is pretty great from a technical standpoint. i see its benefits. i know. other languages have taken ideas from it. i use packages that emulate it. but i have not brought myself to use it, if i can help it. the borrow checker seems to be the least of my problems.
use of latest features
every new release of rust tries to maintain compatibility with most rust code that's been written (that is—every rust code in github).
but it's immediately nullified by everyone (including the rust-in-linux project) using nightly instead of stable, or use a very recent stable.
a fortnightly release schedule is also a nightmare for "stable" (read: glacial) projects wanting to ship rust, so the compiler shipped with those versions couldn't compile a lot of rust code because those code use the newer versions.
while i trust that backwards-compatibility is not an issue here, it's the issue of providers being expected to keep up with rust releases. which means you basically need someone to guard that post, along with the headache of trying to coordinate that with the provider's manager. supporters brush it off by saying, "get with the times, old man".
rust's release train mechanism is looking more like a hype train: the fact that "minimum supported rust version" (MSRV) is a common phrase, and that this website is a thing should tell you something about how frequently the language is updated.
some people like chasing trains like this, others don't.
obtuse method chaining
i'm fine with "method chaining". i use it quite often. under the condition that it remains clear-at a high level-what it's doing. what do rust libraries often do?
something.into().to_iter()
, foo.unwrap()
, std::iter::IntoIterator::into_iter(baz)
…
just get to the point already! no, i don't buy that "it's not boilerplate because it makes it clear what you are doing exactly to your object," i just want to decipher the damn thing!
"this is just what you signed up for when you do systems programming, everything is laid bare unlike C where you need to keep it all in your head" except rust is not just used for "systems programming", but then where's the line? it's just a social construct
is it? can i trust what i see with my eyes? no, of course not.
packaging
cargo's package culture seems to mirror that of npm. when people think of left-pad
they think of:
- the inadequacy of the standard library (javascript added a native
left-pad
after the incident, around 2016/17 to be exact) - many, many trivial packages often consisting of a single line, upon which many packages either depend upon, or is the root of a deep, deep dependency tree.
rust's stdlib is capable enough, so point 1 doesn't quite apply. point 2 however… it's not that trivial in rust to do things that are trivial in other languages, sometimes including even C.
i understand, rust requires you to really think about memory in a way that other languages don't (because memory management is quite important), so there's lots of utility packages that iterate on each other. really driving home the meaning of "not reinventing the wheel in an insecure way"
however. one big problem.
compile a rust project, look at the cargo dir.
how big is it?
the simple formula is this: take the large amount of small packages, and consider that each package is statically-compiled. what do you get? BOOM! megabytes of package cruft. at least node_modules
, even with the ungodly amount of files, don't actually weigh that much.
culture
aka my biggest non-technical problem with rust.
one or two arrogant bad apples in a community—that's understandable. how about an entire culture? don't get me wrong—it's "welcoming", it's "pleasant", and i am sure it's a lot of fun to be around. however, consider that:
- rust is positioned to be the cutting-edge in safe yet performant programming languages.
- borrow-checking answers the "speed vs safety" question with "why not both?"
- the same mechanism helps prevent data races, so 🔥fearless concurrency🔥 helping it be 🚀blazing fast🚀
- result/options instead of exceptions allow for handling errors as soon as possible
- the community is ✨welcoming✨, obviously
so all of those reasons easily position rust as the best choice for projects technically, objectively, even morally.
Key word: morally. what does that mean?
it means people who are obsessed with being morally correct are gonna flock to the language, and become its foot soldiers. normally it results in a latent culture where it gives them the "right" to be smug, obnoxious propaganda machines because, what technical recourse do you have?
after all, why be so wrong, when you can be so goddamn right?
yes, it doesn't appear all the time, but there is always a chance of this happening when the community interacts with others. what other language has both this kind of reach and can afford to be this smug?
this behavior underpins the attitude people have towards things that rust cannot support yet. "it's obsolete or not ready for prime time yet, you should trash it." "it cannot be secured, you should trash it."
are programming languages a fucking competition? use what works for the job, right? then why put your energy into demeaning others who improve themselves?
"you're just mad because it's true", yeah and also you are too fucking smug. i couldn't believe someone like that can get ahead in the world, but they often do. i just lack the charisma to make my smugness tolerable.
in fact, this entire culture is what made me rethink the way i talk about linux to non-users. because it had made me realize the linux community is exactly the same way, especially towards windows users. so at least i have rustaceans to thank for making me introspect.
i'm not sure where to put this, but i've heard someone responding to this white house statement along the lines of:
no one forgot about java, swift, ada, etc. as memory safe languages, it's just they suck
…which is exactly why the media forgot about them. again, most languages are memory-safe, but people think of only rust—it's like thinking of only C when talking about "real programs". incidentally steve klabnik wrote something about putting too much focus on "memory safety".
rust has a "brand" like it or not. not to be confused with how the rust foundation wants to control it, however.
it's what makes the hypeseeking crowd want to proudly advertise that it's "rust-based", "written in rust", etc. etc.
what are people saying about it? "it's so i know it's something i can work with" "it shows the capability of the language, especially if it's niche"
yeah, same. i can say my projects are "written in nim" because i want to show that:
1. nim can do this kinda thing
2. that programmers who know the language can contribute to or use parts of it in their own projects
but to the wider audience it means nothing. nim means nothing to them, at worst it's derogatory. as in, "lmao, written in discount python."
how about rust?
consider the 70% figure that's repeated to the point that it's a bit like a slur for Cniles. that's the implication that makes "written in rust" different than "written in python" or "written in nim". and some software advertises itself as written in rust in a way that imply that this alone automatically makes it safer than every other app.
it isn't a panacaea, but it's marketed as such. it's a cure to the illness that is programmers themselves.
it's heavier than even "written in go". what does that imply? that it's easy to contribute to? that it's built on proven technology? i'm not sure.
i am sure in due time, i will have to use it, and i will overcome its challenges. but this is something that has come up time and time again. and i kept getting fucking gaslit about this. i'm sick of it.
…but then again, sike, the "non-technical" gripes are actually technical gripes, so.
when you webdev
WHEN YOU TRADE USER EXPERIENCE
FOR DEVELOPER EXPERIENCE
the absolute state of web dev
This is from a real website of a modern "web developer".
I couldn't have painted a better picture of 21st century web dev even if I tried.
who cares?
haha, you must be insane for only listing html, css and js on your skills list.
that's the bare basics lmao. they'll look at people who have much more - react, vue, tailwind... the whole nine yards.no one will GIVE A SINGLE SHIT if your website works without scripting or if it doesn't eat your user's ram.
or if your website (really a web app) is "accessible", like, at all.they only care if you can make it in like 5 hours, and looks really good regardless of contrast issues.
they won't mind the 10 megabytes of javascript loading in the background.the world moves fast, bucko. it's time for you to adapt.
who needs stability?
who needs performance?
who needs bandwidth optimization?
the world is burning, may as well roast a marshmallow on it.
on building a single page app
when I make one of these, I want one that works well on html as much as it would on a single page. easier said than done.
the backend & HTML stuff is piss-easy. it's the SPA-izing that gets me.
the single script file I end up making has hundreds of lines for sure (even more if you count comments).
i'm trying to create and fade in components dynamically from a json response, y'know, like a regular SPA thing. the extra work here, then, is matching what the JS generates to what I laid out in the HTML.
i'm using bliss.js for this since it has some shortcuts for common JS stuff.
come on... do it... you WILL use react...
maybe i will, but i won't like it much. at least, not until i forget what react is doing to users.
in fact, to me, all of this is worth doing as I'm learning a bunch of stuff.
like Prototype
, even if i'm doing it to global js objects like String
and Date
. we do a little trolling
maybe a bit about Promise
and addEventListener
too, even if it's just the basic stuff really
hundreds of lines? yep, sounds like you're making your own shitty framework. it's not optimized and probably insecure
and?
my single script file so far is 30kb (9kb minified) + 12kb minified for bliss.js
what it's for does so much more than an extremely basic hello world in react (generated code: 130kb) lmao
you know the web sucks
-
html
- barely a standard
- constantly getting toyed around by browser vendors (hello, browser wars)
- everyone is picking elements for their visual appearance (see
<h1>
to<h6>
) - one engine is dominant, there are no good browsers.
-
js
- most of js code is machine-generated or compiled, that's why everything's so bloated now
- the ecosystem gets so big and unnecessarily complex that javascript fatigue is actually a thing. i don't see this shit in other programming (or scripting) languages.
- places with mostly static content that block you if you have js disabled: fuck you.
- "imagine disabling js": imagine prioritizing DX over UX, my comfort is your suffering.
- everywhere should be treated as a privacy AND security nightmare with js enabled. can never be too safe.
- if your site is ORDERS OF MAGNITUDE faster to navigate with js off, you've got serious issues.
- how about the recent zero days huh? that's another reason to have noscript.
-
css
- the syntax doesn't make sense for a cascading language, oh, but it is designed to be "quick".
!important;
!important;
!important;
!important;
!important;
are you coding son?- it's so hacky to get anything right in it
- noooooooooo you have to use
.message.-error
! haha utility classes gotx-red.p-4.mx-3.bg-blue.h-4.bs-black:4.zoom.tf-serif
support cutoff
the best way to start thinking about absolute browser "support cutoff" now is from your own server
does it use https? good
now check what kinds of cipher it's using for connections and check the earliest version of a browser that supports it
like i said, it's kinda pointless to design specifically for a 90s browser but then you can't open it as-is on it
how scalable are you?
does it matter? i.e. you are a big shot of a company needing to accomodate hundreds of customers concurrently
does throwing more code than needed on your service make it more scalable?
can you explain what is being added and how does it impact your customers?
(even function calls take time!)
feature detection > user agent sniffing
user agent sniffing is how we got "Mozilla/5.0" on every visual browser UA
not sure if you need extra boilerplate to do that (cough Modernizr cough), feature detection should be as simple as if ("customElements" in window)
anti-user
cOnSidErEd hArMfUl:
- scripts obfuscated thru webpack and babel
- bloating the webpage with subversive patterns like utility-only css
- making the client do all the work (looking at you, react)
- fixed-unit sizing everywhere
- very low contrast designs where all the content is located
- failing to balance developer convenience with client soundness
- completely unusable site without javascript
the most minimal opengraph setup
just the sitename, image, basic html description. ez:
<title>Delectable Dinkums</title>
<meta property="og:site_name" content="My Site">
<meta property="og:image" content="https://http.cat/200">
<meta name="description" content="This is where I get to dump all my shitposts :^)">
<meta name="author" content="anon">
(note, og:image
must be an absolute path)
here's how it'll show up in discord etc. :
.---------------------------------------.
| My Site |
| |
| Delectable Dinkums [Image] |
| |
| This is where I get to |
| dump all my shitposts |
| :^) |
._______________________________________.
css class methodologies
bem (broke)
<section class="card">
<div class="card__image">
<img src="example.jpg" alt="Example image">
</div>
<div class="card__description card__description--flashy">
<p>Hey lookit me!!! I'm fancy</p>
</div>
</section>
.card {}
.card__image {}
.card__description {}
.card__description--flashy {}
smacss (just got out of bed)
<section class="card">
<div class="card-image">
<img src="example.jpg" alt="Example image">
</div>
<div class="card-description is-flashy">
<p>Hey lookit me!!! I'm fancy</p>
</div>
</section>
.card {}
.card-image {}
.card-description {}
.card-description.is-flashy {}
idunno what this is called, it's not like it's better or anything (woke)
<section class="card">
<div class="_image">
<img src="example.jpg" alt="Example image">
</div>
<div class="_description -flashy">
<p>Hey lookit me!!! I'm fancy</p>
</div>
</section>
.card {}
.card ._image {}
.card ._description {}
.card ._description.-flashy {}
directly tying it to markup order (awokened)
<section>
<div>
<img src="example.jpg" alt="Example image">
</div>
<div>
<p>Hey lookit me!!! I'm fancy</p>
</div>
</section>
section {}
section div:nth-of-type(1) {}
section div:nth-of-type(2) {}
utility-only (BESPOKE)
<section class="flex-horiz:lg flex-vert:md">
<div class="h-3">
<img src="example.jpg" alt="Example image" class="w-100p h-100p">
</div>
<div class="px-4 py-4 grey-100 flex-grow">
<p>Hey lookit me!!! I'm fancy</p>
</div>
</section>
xhtml seems like a good idea?
draconian error handling, actual validation, remains untouched by people who wanna put fucking DRM on it, what more can you ask for?
but please, stop using text/html
as the content type
the only problem now is fouc (see below)
it's completely inevitable with the xml renderer, no anti-fouc fuckery will save you now. but i accept that lmao
also if you use text/html
, shortform empty tags like <div/>
won't work anymore
always remember
every html element is a <div>
or a <span>
if you wish for it hard enough
so there's no excuse for picking elements solely based on how they look
framework 👏 review 👏
I looked at a review of vanilla vs js frameworks
points taken:
- hooking to random elements can be hard, have to use
getElements?by*
orquerySelector(All)?
- can't immediately tell which elements have bound events
- could probably use something like
data-bound
or somethin
- could probably use something like
- you'll just make your own shitty library/framework anyway
- don't reinvent the wheel, even to learn!!!!
</strawman>
- don't reinvent the wheel, even to learn!!!!
looking at independent demos made from those frameworks and you might've guessed that they require JS just to display the page
svelte I feel fares a bit better because you can make it so that it renders HTML from the get go. the realworld demo is a project that aims to put all of these frameworks and libraries to the test, and even the vanilla app!!! requires javascript.
svelte team's on the other hand, has enough conscience to load the basic elements without javascript. sawir's implementation is even better, because you have everything rendered out already using php and I bet alpine is a sweetener.
but then most of these frameworks have syntax that just looks uncanny:
- react has jsx
- you have colons as attribute names in vue
why single page apps?
oh its only like .3% who disable javascript and they're autists anyway
that number will rise alright, as more people have slowdowns thanks to the absolute metric ton of js being used on every website worth a damn
you know, this idealism probably won't work and that I should go with what the industry is doing anyway
I hear another point of SPA is shifting rendering logic from the server to the client
the problem is that clients will have absolute shit machines
getting rid of timezone disparities
pretty good idea but even that can be adjusted for separately
not having to store sessions since variables are global
looks like your app is pretty stateful
if you really need to use a framework
might i recommend svelte (compile-time builds, major performance perks!)
or even better, alpine.js (4kb goodness) it's 36kb.
not bad, but i dunno where i got that ridiculously low number from.
elementals.js is also pretty good (25kb)
fouc doesn't actually matter anymore
...because the either the page loads without the styling or the entire render is blocked until the style is loaded
anti-fouc measures can be decidedly anti-user by making the site completely unusable without javascript, as an anti-fouc approach includes covering the page with a loading screen and applying classes which makes elements hide.
if javascript is disabled, the anti-fouc hooks won't run, so nothing will be visible to the user
a surefire way to prevent fouc is ensuring the user is operating on text/html
at any time
custom elements
turns out a few browsers don't actually support custom elements and the page will shit itself if any functionality depended on it.
last I checked that's pale moon and seamonkey
proprietary js
sometimes I wonder if webpack is an exercise in proprietary js. just look at what it outputs, it's completely opaque shit, but at least you won't use as many bytes
utility-first
they told me that it's utility-first CSS, not utility-only, and that @apply
is the solution.
problem is, does anybody even use @apply
????
i think more people should do this (tailwind as an example):
.button {
@apply
px-4
py-2
bg-blue-600
text-white
rounded
}
granted the output won't be very optimal, but it is a good step