161–170 of 189 posts
Earlier quoted context omitted.
No, but it's very nice to be able to share code for things like view rendering or form validation between the server and client without jumping through hoops.
So you use language X. Compile it and run it natively on server, compile it to wasm and run that in the browser.
Earlier quoted context omitted.
I'll generally agree with your definitions for concurrency and parallelism. Our parallelism definitions were essentially the same. But what you say about coldtea is not a fair interpretation of their post. millstone said this: The event loop doesn't allow you to do a computation concurrently with handling user events, so it's not at all a proper concurrency model. By this definition, concurrency is only occurring whe…
That's not the definition I had in mind. What I meant is that JavaScript lacks an easy way to allow for computation that doesn't block the event loop. We can imagine an old school cooperative multithreading architecture: for (var i = 0; i but JavaScript does not support this. Instead you have to awkwardly re-structure your computation in CPS or an equivalent to do this sort of thing.
I'm late to the party but please for anyone reading this, look into the actor model. Shared mutable state quickly becomes unmaintainanble. It used to be slow to do shared immutable state but that's no longer the case. Today there are many better ways to do shared memory with copy-on-write so data is only copied if it's changed. Think back on history - there are only a handful of computation approaches that have stood…
For one, AFAICT very few implementations provide built-in back-pressure which is crucial if you want to avoid runaway resource consumption or having to just drop messages on the floor. This may not be critical for one's particular scenario, but it very often is for applications where you'd used threading and blocking queues (redezvous being a special case).
Earlier quoted context omitted.
When told that multi-threaded access is hard and messy, "X program uses threads and it's not a mess" is not an argument -- for one because nobody said X program is a mess. Threads being messy is not a transitive property. Nobody doing threads ever said that they are not messy or that multi-thread access and locking et al are easy.
Oh ffs I feel like I'm back in 1994 or so...
(If you answer just use Erlang, CSP or any other variation, well, my point exactly).
Earlier quoted context omitted.
I draw the line at whether the interleaving granule is under the programmer’s control or not. For example, I can say that when a task executes on an event loop, no other tasks are executing concurrently to it because the event loop executes tasks sequentially .
Ok you draw the line there, but definitions are supposed to be commonly understood, that's how language works...
Earlier quoted context omitted.
It would have been a shame if the OSes on which Firefox runs had similarly limited access to shared memory to one particular "safe" style in the spirit of paternalistic caution. Would Rust/Servo have been possible without access to the raw rope?
This isn't about "paternalistic caution," it's about purposeful and sensible engineering. JavaScript wasn't designed for threading, and it's a less natural fit for it compared to a language like C, so this is understandably a pretty serious undertaking. Your point is that this may enable some currently unimplementable application in JavaScript. The assumption is that Firefox couldn't have existed without a free-for-a…
JS is actually a better fit for threading than C, and in many ways it has similar problems. Unlike C, JS has memory safety and concurrency wouldn’t break that. Concurrent programming is a lot easier if you can’t corrupt the heap. Like C, JS has some “global” variables like RegExp.lastMatch (C has errno) that need to be made into thread-locals. My proposal includes thread locals so it would be easy to make lastMatch into a getter that loads from a thread local.
Earlier quoted context omitted.
Tests are great. No harm in tests. I just don't think that we have sufficient evidence to conclude that using type systems to aid the development of concurrent code actually leads to better concurrent code. Therefore, I err on the side of not using the type system for that purpose so that I can use it for many other things that I think it's really good at. (Just take a look at JSC's source code if you want to see our…
> I just don't think that we have sufficient evidence to conclude that using type systems to aid the development of concurrent code actually leads to better concurrent code. This is like saying we don't have evidence that evolution is real. Type systems are proof systems. If a type system encodes concurrency safety, and a program is valid under that system, then you can be 100% certain that program doesn't have a rac…
A type system is a proof. But the proof in the type system is not a proof that it’s better to use a type system than not. That’s an entirely separate question.
I think that type systems are good at some things. Concurrency isn’t one of them.
Earlier quoted context omitted.
I do threads and I just said that they are not messy.
Well, nobody sane then if I'm allowed the Scotsman! People also defend all kinds of dangerous constructs or practices blaming other programmers for not being good enough to use them even though statistically even the best programmers suffer from problems derived from them (e.g. buffer overflows, or in the case of threads race conditions, starvation, etc.). And since we're particularly talking about adding threads to…
Earlier quoted context omitted.
Can you be very specific?
When told that multi-threaded access is hard and messy, "X program uses threads and it's not a mess" is not an argument -- for one because nobody said X program is a mess. Threads being messy is not a transitive property. Nobody doing threads ever said that they are not messy or that multi-thread access and locking et al are easy.
Like I said, WebKit uses threads and it’s great. Maybe some day you will also learn to use threads.
Earlier quoted context omitted.
When told that multi-threaded access is hard and messy, "X program uses threads and it's not a mess" is not an argument -- for one because nobody said X program is a mess. Threads being messy is not a transitive property. Nobody doing threads ever said that they are not messy or that multi-thread access and locking et al are easy.
You just called WebKit a twisted mess. I asked you for examples. Looks like you don’t have any. Like I said, WebKit uses threads and it’s great. Maybe some day you will also learn to use threads.