Happening: Node.js creator regrets creating Node.js
Other urls found in this thread:
en.wikipedia.org
npmjs.com
devdocs.io
devdocs.io
destroyallsoftware.com
developer.mozilla.org
devdocs.io
devdocs.io
devdocs.io
v8.dev
devdocs.io
devdocs.io
devdocs.io
ecma-international.org
github.com
github.com
twitter.com
JS turned out to be a huge mistake, anything built on it even moreso.
He doesn't look very healthy
it's the AIDS look
>js
>a mistake
how so?
>inb4 muh slow sites
No muh spaghetti insecure code.
>umm.. sooo... *waves hands effeminately*
The guy is very humble considering he created such a great thing
>Happening
This is over 4 months old
>regrets creating Node.js
No he doesn't. He regrets a small handful of things about it, primarily related to npm.
Most of this talk is just an advertisement for Deno anyway, which is his new project that's basically just node but for Typescript
he's a filthy neet
>primarily related to npm
Funny because npm and how easy and fast they are to use is mainly why node is so popular
It's a terribly designed language thrown together in extreme hurry (Netscape gave Eich literally 10 (ten) days for the job) that was never meant to be used for anything more serious than simple DOM manipulation and displaying clocks on 1995-style websites. As the web grew larger and more complicated, it had no alternative but to embrace that shit with all of its design flaws and cross-browser incompatibilities, while ECMA standard revisions kept putting more lipstick on that pig.
Then the generation of kids who grew with the web thought: "hey, since we're already familiar with it, why don't we bring JS to the back-end as well?" which was probably one of the worst ideas in the history of mankind.
>It's a terribly designed language
What makes you say that?
>Dynamically typed (at least typescript fixes this)
>Callback hell
>No proper multithreading
>Type system is an absolute clusterfuck, see == vs ===
I'll agree that non-strict, pre-2013 JS was terrible, but compared to other interpreted languages I'd say it holds its own pretty well.
>Fixed by Typescript/Flow, etc. Common in interpreted languages
>What are Promises or async/await
>Again, common in interpreted languages and there are strategies to deal with this
>Non-argument. They are fundamentally different operators that have nothing to do with the type-system or lack thereof.
>>Again, common in interpreted languages and there are strategies to deal with this
Still doesn't make it better. CPUs are hitting performance walls, and they're just adding more cores instead. Non-SMT languages will become worse and worse in terms of performance as more and more bloat gets added.
you also forgot:
>function scoping instead of block scoping
>the 'this' keyword and OOP is a complete dumpster fire in JS
>anonymous functions
>uses promises to "fix" call back hell
>const declarations aren't immutable, its just an immutable reference
There really isn't anything redeeming about JS other than it is pretty ubiquitous since it is in every browser.
Can you use typescript with Node? Sry i am a complete beginner
Sure, that's fair. But there are strategies and libraries to help deal with this. Napa is a library example, and a very common Node strategy is to simply have a cluster of processes that communicate via some bus.
Found the dumb ass web developer. Java, which is one of the most popular interpreted languages has proper multi-thread support and so does C#. And yes '==' and are '===' related operators. The only reason they came out with the later is because JS has a retarded type system.
>is to simply have a cluster of processes that communicate via some bus
Which adds overhead and complexity.
At that point, it becomes a question of "why bother with this language" because JS's only advantages, even over stuff like python, become "well it runs in a browser" and "we can hire some poos for $2 an hour to write it"
>Java
>interpreted
u wot m8
>Block scoping has been in the language for like 4 years
>The only weird behavior of "this" is in the global window context. It is a prototype oriented language, Java concepts aren't meant to translate 1-1.
>An objectively good feature, most languages are starting to or have already added it
>Again, a good feature that is made better by async/await
>const has a specific meaning in JS, baggage from other languages is irrelevant
There are a lot of valid complaints about the language, but they certainly aren't these. This is the same cult logic that people use when they say "Ug ug, PHP bad" without knowing why (just parroting other people).
>Dynamically typed
>No proper multithreading
Fair enough, although I'm not convinced that static typing would be better for the kind of stuff I usually want to use JS for.
>Callback hell
Not since promises and async/await were added.
>== vs ===
Those type issues are all very easy to avoid... when I write JS I just always use === and make all casting explicit.
It's good to see you're not one of those people who just hates on JS because other people do it and you saw a list of some 'typeof(null) === "object"' quirks on the web somewhere. It is a flawed language, I'm just not sure I'd call it terribly designed. To me, it just seems mediocre. Not great, not horrible. I've yet to come across a computer language that I don't strongly dislike something about, so maybe I'll try to create my own at some point.
>although I'm not convinced that static typing would be better
Out of curiosity, when is static typing not better?
Any extra work taken to write it is generally handled by an IDE anyway.
What's wrong with anonymous functions?
First of all, Java is not an interpreted language, so you've kinda already shown yourself to be ignorant. Second, if you understand anything about language syntax you should understand that reference equality, value equality, and type coercion are all things that need to be account for. An example of this is the "is" operator and the "==" operator in Python. You can achieve a similar effect with comparing pointers vs the value of the dereferenced pointer in something like C.
>Common in interpreted languages
Except js shouldn't be an interpreted language in 2018.
We have fast hardware and yet we struggle to have smooth scrolling on EVERY. SINGLE. ONE. website as it MUST be in 2018.
We can draw billions of polygons in one second on modern gpu because we took time to develop really fast tools, we knew it was necessary to have really optimized hard/software when pretty much any image manipulation algorithm is quadratic in time and/or space.
Somehow it's ok for the web, which represent billions of users and dollars, to be based on really slow (by 2018 standards) and not future-proof technologies.
Modern web need more performant tools and it seems that js has achieve pick performance.
Only solution is to change tools.
Not the same person but arguably for quick, one-off scripts that just need to handle simple interactions. It is easier to quickly iterate on simple ideas in that case. I personally prefer to always have typing though.
>hurr durr node has no multithreading
out of curiosity when did a site on Node shit itself because of lack of performance cause i can't remember a situation like that.
>brainlets don't understand that multithreading is not the same as simultaneous multithreading
>Out of curiosity, when is static typing not better?
When you're not worried about your code killing people if it malfunctions and you're not worried about other people trying to add to your code later - instead, you're working on a passion project and you never make any type mistakes in your code, and having a type system would just be bloat.
The result is the same, is that node doesn't have performance problems unless all you measure performance is by benchmarks from fuck-knows-what-shite
This is a complete misrepresentation of the state of JS. The reason sites are slow these days is a combination of volume of code and poorly written code. With WebWorkers/ServiceWorkers you can have IPC in the browser. With well-planned styles you can have GPU rendered animations. Sites are slow because the barrier of entry for web dev is super low, not because the tools are bad. Browsers are some of the most heavily developed pieces of software (still far from perfect). I'd argue another issue is the prevalence of third party (ad/tracking) code in so many websites.
>this language that is constricted to your own code using a single CPU core doesn't have performance issues, I swear!
>never mind the fact that people have to resort to fucking IPC as a workaround, thus confirming this exact issue!
>With WebWorkers/ServiceWorkers
And I don't want to deal with IPC, I want to have proper SMT.
Java absolutely is an interpreted language dipshit. I know you must be confused since there is a Java "compiler" but that only targets the JVM which then INTERPRETS the byte code. The JVM even has a just in time INTERPRETER. You are basically making one of the dumbest and most pedantic arguments that has been around forever in computer science. See the following you fucking knuckle dragger:
en.wikipedia.org
They make code an unreadable cluster fuck and they default the whole point of a function, which is reusable code.
>turned out
Ecmascript was rotten from the core to begin with. The way people who I'd consider sensible webdevelopers aren't writing JS. They use it as their machine code equivalent because it's not a good language. Many of them are looking to web assembly simply because that's what they really want from JS right now.
ES never stood a chance. It's design wasn't meant for actual programming.
Just like XML/JSON aren't proper data formats.
That's simply not true. It has nothing to do with the nature of anonymous functions and everything to do with the style and ability of the person writing the code.
>no proper multithreading
npmjs.com
>And I don't want to deal with IPC, I want to have proper SMT.
Wut. Aside from games, what task do you have on the web that could possibly be performance-sensitive enough to want to deal with the complications of threading/shared memory when the message passing exposed by Workers achieves acceptable performance with an infinitely simpler concurrency model?
Node.JS guy regretting making Node is old, old news.
Cat-v dot org guy has an interview on there where the creator lamented how 99.9% of all software is a pile of shit, and how sorry he was for contributing to the shit world of shit software after he learned what good software looks like. He then went about telling people not to use Node.js but that was a long time ago, it's now it's own life.
JS is indeed aids, you don't need it to build a highly interactive and fast 'website' now that we have web assembly. Goodbye NPM and other junkware
You guys know to use WebAssembly you have to still write your site in JS right.
>sensible webdevelopers...
Edited that horribly. Meant to say that sensible webdevelopers don't use Javascript. It's not what you want.
No shit there is a bytecode interpreter, but to get to the bytecode it needs to be compiled. Bytecode is not the same as the code you write, and it is not the same as the code that gets executed by the machine. Read the passage you yourself linked.
That's the current state yes. I wasn't saying that these people use wasm right now.
const in JS is exactly like final in Java, but oyu have to initialize the variable when declaring.
If you are too retarded to make a difference between values and reference values then I'm sorry, but programming isn't for everyone.
The lines are blurred when you're talking JIT and interpreting. It's not really meaningful to bicker about it because it depends so much on what's actually going on.
I'd you look at Java bytecode it's like a highly referential IR. It's not really what you'd consider interpreted because interpreted implies the association to the original source is strong.
Not for long
Check some of the web consortium/IETF drafts of specifications for new browsers coming out
>No proper multithreading
devdocs.io
devdocs.io
>message passing
Not proper SMT.
In proper SMT, everything has access to the same heap of objects. There's no need to duplicate anything when passing it between threads.
>performance-sensitive
It's not just performance, also the memory usage. I'd rather not be duplicating objects for no good reason especially seeing as how bloated most JS is anyway.
> infinitely simpler concurrency model?
But for server-side it's mostly irrelevant, because most objects are only going to be touched by one worker thread at any given time. Message passing just adds overhead in that case.
>deal with the complications of threading/shared memory
I'm not a brainlet.
The first two examples. Are those strings in specific relevant? Or is it that any string can be coerced to null and NaN?
>multiple environments running on independent threads, and to create message channels between them
Holy fuck, the number of people who don't have the slightest clue about multithreading yet feel compelled to respond anyway is astounding.
>Multithreading is a widespread programming and execution model that allows multiple threads to exist within the context of one process. These threads share the process's resources, but are able to execute independently.
Message-passing-based multithreading (or at least, when it's the language's only possible style of multithreading) does not fit the definition of multithreading.
Then they should have just called it Final or some other shit. At least Java has the static modifier. There is no way to have a immutable value in JS other than using a constant literal which is fucking stupid. The keyword const has been used for literally DECADES to mean an immutable value. There was no good reason to pick that name which historically has very strong connotations that run contrary to what they were going for.
>what task do you have on the web that could possibly be performance-sensitive enough
every single one of them. Any performance hit is shown on your cpu/gpu and in modern ages, smartphones are a thing.
losed cpu cycles == less battery life
cpu-heavy operations == heat
Put the entry barrier higher, get a good compiler with cutting-edge static analyzer and profit.
Let's start with the primitives, shall we?
typeof null == 'object'; // true
typeof NaN == 'number'; // true
NaN == NaN // false. also there's no fucking way of determining whether a value is NaN
The type coercion rules absolutely fucking bonkers. Justify this (protip: you can't):
if('0') {
console.log("HURR");
if('0' == false) {
console.log("DURR");
}
}
How about this one?
false_obj = new Boolean(false);
false_obj == false; // true
false_obj && true; // also true
This one I'd really like to hear the logic behind:
Number.MAX_VALUE + 9e100 // = Number.MAX_VALUE
Number.MAX_VALUE + 9e200 // = Number.MAX_VALUE
Number.MAX_VALUE + 9e300 // = Infinity
Speaking of numbers:
Math.pow(2,31) == 2147483648 // true, as expected
1
Not the user you replied to, but Java is indeed an interpreted language, it needs to be to deliver on its promise of 'compile once, run everywhere'. It compiles to bytecode targeting the JVM which is one abstraction layer up from bare metal to which traditional compiled languages get translated to.
If you wanna talk blurriness between interpreted and compiled languages, check out SBCL's implementation of the onboard compiler, which can compile individual procedures to the underlying machine's binary format at runtime, now that's some hazy blurry shit.
By that definition, than almost no languages are interpreted. Only shit like bash would be considered interpreted. That is such a stupid argument. I also fucking mentioned it in my previous post. But I guess you are too fucking stupid to not be confused since Java has a "compiler". I'll try and explain for you dipshit.
The Java compiler takes source code to byte code. This byte code is targeted at the Java Virtual Machine. The Java Virtual Machine then takes the byte code and INTERPRETS it into op codes, aka machine code, of the CPU instruction set architecture it is running on. Thus the JVM is acting as an INTERPRETER.
null is a bottom value for uninitialized, no-value objects, prototypes are required to be objects, the Object type has its prototype set to null, so basically every object inherits from Object implicitly unless their prototype is set to something else
Bunch of shit there that are required by IEEE-754 double precision floating points.
If you act like a retard you won't be excused for using == instead of === but if you insist on using == then read up developer.mozilla.org
new creates a non-null object that is always a truthy value when comparing
devdocs.io
>Bitwise operators treat their operands as a sequence of 32 bits
Nice job retard, you can't even read a handful of words. How do you live a day-to-day life being such a retard
ASI is an error correcting mechanism. Use a linter to correct your errors if you are too dumb to learn where the semicolons go
devdocs.io
this has very deterministic behaviour, if you are too retarded to read this page then I'm sorry, but as said above programming is not for everyone, maybe you could try doing something else
devdocs.io
arguments is an array-like for historical reasons, but if you treat it as an array then you shouldn't have any issues with it
v8.dev
arrays are implemented in a very clever way
If you mean the [1, 2, 3, 4].map(parseInt) thing then I have bad news for you, learn the signatures of the functions you are working with
devdocs.io
devdocs.io
devdocs.io
You have to use an entirely different variable declaration to get block scoping. The problem is var is function scoped and it is still valid JS. I mean fuck, even the Mozilla Developers Network still uses var in a shit ton of their documentation and examples not to mention every fucking retard that is too lazy and stupid to start using it. Thus we are stuck with it for the foreseeable future.
Congratulations, you just explained why all of that garbage is the way it is.
You didn't, in the least bit, actually justify why any of it is like that.
You can just cross compile with emscripten or some JS targetting shitlang that you already know if you are too retarded to learn.
Are you sure programming is a thing for you? Or are you just some corss boarder retard pretending for some (You)s
>my language is shit because of miles of esoteric legacy cruft
>it's the programmers that are too stupid to learn all this esoteric legacy cruft!
Then just learn modern JS and care not about the legacy cruft?
But beside the arguments and null thing nothing you listed is a "legacy cruft", you have rest arguments operator now if you don't feel like dealing with arguments object anyway.
No, by my definition interpreted languages are interpreted. Go and try to compile JS to bytecode in advance and have V8 execute it, tell me how it goes.
>muh ECMA-262 clearly states "+" can become a multiplication operator when one of the operands is a prime and there's a full moon next week
>it's not a bad design, because it's codified by the spec, you brainlet
wew
wrt use I was talking about a client-side use case. If you're chasing SMT for the sake of SMT, without an actual use-case, I feel like you don't develop actual software. Sure message passing has overhead, though Workers have ways to kinda mitigate it (not really). Simplicity is more important than performance gains that will be imperceptible to the average client.
I've written loads of JS code, and none of the type conversion and comparison quirks have ever caused me any problems. I learned within the first few weeks of writing the language how to avoid most of them. I do all type conversion explicitly and never let the language do it implicitly. I always use ===.
>there's no way of determining whether a value is NaN
isNaN(value)
I agree that this is a bit of a mess.
false_obj && true; //also true
Yes, because false_obj is an object wrapping the primitive false, not the primitive value itself.
Number.MAX_VALUE ...
1
He's not entirely at fault. Good programmers did nothing and uneducated people started using it. any respecting programmer tries to get away from webdev-like tasks anyway.
Oops, meant to say:
I agree that this is a bit of a mess.
>it's yet another jubberscribd bad langooje thread
>Go and try to compile JS to bytecode in advance and have V8 execute it, tell me how it goes.
How about I duplicate the source file and change the extension to .bytecode? Does that sound good enough?
isNaN determines whether or not a value can be casted to a number (with all the standard JS type coercion retardation), as in:
>isNaN('a');
true
>isNaN('');
false
There's no way (that I know of) of telling whether a value is of the supposedly primitive type called NaN.
You won't seem less of a retard throwing unrealistic hyperboles around. Either learn the language or fuck off.
>webdev is not real programming
This meme again? Professional web dev usually involves coordinating multiple computer systems that are geographically spread out across hundreds of miles and interact in an asynchronous, real-time way, and you can't necessarily rely on getting responses back for requests, and sometimes there are people trying to fuck with your systems. But for some reason there are people who think that writing software for a nice well-controlled sandbox is more hardcore.
Oops, meant to say:
I agree that "this" is a bit of a mess.
>Are you sure programming is a thing for you? Or are you just some corss boarder retard pretending for some (You)s
Not him but aren't you doing the same?
NaN is an absorbing element in math, why is js treating it differently ?
why can't you use bitwise operators on 64 bit integers?
Why do you have to split it yourself? Even fucking C can do this and it is really fast and easy to do.
Why do you think it's wise to treat max_number +1 as max_number but max_number +2 as infinity? It's retarded. Do you have to loop the whole integers range twice to gain the right to be infinity? Explain why it's a good choice.
How is it a good choice to allow semicolon AND no semicolon, at the same time? Pick one and use it forever.
Why do every number is float? ALU is faster than FPU in most cases, justify using float for everything.
Why do you call lambda functions arrow functions when everyone else calls them lambda functions for righteousness sake.
Js was not designed to be this widely used, you weren't suppose to do fucking bitwise operator or laplace transform or whatever complex shit.
Js was suppse to help you write small applets on your website, the legacy burden is just too heavy for it to become good at some point.
rewrite everything from scratch or change techs, we have promising backend stuff in the go, elixir and rust worlds, php7 is coming back for the frontend, I'm sure greedy ads companies can use better tools too.
there is a bright future for the web at a technical level, we should embrace it instead of following the wrong path.
I'm baffled that there are still morons who use nodejs when there's stuff like vert.x out there. But most webdevs are brainlets anyway.
>When you're not worried about your code killing people if it malfunctions
But the type system would simply point out the errors that you would find eventually when the program goes into some edge case and you have no fucking idea why that shit crashed (apart from "got X expected Y").
>you never make any type mistakes in your code, and having a type system would just be bloat
But if you make no mistakes then the type system would not point any errors (no burden on the programmer) and having static types would make your program faster since it wouldn't do runtime type checks - it would actually remove the bloat. Oh, I'm assuming we're talking about a reasonable type system implementation with type inference obviously. Having to explicitly write each obvious type would be indeed annoying.
YES We did it, guys!
>>webdev is not real programming
>This meme again? Professional web dev usually involves coordinating multiple computer systems that are geographically spread out across hundreds of miles and interact in an asynchronous, real-time way, and you can't necessarily rely on getting responses back for requests, and sometimes there are people trying to fuck with your systems. But for some reason there are people who think that writing software for a nice well-controlled sandbox is more hardcore.
>Reading comprehension
Never said webdev isn't programming. And I wouldn't call what you describe webdev work. I mostly point to time consuming problem of checking which browser supports what and having to deal with frameworks like node.js I stand by my argument that any programmer who values sanity tries to get away from that line of work.
pic related
ecma-international.org
isNaN has to convert its argument to a double first before doing anything, also yes you can check for NaN in a very simple way
const isArgNaN = arg !== arg; // true if NaN
Repost because people who delete and repost their reply make the whole thing retarded.
>also there's no fucking way of determining whether a value is NaN
Wrong.
isNaN("asd") // true
Correct way of doing things:
let obj = new Boolean(false);
obj === false // false
The Number issues I think are implementation-based. The spec requires them to have certain parameters, but what happens on edge cases may not be handled in the same way by all engines.
Dunno what issues you have with arrays:
>Also: the arguments pseudo-array not being a "real" array, and being or not being kept in sync with named parameters, depending on how you call the function.
Welp, using the arguments object is kinda old-skool. If you still want to use it, use strict mode and all your sync worries are gone.
Otherwise, get with the times, pops, and use the rest operator:
function fn(...baka){
baka.forEach(v=>console.log(v))
}
>pic
Yeah this person in question doesn't understand floating point numbers. It doesn't belong with the other complaints.
>not using the fastest framework
github.com
>And I wouldn't call what you describe webdev work
Then what would you call it?
Ah, so it's just a floating point issue, not JS. Got it.
But why? You could have multiple threads in context of one process that communicate with each other only with messages (my reference are mailboxes for IPC, some variation sounds doable for threads). They are indeed sharing the process' resources but simply aren't aware of it (because the language doesn't allow appropriate constructs). That seems to fit the definition and sounds like message-passing multithreading. Sorry if I'm just spouting unrelated nonsense, I have no idea how javascript works.
>NaN is an absorbing element in math, why is js treating it differently?
It cannot and it shouldn't, if you notice any behaviour that does not adhere to the IEEE-754 pecification then report it to the correct people.
>why can't you use bitwise operators on 64 bit integers?
>Why do you have to split it yourself? Even fucking C can do this and it is really fast and easy to do.
pic related
>Why do you think it's wise to treat max_number +1 as max_number but max_number +2 as infinity? It's retarded. Do you have to loop the whole integers range twice to gain the right to be infinity? Explain why it's a good choice.
It's how IEEE-754 doubles work, nigger
>How is it a good choice to allow semicolon AND no semicolon, at the same time? Pick one and use it forever.
Like I said, ASI is an error correcting mechanism and reliance on it is officially discouraged github.com
>Why do every number is float? ALU is faster than FPU in most cases, justify using float for everything.
Not floats, doubles. But you also have internally optimized Smi in V8 and BigIntegers now
>Why do you call lambda functions arrow functions when everyone else calls them lambda functions for righteousness sake.
JS popularized anonymous functions to begin with. Be glad other languages copied JS (which copied Scheme)
>Why do you think it's wise to treat max_number +1 as max_number but max_number +2 as infinity?
not user; Pet-peeve of mine. Even if the maximum a 64bit integer could hold is treated as infinite, it would be wrong. Otherwise the equation Infinite+1 = Infinite+2 would hold. This can't be true and therefore mathematics calls this "Undefined" which is not the same as NaN or traditional undefined characteristics.
Doesn't anyone here think how javascript is a tool much bigger than the task most of the time? Sometimes people want just a bit of simple dynamically loaded content (imagine some database where you don't want to load all records in advance) and you need all that javascript machinery. I mean, it's cool that I can go onto some chinese cartoon porn site and manipulate it to align the content so I can fap without triggering my autism but isn't that kinda excessive?
>ALU is faster than FPU
It's not. And that's not why you should decide for one over the other. The historical reason we've simulated floating point is either platform support or speed. But floating point is faster now. It's not by a staggering amount really. Some operations are way faster in FP but nothing that justifies moving unless you could stand to gain from fractions.
>Simplicity
Traditional multithreading isn't necessarily any less simple, especially if you're using a bunch of pre-made constructs. If anything, it can be even simpler, because you don't have to deal with any of the message passing stuff.
Consider something like a connection pool, where a thread can request a connection and the first available one is returned (or a new one created). Your connection objects likely can't be passed as a message to another thread, meaning you'd have to handle all communication in and out of each connection via message passing. Now you've just added a bunch of complication.
Whereas with proper SMT, especially for server stuff where one connection typically gets its own thread, you don't even need to worry about thread safety because any object allocated by a thread will be touched only by that specific thread.
>Having to explicitly write each obvious type would be indeed annoying.
This is what IDEs are for. If IDEs didn't exist, Java would be 100% unusable.
You can certainly implement message passing in a true multithreaded environment. But something geared towards only supporting message passing can hardly be called proper multithreading.
>I mean, it's cool that I can go onto some chinese cartoon porn site and manipulate it to align the content
That's the problem with JS: what you just described was exactly the original intended usage of it. But then it started getting used for more and more shit and nobody can decide on a replacement.
On server side for serving webpages it's better to optimize for single thread and scale by spinning up a new instance on an available thread instead.
Multithreading via message passing might not be convenient but it's hell of a lot more secure than having direct access to another thread's resources.
I'm pretty sure there are libraries out there to make threading easier, but like I said most people focus on multiples of single thread processes.
>On server side for serving webpages it's better to optimize for single thread and scale by spinning up a new instance on an available thread instead.
Which is exactly how most Java frameworks do it. The difference being Java doesn't have a GIL like python so each thread can actually execute simultaneously, and unlike Node it wouldn't need to spin up multiple copies of anything that actually can be shared between threads.
>I'm pretty sure there are libraries out there to make threading easier
There certainly are, but that goes for both styles.
>Java frameworks
Kind of not fair comparing frameworks of all things to vanilla, no batteries included JS, desu
>You can certainly implement message passing in a true multithreaded environment. But something geared towards only supporting message passing can hardly be called proper multithreading.
Why is that? Without additional requirements message passing sounds as good as any other form of multithreading. Note that in this theoretical implementation I would allow sharing of resources that are sent through a message (but would require additional synchronization then - which could be done through message passing as well). Since the threads live in the same address space it would be enough to simply send an address of a resource (and therefore it would seem difficult to prevent the user from it as you would need to prevent the user from sending pointers and from casting things to pointers and back and I don't really know I don't want to think about it too much) but I would try to prevent the user from accessing arbitrary pointers (so they don't access things that weren't explicitly shared).
you can't compare h2o to vertx. two different things
Fair enough.
Let's say you're implementing a server from scratch in Java.
You'd typically create your ServerSocket which is your listening socket, and then accept connections by doing ServerSocket.accept() in a loop to get a Socket for each new connection. Then you spin up a new thread for each Socket.
I use that all the time for when I need a dead simple application-specific Java server and don't want to deal with a big framework.
>Note that in this theoretical implementation I would allow sharing of resources that are sent through a message
But at that point, it's pretty much traditional multithreading. If I say "new Thread(foo.bar(baz))", I've more or less implicitly shared foo and baz.
>but I would try to prevent the user from accessing arbitrary pointers
Java et al don't let you do arbitrary pointers anyway, so it's moot for anything that's not C-like. If you didn't specifically pass that stuff to the other thread, it's not going to be able to find it, unless it's accessible by some static method/field on a class somewhere (in which case it really should be threadsafe).