HN user
Great to see this moving forward.
It does seem a bit of a mixed message to enable this by default while still saying the functionality is experimental. I fear many people will take this as a signal to start using the feature in production, then find a later Node.js update breaks things if the behaviour changes.
The approach taken to this problem by Cats Effect (a Scala concurrency library) is interesting. It allows cancellation of a fiber from outside, but let's blocks of code be marked as uncancelable. If a fiber is cancelled while executing one of these blocks, it will complete the block before cancelling. This protects against cancellation in between two operations which leaves the program in a broken state.
The drawback of this approach is that the onus is on anybody writing code which might be cancelled to correctly mark the uncancelable regions.
As long as they don't make them mutable!
Nice to see some Scala content on HN.
Hope he finishes the book.
Here a common example:
Given the following tables:
CREATE TABLE person (
id INT PRIMARY KEY,
name VARCHAR NOT NULL
);
CREATE TABLE pet (
id INT PRIMARY KEY,
name VARCHAR NOT NULL,
owner_id INT NOT NULL
);
SELECT owner.id, owner.name, COUNT(pet.id) AS numberOfPets
FROM person AS owner
LEFT OUTER JOIN pet ON owner.id = pet.owner_id
GROUP BY owner.id
We can solve this with ANY_VALUE:
SELECT owner.id, ANY_VALUE(owner.name) AS name, COUNT(pet.id) AS numberOfPets
FROM person AS owner
LEFT OUTER JOIN pet ON owner.id = pet.owner_id
GROUP BY owner.idYouth culture is alive and well.
And as for music subcultures, I'm a fan of several genres which have distinctive fashions, art styles and world views - rave, psytrance, drum and bass, hardcore punk, metal. It's great to go along to gigs and meet people from those different groups.
I think what has changed is that those subcultures are no longer exclusive to young people. It has become more acceptable for people to be outwardly "alternative" later in life, so people remain in the cultures they found when they were young.
I'm glad people are working on this problem. Typescript's compiler performance is certainly a weakness.
Other commenters have rightly called out the complexity of the type system as the reason why this is difficult. The other reason is that Typescript does not have a formal specification. The tsc compiler is the only reference for the correct behaviour. It would be great if the official compiler and these reimplementations could share a common test suite to ensure compatibility.
Interesting. I'm not aware of any other lazy dynamic languages. I would assume it is difficult to optimise such a combination.
Having a good knowledge of HTTP is useful in many different contexts.
- The correct semantics for each HTTP method
- What different status codes indicate
- Common headers, particularly around caching
- HTTP 1.1 vs HTTP 2
- Common authentication protocols - OAuth 2.0, JWTs, etc.
The important thing is that it separates the order of side-effects from the order of evaluation of expressions. This isn't a particularly important distinction in an imperative language, but in a functional language when you introduce things like laziness and memoization, the order in which expressions will be evaluated is not obvious.
Because pure I/O preserves referential transparency, it gives the compiler far more ability the optimize the code by changing how, when and whether things are evaluated, while still being able to prove that it has not modified the external behaviour of the program.
Haskell doesn't use pure I/O out of zealotry - without it, Haskell couldn't and be lazy-by-default and the compiled code would probably be much slower.
There are a lot of interesting possibilities with template literal types. I've discussed some of them here:
https://davidtimms.github.io/programming-languages/typescrip...
This sounds similar to how Cloudflare Workers work - using the V8 isolate technology built for Chrome to provide secure isolation of backend processes without the overhead of VMs or even containers.
If you're looking to create a dynamic language with reasonable performance, you could look at implementing it with RPython [1], which is used for PyPy, or for the Parrot VM [2], which is used for Perl 6.
Once it becomes a little more mature, Zeta VM [3] may also be a good target.
I'm really not a fan of the function bind operator. It adds extra complexity to the meaning of "this" in JS, which is already one of the most confusing aspects of the language.
I do understand that it is nice to be able to write those chained method call pipelines, without having to monkey patch anything. I think the |> operator from Elixer is a much simpler solution to this problem through, as it allows you to use normal functions, rather than having to write special versions that use 'this' for their primary data.
What features would a type system require to be able to soundly type check 100% of the patterns that are found in dynamically typed programs? Dependent types? Refinement types? Is it possible?
After having used this operator in Elixir and Elm, I would love to see it in JS. I know it seems like a superficial issue, but I think the left-to-right chaining flow is one of the main things people miss as they move from an OO style to a more functional one.
This is exactly the response to this tragedy that I was fearing in the UK. What the article fails to mention is that France passed their own sweeping surveillance law earlier this year [1], and it clearly failed to stop this attack from happening. That isn't to say that increased surveillance never aids in intercepting terrorism, but to sell it as a golden bullet is highly disingenuous. Now is precisely the wrong time to be making rash decisions and passing reactionary legislation which will have serious ramifications for privacy and cyber-security for years to come.
[1] http://www.theguardian.com/world/2015/may/05/france-passes-n...
I really hope immutable collections get added to the standard library eventually (probably ES2017 at this rate). Proxies should allow them to be used with libraries which expect mutable objects and arrays, as long as they don't mutate them.
Having them built in to the language would open up some interesting new possibilities too. It should be possible to send immutable data between Worker threads without the overhead of serialization and deserialization, which is currently one of the main barriers to doing heavy computation in a web worker rather than on the UI thread. Of course, there would be some nasty internal implementation details to sort out, as it would require sharing heaps, but it should be possible.
This looks fantastic. Python always feels like it's almost as good as a dynamic, imperative language could get, but I miss some of the functional idioms from other languages. It's great that this is just a thin layer over Python too, so it can hook into the ecosystem, and it's a realistically sized project for a single developer to maintain.
This is something which really excites me about Rust. Having constructs as fundamental as function application extensible via traits reminds me of Python's magic methods, but without the runtime overhead.
Haskell and Clojure both use structure-sharing data structures, which allow immutability without the cost of copying the entire structure whenever you want to make an update. They also use laziness to improve the performance of their data structures.
If you want an implementation of these ideas in JS, Immutable.js [0] or Mori [1] are the leading libraries. seamless-immutable doesn't use these techniques, so it probably wouldn't perform well on large data sets. The benefit of it is that the immutable objects can be used as drop-in replacements for their native JS equivalents in some situations.
Full disclosure: I've contributed to Immutable.js
From what I can see, seamless-immutable basically just enforces immutability on native JavaScript data structures. Immutable.js on the other hand, implements full persistent data structures, which give much better time complexity guarantees about important operations. Immutable.js also has a rich API designed for manipulating immutable data structures and uses lazy evaluation for methods like map, filter and concat, which really improves performance when chaining chose operations.
It appears the author has already answered my question:
http://www.nczonline.net/blog/2014/04/22/creating-defensive-...
Can't the exception throwing on missing property behaviour be created using ES6 proxies?
Anyway, while many of these things would be nice additions, I think ES7 will contain more low-level features which particularly benefit libraries and compile-to-js languages, such as SIMD support and value objects. Personally, I'd love to see tail call elimination in the spec.
very nice, although the text shadow on the code makes it a bit hard to read