Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programs are dead, and JavaScript has killed them

pouria.dev

Post reply on HN
Print view View original

211–216 of 216 posts

Re: Programs are dead, and JavaScript has killed them

#211

Post by yazaddaruvala »

kingboss wrote: post #210
yazaddaruvala wrote: post #174

Earlier quoted context omitted.

I have! It's a very good talk. I wouldn't make any design or technology decisions based on it tho. What is clear today is that Javascript is on every computer in the world (including phones). It is now even taking over for native desktop apps and native mobile apps. At this point, including a JS engine into all the kernels for apps and browsers to use just seems prudent.

JS in kernel is a beyond idiotic idea. Why the hell would you put something like that in the kernel? Computing world has lost its mind if this can even come up as a suggestion. I just feel that 90% of people on this website are junior web devs. That must be the reason for the glorification of a POS language such as JS. Why the hell would you even want to run this garbage language on the server? Now you want it in the…

lol, are you familiar with ring 0? what about context switching and scheduler preemption? If you are, then you know they add significant overhead to IO bound applications.

> Why the hell would you put something like that in the kernel?

Because some ridiculously large % of all client software is written in/transpiled to JavaScript?

If the JS/WASM runtime would be run with the correct sandboxing (similar to browsers like Chrome), you likely could run the entire application in ring 0 and only context switch because of scheduling preemption. Maybe even ouch the whole browser into the kernel?

All runtime APIs that currently need “syscalls” would become significantly more efficient. You’d end up with an extremely performant system for running browsers and browser like apps (ie Electron).

Re: Programs are dead, and JavaScript has killed them

#212

Post by LtWorf »

ozim wrote: post #170
LtWorf wrote: post #153

Earlier quoted context omitted.

> Couple hundred years ago people were still thinking that Earth is in the center of the universe :) They were? Were they educated people or just some random people?

Well just read up: https://en.wikipedia.org/wiki/Nicolaus_Copernicus Couple hundred years ago - this was up to 600 years ago - I was not saying about 100 or 200.

Well 200 is "a couple"

Re: Programs are dead, and JavaScript has killed them

#213

Post by kingboss »

yazaddaruvala wrote: post #211
kingboss wrote: post #210

Earlier quoted context omitted.

JS in kernel is a beyond idiotic idea. Why the hell would you put something like that in the kernel? Computing world has lost its mind if this can even come up as a suggestion. I just feel that 90% of people on this website are junior web devs. That must be the reason for the glorification of a POS language such as JS. Why the hell would you even want to run this garbage language on the server? Now you want it in the…

lol, are you familiar with ring 0? what about context switching and scheduler preemption? If you are, then you know they add significant overhead to IO bound applications. > Why the hell would you put something like that in the kernel? Because some ridiculously large % of all client software is written in/transpiled to JavaScript? If the JS/WASM runtime would be run with the correct sandboxing (similar to browsers li…

I am familiar with ring 0. Familiar enough to understand how stupid it would be to put a browser there. You don't need that many syscalls if you know what you are doing. Obviously, JS guys don't since they argue that many syscalls are needed and it's impacting performance enough that they should move it to ring 0. Jesus H Christ ...

Re: Programs are dead, and JavaScript has killed them

#215

Post by cb321 »

cduzz wrote: post #73
andsens wrote: post #61

Earlier quoted context omitted.

shameless plug If you want to avoid having to write your own args parser everytime or think getopt is a pain, you should check out my little project: https://github.com/andsens/docopt.sh No dependencies, the code is directly inlined into your script, and you write the args parser by writing the help-text.

hey='you can define variables' do_this='without commandline parsing' ./thing #!/bin/sh hey=${hey:='default one'} do_this=${do_this:='default two'} not_that=${not_that:='because getopts is a nightmare'} echo "${hey} ${do_this} ${not_that}"

If you want to be more DRY (do not repeat yourself) with regard to the variable names you can use the `:` command inside the script (which just expands its arguments) as in

    : ${hey:='default one'}
or even more briefly just use that `:=` {or `=`} assign if empty or unset {or assign if unset} at the first use case.

Also, besides shells most prog.langs have easy ways to receive these { getenv in C, os.environ.get("do_this", "default two") in Python, etc. }.

--

I think what people really miss here is the (rarely used, I guess?) shell calling/invocation syntax @cduzz points out of:

    var1=val1 var2=val2 program
which is notably even more terse than GNU long options:

    program --var1=val1 --var2=val2
Also missing is a documentation standard/convention like:

    help= program
to dump out settings possibilities and their defaults and maybe their types (integer, string, bool, etc.). One virtue of the `:` syntax above is that it is rare enough in "ordinary shell code" that you could probably auto-generate the help from such a table at the top of the script via

    grep '^: ' "$0"
at least if you are willing to assume the invoker sets $0 to a full path.

Soon enough you may outgrow shell programming and, if you become used to such nice conveniences and are willing to learn Nim, I might then recommend something more like https://github.com/c-blake/cligen

Re: Programs are dead, and JavaScript has killed them

#216

Post by cb321 »

tambourine_man wrote: post #81
cduzz wrote: post #73

Earlier quoted context omitted.

hey='you can define variables' do_this='without commandline parsing' ./thing #!/bin/sh hey=${hey:='default one'} do_this=${do_this:='default two'} not_that=${not_that:='because getopts is a nightmare'} echo "${hey} ${do_this} ${not_that}"

I’ve been bashing for decades and never thought of that. Thank you

You might also see ideas in https://news.ycombinator.com/item?id=34147636
Post reply on HN