WTF Bites
-
On another topic...
You think server-side JS is stupid? I just saw a blog post about server-side WebAssembly.
-
And my C-like brain really misses the semicolons.
There are semicolons in F#. You just don't need to use them. Or sometimes you can't use them because your 40-line function is just one long statement stitched together with
|>. Which is actually a very nice way to write code if you ask me.What about the miners in the expanse?
-
@Tsaukpaetra what?
-
@Tsaukpaetra what?
I think it's like a forum meme, sorry I'm not good at that.
-
@Tsaukpaetra oh, I see. I just got here.
-
@Tsaukpaetra oh, I see. I just got here.
And I probably butchered the meme. Everyone wins!
-
It sure makes sense for some acronyms. "I LOL'd" is common; "at work everybody is BYODding" would be fine. "Let me just LCD this widget" would be weird though, just like "try to IIRC this" or "I hope I've been able to Q.E.D. it". All the right verbs but accompanied by nonsense.
Those are all intelligible in that they (probably, with context) communicate the intended meaning, even if they don't make perfect sense grammatically.
That happens to be why it's my pet grammar, not intelligibility, peeve.
-
@Gern_Blaanston said in WTF Bites:
@Gern_Blaanston said in WTF Bites:
As for using RSVP as a verb, I see nothing wrong with that. Responding to something is an action, you are doing something, and that's what verbs are for.
I respondpleased is like saying I fuckyouverymuched up. It does contain the verb that expresses what you're trying to say, but the rest of it changes the meaning to something different.
Words, and their use, change over time.
Today it is common for people to shoot video with their phone and refer to it as "filming". It's technically wrong (there is no film involved) but it is now almost universally accepted.
It never had the primary meaning of "to use a film on a spool" but was always used as "to record moving images onto a medium". "I filmed it" always meant "I have a record of it in moving photographic images", not "I produced a big-ass spool of celluloid that's now sitting in my suitcase being a fire hazard", although it did imply that for a long time; that's why it was just natural to apply it to TV cameras some 70 years ago already.
It's is less technically wrong than "electricity", which today is approximately never produced using the piece of amber it's named after. Or to "shoot" movies for that matter."I RSVP'ed" is technically wrong but is understood to mean "I replied".
Shit happens, and sometimes you just have to stop being the old guy yelling at clouds.
Writing HTML is understood as "programming", too. I understand it perfectly well when somebody says "I program in HTML", I just read the subtext as "and I know very little about it". Same with "RSVPed" and the subtext of "I'm an ass who fails at being pretentious because I think I looked smart using this not-even-a-word instead of the simple 'to respond' that would be correct".
hardly ever gets better with age. Or rather, it's incurable but it does get better.
-
@Gern_Blaanston said in WTF Bites:
@Gern_Blaanston said in WTF Bites:
As for using RSVP as a verb, I see nothing wrong with that. Responding to something is an action, you are doing something, and that's what verbs are for.
I respondpleased is like saying I fuckyouverymuched up. It does contain the verb that expresses what you're trying to say, but the rest of it changes the meaning to something different.
Shit happens, and sometimes you just have to stop being the old guy yelling at clouds.
Make me!
-
@sebastian-galczynski the basic problem is that there are too many developers. About half or so need to be fired and go flip burgers instead, and i believe that productivity would go up by doing that.
-
@Carnage I saw a post somewhere in which a crane operator said they recently completed a construction where the construction management was nowhere to be seen the entire time. The only time in his whole career where they met the deadline, and with a healthy margin.
-
Tuples have approximately nothing to do with lists.
Unless you're in Python, where they're best treated as immutable lists. But then you don't need to be type-consistent in Python in the first place, types being something of an illusion. (Properly, it is values that have real types, not variables or functions, and those real types don't have extended attributes about the types of their contents.)
-
On another topic...
You think server-side JS is stupid? I just saw a blog post about server-side WebAssembly.
Server-side webassembly is not stupid though. Webassembly isn't really tied to web in any way except the name. It is just a virtual machine, like JVM or CLR, but designed with sandboxing in mind (it has no built-in ways to access the outside world, the host determines that). There are many cases where you want to run sandboxed tasks server-side and webassembly is a good fit for those.
-
Properly, it is values that have real types, not variables or functions, and those real types don't have extended attributes about the types of their contents.
Unless you are running under mypy.
-
On another topic...
You think server-side JS is stupid? I just saw a blog post about server-side WebAssembly.
Server-side webassembly is not stupid though. Webassembly isn't really tied to web in any way except the name. It is just a virtual machine, like JVM or CLR, but designed with sandboxing in mind (it has no built-in ways to access the outside world, the host determines that). There are many cases where you want to run sandboxed tasks server-side and webassembly is a good fit for those.
- JVM and CLR are usually primary targets - often the only targets - of the languages targeting them. WAsm is always secondary at best. Which means there always exists another choice than WAsm and it's always better, faster, and more supported - the opposite of most JVM/CLR languages.
- You sandbox code you don't trust. Do you not trust your own code?
- Is WAsm still unable to free the once allocated memory or do I have to look for a new stupid annoying limitation no other tech stack has that I can point to every time WAsm is mentioned?
-
On another topic...
You think server-side JS is stupid? I just saw a blog post about server-side WebAssembly.
Server-side webassembly is not stupid though. Webassembly isn't really tied to web in any way except the name. It is just a virtual machine, like JVM or CLR, but designed with sandboxing in mind (it has no built-in ways to access the outside world, the host determines that). There are many cases where you want to run sandboxed tasks server-side and webassembly is a good fit for those.
- JVM and CLR are usually primary targets - often the only targets - of the languages targeting them. WAsm is always secondary at best. Which means there always exists another choice than WAsm and it's always better, faster, and more supported - the opposite of most JVM/CLR languages.
- You sandbox code you don't trust. Do you not trust your own code?
- Is WAsm still unable to free the once allocated memory or do I have to look for a new stupid annoying limitation no other tech stack has that I can point to every time WAsm is mentioned?
There are places where you are better off not trusting your programmers, and limiting the reach of their code. Those places tend to be things like MUST.
-
@Carnage well, there's also the problem of https://xkcd.com/1200/ . Sandboxing makes sure the app won't be able to use OS-wide security exploits, mess with other processes, or perform certain memory operations/syscalls depending on how the sandbox is written. But it won't protect you against exploits for the sandboxed program itself, or crashes, or DOS, or accidentally corrupting the entire multi-tenant database due to a logic bug. How likely is it that your problem will be in the first group? And even if it is, with modern cloud architecture there's very little running in the program's VM anyway so the damage will be very limited. Unless the exploit can escape the entire VM but that's incredibly hard to achieve with malicious input alone and doing it accidentally is pretty much impossible. Considering all that, is it still worth it to employ sandboxing?
-
@Carnage well, there's also the problem of https://xkcd.com/1200/ . Sandboxing makes sure the app won't be able to use OS-wide security exploits, mess with other processes, or perform certain memory operations/syscalls depending on how the sandbox is written. But it won't protect you against exploits for the sandboxed program itself, or crashes, or DOS, or accidentally corrupting the entire multi-tenant database due to a logic bug. How likely is it that your problem will be in the first group? And even if it is, with modern cloud architecture there's very little running in the program's VM anyway so the damage will be very limited. Unless the exploit can escape the entire VM but that's incredibly hard to achieve with malicious input alone and doing it accidentally is pretty much impossible. Considering all that, is it still worth it to employ sandboxing?
Yes.
-
On another topic...
You think server-side JS is stupid? I just saw a blog post about server-side WebAssembly.
Server-side webassembly is not stupid though. Webassembly isn't really tied to web in any way except the name. It is just a virtual machine, like JVM or CLR, but designed with sandboxing in mind (it has no built-in ways to access the outside world, the host determines that). There are many cases where you want to run sandboxed tasks server-side and webassembly is a good fit for those.
- JVM and CLR are usually primary targets - often the only targets - of the languages targeting them. WAsm is always secondary at best. Which means there always exists another choice than WAsm and it's always better, faster, and more supported - the opposite of most JVM/CLR languages.
A few years back I'd have said, forget JS, it's so slow, why are you trying to compete with real VMs anyway? Then they started optimizing the shit out of it. I wouldn't count on WebAsm not gaining enough traction for a similar thing to happen.
As for "more supported", remember you're dealing with MS and Oracle here.- You sandbox code you don't trust. Do you not trust your own code?
Every exploited server is someone who trusted their own code.
-
On another topic...
You think server-side JS is stupid? I just saw a blog post about server-side WebAssembly.
Server-side webassembly is not stupid though. Webassembly isn't really tied to web in any way except the name. It is just a virtual machine, like JVM or CLR, but designed with sandboxing in mind (it has no built-in ways to access the outside world, the host determines that). There are many cases where you want to run sandboxed tasks server-side and webassembly is a good fit for those.
- JVM and CLR are usually primary targets - often the only targets - of the languages targeting them. WAsm is always secondary at best. Which means there always exists another choice than WAsm and it's always better, faster, and more supported - the opposite of most JVM/CLR languages.
A few years back I'd have said, forget JS, it's so slow, why are you trying to compete with real VMs anyway? Then they started optimizing the shit out of it. I wouldn't count on WebAsm not gaining enough traction for a similar thing to happen.
JS gained traction because Apple banned Flash. That was the sole reason why Angular, React, Node, NPM, leftpad and so on exist today. No similar event occurred in WAsm's 10 years of existence so far, and doesn't look like it's going to happen in the next 10 either.
As for "more supported", remember you're dealing with MS and Oracle here.
No, I mean, within the ecosystem. Take Clojure for example. Totally third-party to JVM, but uses JVM as its primary target. There are other implementations of Clojure, but they have like 1% of the already small Clojure's total market share.
- You sandbox code you don't trust. Do you not trust your own code?
Every exploited server is someone who trusted their own code.
Okay, so you don't trust your own code. Why did you give it access to your entire database and all your API keys?
-
Do you not trust your own code?
I know my own code well. Damn right I don't trust it!
-
Okay, so you don't trust your own code. Why did you give it access to your entire database and all your API keys?
Because it needs to be authorised to do some things in order to carry out its primary task. Without the API keys or DB access, why would you be running it at all?
-
On another topic...
You think server-side JS is stupid? I just saw a blog post about server-side WebAssembly.
Server-side webassembly is not stupid though. Webassembly isn't really tied to web in any way except the name. It is just a virtual machine, like JVM or CLR, but designed with sandboxing in mind (it has no built-in ways to access the outside world, the host determines that). There are many cases where you want to run sandboxed tasks server-side and webassembly is a good fit for those.
- JVM and CLR are usually primary targets - often the only targets - of the languages targeting them. WAsm is always secondary at best. Which means there always exists another choice than WAsm and it's always better, faster, and more supported - the opposite of most JVM/CLR languages.
A few years back I'd have said, forget JS, it's so slow, why are you trying to compete with real VMs anyway? Then they started optimizing the shit out of it. I wouldn't count on WebAsm not gaining enough traction for a similar thing to happen.
JS gained traction because Apple banned Flash. That was the sole reason why Angular, React, Node, NPM, leftpad and so on exist today. No similar event occurred in WAsm's 10 years of existence so far, and doesn't look like it's going to happen in the next 10 either.
I'm not well versed in JS historiography but I don't see how that should have had a big influence on its server-side adoption. Didn't a lot of the optimization happen after some people decided Node was a good idea?
- You sandbox code you don't trust. Do you not trust your own code?
Every exploited server is someone who trusted their own code.
Okay, so you don't trust your own code. Why did you give it access to your entire database and all your API keys?
I'd like to give it access to as much as it needs to do its job but no more. Often enough, it can do more.
-
@dkf but do you realize how much damage can be done with those authorizations? Your entire business might go poof for hours, maybe days, and it will take weeks to sort out everything that got lost since last backup, especially if anything financial happened.
I'm not saying not to authorize your app to do things it needs to do. I'm saying that since you already authorized it to do so, and don't consider it to be a critical risk to your service's survivability - how much would you be gaining by sandboxing really, and is all the extra effort actually worth anything?
-
@dkf but do you realize how much damage can be done with those authorizations? Your entire business might go poof for hours, maybe days, and it will take weeks to sort out everything that got lost since last backup, especially if anything financial happened.
Well no, because it doesn't have the credentials to access the DB for that part of the business. We don't put all our eggs in one basket. The API keys it has only allow exactly what is required for the app, and the nature of them is such that they can't be used for any other purpose. (Not even for debugging the application. Goddamnit, Keycloak!)
I'm not saying not to authorize your app to do things it needs to do. I'm saying that since you already authorized it to do so, and don't consider it to be a critical risk to your service's survivability - how much would you be gaining by sandboxing really, and is all the extra effort actually worth anything?
The point of a sandbox is to give a finer grained control over what permissions are granted. For example, it might let you use the API guarded by the token but not see the token itself; only a proxy for the API is exposed within the sandbox. This is in addition to the security policies implemented by the OS, mainly because those are probably set by someone else. By sandboxing, we have better assurance that we will not cause problems even if we make a mistake, because the sandbox characterises what the real capabilities of the code are.
Of course, it is also possible to make mistakes in sandboxing. But that we might make a mistake in one place (hopefully an easily auditable one!) is not a reason to not try to prevent code in other places from having access to exploitable capabilities it doesn't strictly need.
-
On another topic...
You think server-side JS is stupid? I just saw a blog post about server-side WebAssembly.
Server-side webassembly is not stupid though. Webassembly isn't really tied to web in any way except the name. It is just a virtual machine, like JVM or CLR, but designed with sandboxing in mind (it has no built-in ways to access the outside world, the host determines that). There are many cases where you want to run sandboxed tasks server-side and webassembly is a good fit for those.
- JVM and CLR are usually primary targets - often the only targets - of the languages targeting them. WAsm is always secondary at best. Which means there always exists another choice than WAsm and it's always better, faster, and more supported - the opposite of most JVM/CLR languages.
A few years back I'd have said, forget JS, it's so slow, why are you trying to compete with real VMs anyway? Then they started optimizing the shit out of it. I wouldn't count on WebAsm not gaining enough traction for a similar thing to happen.
JS gained traction because Apple banned Flash. That was the sole reason why Angular, React, Node, NPM, leftpad and so on exist today. No similar event occurred in WAsm's 10 years of existence so far, and doesn't look like it's going to happen in the next 10 either.
I'm not well versed in JS historiography but I don't see how that should have had a big influence on its server-side adoption.
Apple blocked Flash -> web apps needed a new platform -> HTML5 effort started, championed by Google -> JS was upgraded enough to be barely usable -> Angular was made, championed by Google -> JS projects need real packaging now -> build systems became standard way of working with client-side JS -> JS evolution wasn't tied to browser evolution anymore and could happen at much faster rate -> JS became good enough to make real apps in -> software companies realized the power of locking all their products behind a website -> software companies seen the writing on the wall that smartphones will become dominant market -> software companies that already had web apps realized they can save costs by making the mobile apps simply display their website -> native JS environments were developed to better integrate those mobile/web app hybrids with system features of smartphones -> suddenly you could run JS programs with all bells and whistles without a browser -> software companies still think in terms of hiring developers for specific languages -> this misconception makes them believe a single language across the entire tech stack is amazing -> JS is still the only real possibility in web app space -> it was decided to use JS for everything including the server.
Not all of those happened sequentially, of course. But as soon Google and Apple joined WHATWG, the future was set in stone and things couldn't have happened any other way.
-
The point of a sandbox is to give a finer grained control over what permissions are granted. For example, it might let you use the API guarded by the token but not see the token itself; only a proxy for the API is exposed within the sandbox.
I'm not talking about that kind of sandbox. I'm talking strictly about running code as an ELF executable vs. running it as a WAsm executable. Lots of extra work and extra problems to worry about for essentially no gain.
-
The point of a sandbox is to give a finer grained control over what permissions are granted. For example, it might let you use the API guarded by the token but not see the token itself; only a proxy for the API is exposed within the sandbox.
I'm not talking about that kind of sandbox. I'm talking strictly about running code as an ELF executable vs. running it as a WAsm executable. Lots of extra work and extra problems to worry about for essentially no gain.
But that is the sort of sandbox that WASM offers: the profile of operations offered by the host environment to the WASM app is the only way it has of interacting with the outside world, and that most definitely doesn't need to be standardised. There are some common profiles (especially for in-browser work), but they aren't all identical.
-
@dkf but so does a virtualized, dockerized system. Putting WAsm on top of that (and in 99% of companies it will be on top of that by necessity because cloud) accomplishes nothing.
At my current job, we do use WAsm for a non-web app, but for a completely different reason - to circumvent the certification process of the platform's very protective and very slow-acting owner. That I absolutely agree with, although I'm still shocked we're actually allowed to do it.
-
@dkf but so does a virtualized, dockerized system. Putting WAsm on top of that (and in 99% of companies it will be on top of that by necessity because cloud) accomplishes nothing.
So does running it in a chroot environment of the kind we've had for literally decades.
Iff everybody sets up everything just right and none of the components involved has any bugs that is. Just like with Docker.
It's another line of defense
-
Unless you're in Python, where they're best treated as immutable lists.
My only experience with tuples is in Python, so I didn't know they're ever not just that. TIL.
-
you are better off not trusting your programmers,
As every reader of TDWTF should know!
-
@Gern_Blaanston said in WTF Bites:
Shit happens, and sometimes you just have to stop being the old guy yelling at clouds.
Heretic!
-
On another topic...
You think server-side JS is stupid? I just saw a blog post about server-side WebAssembly.
Running on Ring0, even.
-
@Gern_Blaanston said in WTF Bites:
sometimes you just have to stop being the old guy yelling at clouds.
This is never necessary. Death and irrelevance are always available.
-
@sebastian-galczynski the basic problem is that there are too many developers. About half or so need to be fired and go flip burgers instead, and i believe that productivity would go up by doing that.
You, me and the three members of my team worth a dam would volunteer to go burger flipping if we could afford it. I agree with the sentiment but what we need to to is start with the ideas people. I think that would solve a good chunk of the problem.
-
@sebastian-galczynski the basic problem is that there are too many developers. About half or so need to be fired and go flip burgers instead, and i believe that productivity would go up by doing that.
You, me and the three members of my team worth a dam would volunteer to go burger flipping if we could afford it. I agree with the sentiment but what we need to to is start with the ideas people. I think that would solve a good chunk of the problem.
Fish rot from the head. There should not be CIOs. Even the title reveals this - "oh, let's take a term from our oldest, most dangerous sociotech and jam it into cybernetics!" It's an inherently harmful position, given the Peter Principle and the slow substitution of value from ability to deference, as the ability decays, dies, and still demands that it be deferred to.
Yes, this does describe a particular person.
-
@sebastian-galczynski the basic problem is that there are too many developers. About half or so need to be fired and go flip burgers instead, and i believe that productivity would go up by doing that.
You, me and the three members of my team worth a dam would volunteer to go burger flipping if we could afford it. I agree with the sentiment but what we need to to is start with the ideas people. I think that would solve a good chunk of the problem.
Yeah, I think most of management could be sent to Gulag without adverse effects.
-
@sebastian-galczynski the basic problem is that there are too many developers. About half or so need to be fired and go flip burgers instead, and i believe that productivity would go up by doing that.
You, me and the three members of my team worth a dam would volunteer to go burger flipping if we could afford it. I agree with the sentiment but what we need to to is start with the ideas people. I think that would solve a good chunk of the problem.
Yeah, I think most of management could be sent to Gulag without adverse effects.
I've got some good BAs who can generate real profits and savings, but the incompetent-by-definition C-level does everything they can to prevent it. Our group still generated 5 million in savings last year. But next year, they won't.
And may Aamet leave their soules uneaten. Let them know for eternity instead that they were weighed and found heavy.
-
@Gern_Blaanston said in WTF Bites:
@Gern_Blaanston said in WTF Bites:
As for using RSVP as a verb, I see nothing wrong with that. Responding to something is an action, you are doing something, and that's what verbs are for.
I respondpleased is like saying I fuckyouverymuched up. It does contain the verb that expresses what you're trying to say, but the rest of it changes the meaning to something different.
Words, and their use, change over time.
Programming languages and their use change too, but it doesn't make those who write in JS any less wrong.
So what are the practical alternatives to JavaScript for web developers?
Very often I don’t need to write vast pieces of code to do what I need to get done. Like the chunk of functionality I wrote this week for some bespoke menu behaviour on a website, weighed in at 20 lines. I could have done it in TS or WebAsm, neither of which my project are set up for (and, honestly, that’s so unlikely to change it’s hilarious) or I could have just written my 20 lines and shipped something the client cared about.
And that’s before we talk about all the legacy code to interoperate with.
-
@Gern_Blaanston said in WTF Bites:
@Gern_Blaanston said in WTF Bites:
As for using RSVP as a verb, I see nothing wrong with that. Responding to something is an action, you are doing something, and that's what verbs are for.
I respondpleased is like saying I fuckyouverymuched up. It does contain the verb that expresses what you're trying to say, but the rest of it changes the meaning to something different.
Words, and their use, change over time.
Programming languages and their use change too, but it doesn't make those who write in JS any less wrong.
So what are the practical alternatives to JavaScript for web developers?
s/write/choose - happy now?
I didn't choose JavaScript, JavaScript chose me.
-
@Gern_Blaanston said in WTF Bites:
@Gern_Blaanston said in WTF Bites:
As for using RSVP as a verb, I see nothing wrong with that. Responding to something is an action, you are doing something, and that's what verbs are for.
I respondpleased is like saying I fuckyouverymuched up. It does contain the verb that expresses what you're trying to say, but the rest of it changes the meaning to something different.
Words, and their use, change over time.
Programming languages and their use change too, but it doesn't make those who write in JS any less wrong.
So what are the practical alternatives to JavaScript for web developers?
Very often I don’t need to write vast pieces of code to do what I need to get done. Like the chunk of functionality I wrote this week for some bespoke menu behaviour on a website, weighed in at 20 lines. I could have done it in TS or WebAsm, neither of which my project are set up for (and, honestly, that’s so unlikely to change it’s hilarious) or I could have just written my 20 lines and shipped something the client cared about.
And that’s before we talk about all the legacy code to interoperate with.
Probably biting off more than I can chew but is it just me or could a good chunk of these frameworks and js libraries be dumped if people actually went and learned html and css.
@Carnage add magpies to that list.
-
@DogsB Gatsby is basically that. At least promises to. Haven't tried myself.
As for going raw and doing vanilla JS only - no, no way in hell. Near impossible to do any decent MVVM/data binding without a framework.
-
@DogsB Gatsby is basically that. At least promises to. Haven't tried myself.
As for going raw and doing vanilla JS only - no, no way in hell. Near impossible to do any decent MVVM/data binding without a framework.
Looks like more js shite that’s more marketing blurb than anything useful.
-
@DogsB a modern website that's entirely static files is very useful. Yes, you can make React do the same, but instructions are unclear and it's easy to get something stuck in a ceiling fan. In Gatsby, all-static is the default.
-
@DogsB a modern website that's entirely static files is very useful. Yes, you can make React do the same, but instructions are unclear and it's easy to get something stuck in a ceiling fan. In Gatsby, all-static is the default.
Yeah as much static as possible is just plain sensical, which means rarely done.
-
@DogsB a modern website that's entirely static files is very useful. Yes, you can make React do the same, but instructions are unclear and it's easy to get something stuck in a ceiling fan. In Gatsby, all-static is the default.
If it’s all static files why do you need a “React-based, open-source framework”
-
@DogsB a modern website that's entirely static files is very useful. Yes, you can make React do the same, but instructions are unclear and it's easy to get something stuck in a ceiling fan. In Gatsby, all-static is the default.
If it’s all static files why do you need a “React-based, open-source framework”
Gotta make it cool somehow.
-
@DogsB a modern website that's entirely static files is very useful. Yes, you can make React do the same, but instructions are unclear and it's easy to get something stuck in a ceiling fan. In Gatsby, all-static is the default.
You mean other than the API that powers it that isn’t static?
-
@loopback0 said in WTF Bites:
@DogsB a modern website that's entirely static files is very useful. Yes, you can make React do the same, but instructions are unclear and it's easy to get something stuck in a ceiling fan. In Gatsby, all-static is the default.
If it’s all static files why do you need a “React-based, open-source framework”
Gotta make it cool somehow.
