329 karma · joined April 1, 2017
Tesla Trailing P/E: 390.70 Apple Trailing P/E: 34.11 Ford Trailing P/E : 11.74
He doesn't provide any data to reflect what society's expectations are. Those are just his thoughts.
That's a big distinction.
Over time, I have reflected and shifted this perspective. That reflection centered around the question the author hasn’t asked himself yet: who creates these expectations? It’s always some loose definition like “society” or “elite”, or some other handy wavy grouping of people.
But, to be clear, those expectations are coming from the author. That’s his perspective of what the world thinks, based on his interactions, based on what he chooses to read, listen to, etc. He's not describing anyone but himself.
I found that if I find myself projecting onto social norms, society, or some other loose definition of “they”, what I’m really doing is projecting a part of myself that I haven’t been honest about yet.
My opinion is that Dart's type system is the optimal type system. It allows for statically typed API surface, but at the same time, I can still add some dynamic voodoo under the surface and enable productive meta-programming.
The main isolate creates an Application instance that has N number of supervisors, one for each isolate. The isolates are launched and go thru their initialization steps, reporting back to their supervisor. The application completes its launch once all supervisors have reported back. It fails its launch if an isolate throws an error during initialization or does not hear back in a configurable timeout. Any inter-isolate messages sent during startup are queued until all isolates have completed startup.
Once the isolates are up and running, the main isolate doesn't do anything other than facilitate the inter-isolate message hub. Requests are delivered directly to the isolates running the web server.
When running automated tests, the default behavior is to run everything on the main isolate, since tests are run against a temporary database schema that only exists for the lifetime of the connection.
router.route("/*").pipe(new HTTPFileController("web/");
router.route("/files/*").pipe(new HTTPFileController("something_else/");
An HTTP request for /files/xyz.jpg returns the something_else/xyz.jpg.
If the HTTP path is a directory, then index.html is automatically appended to it. This is a brief overview of the referenced documentation above.
The memory consumption of an isolate depends on the size of the application code. Each isolate actually has its own copy of the application code that gets tuned by the VM over time. Even stuff like static variables are per-isolate. I just pulled up an OK sized Aqueduct project, and it looks like about 30-40MB per isolate. Most of that is probably Aqueduct itself. A worker isolate is likely an order of magnitude smaller.
1: https://webdev.dartlang.org/articles/performance/event-loop
Async/await is implemented really well (Google hired Erik Meijer to help them build it), their threading model is excellent, and there are built-in keywords in the language for stream handling that are seriously productive [1]. Anyone that knows Java/Swift/Kotlin/ObjC is going to be productive in Dart very, very quickly.
Performance has been great, but someone else may be better qualified to answer that question. Much of the lower level socket stuff is just C/C++. I don't want to speak on something I don't fully understand, so I included an article about the Dart VM below [2].
To me, Dart differentiated itself by being more similar to compiled, C-like languages. Obviously, Django, Laravel, Rails, etc. are much more mature. Aqueduct is tested well [3], but nothing beats years of regression tests.
1: https://www.dartlang.org/articles/language/beyond-async 2: https://www.dartlang.org/articles/dart-vm/why-not-bytecode 3: https://github.com/stablekernel/aqueduct
The changelog [1] always has a few entries for the Dart VM with each version, but it's quite clear from using it daily that much more is happening. Some notable recent improvements have been asynchronous breakpoints that are integrated in IntelliJ's debugger and some optimizations for sending messages across isolates.
1: https://github.com/dart-lang/sdk/blob/master/CHANGELOG.md
Yes, multi-threading is accomplished through isolates. The application is run as a replica on a number of isolates, configurable by a command line option.
Each isolate has its own database connection, etc., but operate exactly the same. This behavior doesn't require any additional effort by the developer. (edit: The initialization code sets up a reactive channel for requests, each isolate instantiates that channel, and Dart's VM manages delivering an HTTP request to the most appropriate isolate.)
So, it's not quite like Erlang/Elixir where each connection gets its own process, rather the default number of isolates is 3. Isolates have their own heap, so memory isn't shared across them, but there is a message hub that isolates can send values across. This is useful when say you have websockets connected to different isolates and you want to broadcast a message to all of them.
You can spawn additional isolates from a 'web server isolate' to move computation to another thread.