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

The Birth and Death of JavaScript [video]

destroyallsoftware.com

Post reply on HN
Print view View original

151–160 of 236 posts

Re: The Birth and Death of JavaScript [video]

#151

Post by nothiggs »

MichaelGG wrote: post #137
briantakita wrote: post #134

Earlier quoted context omitted.

> Javascript is a bad choice Javascript is great once used in a "good" way. It's flexible & it's almost everywhere. Spending all your time complaining about how "bad" Javascript is kindof pointless. If you use Javascript, learn how to use it well. Master sushi chefs don't sit there complaining how bad knives are because the knives need to be constantly sharpened. If you are cooking spaghetti, learn how to strain the…

With this logic you can defend anything. PHP's great if used in a good way: Zuckerman's a billionaire. Right? Why is anyone even bothering with PL these days? Sushi knives don't decide to cut you because the rice came from a different origin. And I'd guess that most craftsmen, outside of a ritual and tradition would love for their tools to have less disadvantages. If you want to draw an analogy to spaghetti (?), it'd…

The following perfectly describes my sentiments about all the complaints people have about JavaScript, PHP,

https://www.youtube.com/watch?v=uEY58fiSK8E

Re: The Birth and Death of JavaScript [video]

#152

Post by nly »

andhow wrote: post #106
nly wrote: post #104

Earlier quoted context omitted.

What you seem to be missing with re: asm.js is that, while the JIT to native code gets you your super-fast integer operations, it's still critically incomplete with regard to memory access. Every single individual memory access has to be bounds checked or pushed through some other indirection inside the runtime. Google demonstrated similar ideas with NaCl, which achieved safety with a similarly restricted native code…

On x64 in Firefox, at least, there are no bounds checks; the index is a uint32; the entire accessible 4GB range is mapped PROT_NONE with only the accessible region mapped PROT_READ|PROT_WRITE; out-of-bounds accesses thus reliably turn into SIGSEGVs which are handled safely after which execution resumes. Thus, bounds checking is effectively performed by the MMU.

Interesting approach, might have to look at the code. Nonetheless it highlights how useful the MMU is and how none of this is free.

Re: The Birth and Death of JavaScript [video]

#153

Post by tinco »

gary_bernhardt wrote: post #69
tinco wrote: post #61

The reason why metal doesn't exist now is because you can't turn the memory protection stuff off in modern CPU's. For some weird reason (I'm not an OS/CPU developer) switching to long mode on an x86 cpu also turns on the mmu stuff. You just can't have one without the other. There's a whole bunch of research done on VM software managed operating systems, back when the VM's started becoming really good. Microsoft's Sin…

I didn't want to go into this level of detail in the talk, but... I think you still want the MMU enabled, just not used for process isolation. With virtual memory totally disabled, a 1 GB malloc takes 1 GB physical memory even if it's not touched, you can't have swap at all, memory fragmentation kills you dead, etc. It still has a lot of utility outside of isolation. I don't have a good sense of how the performance c…

After the Operating Systems and Computer Organization courses in my first year of universisty I became a little obsessed with the idea of software managed operating systems. Cool to hear Singularity inspired you as well.

Now I didn't read the paper, but I think the 20% is purely the MMU, I think the protection ring switching thing is much less significant, so I think if you leave the MMU still on that 20% profit is still very optimistic.

Now, if you forget about compiling C (which defeats the purpose of your talk) and just compile managed languages like regular JS, the garbage collector can build a great model of memory usage. Therefore I think it could be much better to let the garbage collector manage both the isolation, and the swapping. So everything in software.

The swapping process would suffer some performance, but that's just CPU cycles, as everyone knows persistent data access isn't even in the same league as CPU memory access.

So yeah, that would mean that you would have to run all untrusted code in managed mode. And with untrusted I would mean code you can't trust with full physical memory access.

Re: The Birth and Death of JavaScript [video]

#156

Post by lomnakkus »

nothiggs wrote: post #151
MichaelGG wrote: post #137

Earlier quoted context omitted.

With this logic you can defend anything. PHP's great if used in a good way: Zuckerman's a billionaire. Right? Why is anyone even bothering with PL these days? Sushi knives don't decide to cut you because the rice came from a different origin. And I'd guess that most craftsmen, outside of a ritual and tradition would love for their tools to have less disadvantages. If you want to draw an analogy to spaghetti (?), it'd…

The following perfectly describes my sentiments about all the complaints people have about JavaScript, PHP, https://www.youtube.com/watch?v=uEY58fiSK8E

So we should just give up completely on trying to make better things?

I don't think that was the point of the video (some amount of gratitude for the things we have) -- but then maybe I'm misunderstanding your point.

Re: The Birth and Death of JavaScript [video]

#157

Post by meowface »

briantakita wrote: post #132
hcarvalhoalves wrote: post #83

Earlier quoted context omitted.

I don't think `parseInt` accepting an optional second argument is the surprising behavior there. The real WTF is `map` passing more than one argument, and the loose behavior of JS regarding argument passing overall.

It's only WTF because it's not the same as other implementations of map. Once you can internalize the map implementation, it's no longer WTF & actually makes sense.

It makes sense but it still strongly violates the principle of least surprise. No other language I know of does this, nor do I think this would be a particularly desirable feature.

Re: The Birth and Death of JavaScript [video]

#158

Post by meowface »

kevincennis wrote: post #74
jisaacks wrote: post #28

Earlier quoted context omitted.

And since 0 is falsy we get 10 for base 0.

It's not exactly checking for falsy values. Although all falsy values will lead to a radix of 10 being applied. parseInt internally uses the ToInt32 abstract operation on the radix parameter. Once it has that value, it explicitly looks to see if the value is 0. If it is, it uses a radix of 10. https://people.mozilla.org/~jorendorff/es6-draft.html#sec-pa... Edit: I hope that doesn't come off as pedantic. My point wasn…

This is HN, there's no such thing as being pedantic. :)

Re: The Birth and Death of JavaScript [video]

#160

Post by nothiggs »

lomnakkus wrote: post #156
nothiggs wrote: post #151

Earlier quoted context omitted.

The following perfectly describes my sentiments about all the complaints people have about JavaScript, PHP, https://www.youtube.com/watch?v=uEY58fiSK8E

So we should just give up completely on trying to make better things? I don't think that was the point of the video (some amount of gratitude for the things we have) -- but then maybe I'm misunderstanding your point.

On the contrary. We should strive to correct all the "wats" that obviously exist in all these languages, but most of what I see is just complaints, most of them ignoring the amazing things that can be done with these technologies. Over 30 year I've been programming in more languages than I care to count, and I don't remember at any point having a specific language stop me from achieving my goal because it has some traps or design flaws. Always made sure to know about them and make use of the language's strong points instead of concentrating on the weak.

And we both understood the point of the video. The fact that there is much to be grateful for does not mean that we shouldn't improve on what needs improving. But for heaven's sake, if you're not going to improve on it, stop whining about it and be grateful for the amazing things it does enable.

Post reply on HN