Our great sponsors
-
crux
Discontinued General purpose bitemporal database for SQL, Datalog & graph queries. Backed by @juxt [Moved to: https://github.com/xtdb/xtdb]
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
mnm
mnm implements TMTP protocol. Let Internet sites message members directly, instead of unreliable, insecure email. Contributors welcome! (Server)
-
-
psarm
Discontinued PSArm is a PowerShell module that provides a PowerShell-embedded domain-specific language (DSL) for Azure Resource Manager (ARM) templates
I work on Crux so can share a few details about our implementation of Datalog. The query is compiled into a kind of Worst-Case Optimal Join algorithm [0] which means that certain types of queries (e.g. cyclic graph-analytical queries, like counting triangles) are generally more efficient than what is possible with a non-WCOJ query execution strategy. However, the potency of this approach relies on the query planner calculating a good ordering of variables for the join order, and this is a hard problem in itself.
Crux is usually very competent at selecting a sensible variable ordering but when it makes a bad choice your query will take an unnecessary performance hit. The workaround for these situations is to break your query into smaller queries (since we don't wish to support any kind of hinting). Over the longer term we will be continuing to build more intelligent heuristics that make use of advanced population statistics. For instance we are about to merge a PR that uses HyperLogLog to inform attribute selectivity: https://github.com/juxt/crux/pull/1472
[0] https://cs.stanford.edu/people/chrismre/papers/paper49.Ngo.p...
Thanks for the thoughtful response! Many of these are totally legitimate: in particular, we're making steady progress to centralize module design, release, documentation, and modernization, or at least to bring many teams closer together. In many cases, we're at a transition point between moving from traditional PS remoting modules and filling out PS coverage for newer OAuth / REST API flows.
I don't know how recently you've tried PS7, but the back-compat (particularly on Windows) is much, much better[1]. And for those places where compatibility isn't there yet, if you're running on Windows, you can just `Import-Module -UseWindowsPowerShell FooModule` and it'll secretly load out-of-proc in Windows PS.
Unfortunately, the .NET problems are outside my area. I'm definitely not the expert, but I believe many of the decisions around the default assembly load context are integral to the refactoring of .NET Core/5+. We are looking into building a generalized assembly load context that allows for "module isolation", and I'd love to get a sense in the issue tracking that[2] whether or not fixing that would help solve some of the difficulties you're having in building modules.
For Azure, you should check out the PSArm[3] module that we just started shipping experimentally. It's basically a PS DSL around ARM templates, as someone who uses PS and writes the Azure JSON, you sound like the ideal target for it.
As for the help content, that's a very funny story for another time :D
[1]: https://aka.ms/psmodulecompat
[2]: https://github.com/PowerShell/PowerShell/issues/2083
[3]: https://github.com/powershell/psarm
https://ipfs.io/ seems pretty cool. I've been meaning to check it out, but not seen any uptake yet.
The GET (Guaranteed Entrance Token) Protocol https://get-protocol.io/
The protocol offers blockchain-based smart ticketing which elements fraud and prevents scalping. This has the potential to get huge when events start coming back post-covid.
Take a look at haxe[0] for a compile-to-js ML inspired language. It's relatively mature these days and integrates with existing typescript definitions via dts2hx[1]
I talk about this more here: https://news.ycombinator.com/item?id=26084187
[0] https://haxe.org/
[1] https://github.com/haxiomic/dts2hx
https://github.com/samsquire/additive-guis
Materialize (https://materialize.com/). Although a bit known here, my coworkers never heard about it. I think it's going to be a game changer.
TMTP, "a sane network protocol for email, to end attacks and promote productivity."
https://mnmnotmail.org/
https://twitter.com/mnmnotmail
Amen. We need to walk back from convoluded and bloated software to the era when every software was simple. https://collapseos.org
In a similar vein, Fable (an F#-to-JS compiler) is gaining a lot of momentum in the F# community. https://fable.io/
https://github.com/chakravala/Grassmann.jl
In the future, geometric algebra will likely be part of everything we do, but it is still very unknown as of now.
Thanks for the thoughtful response! Many of these are totally legitimate: in particular, we're making steady progress to centralize module design, release, documentation, and modernization, or at least to bring many teams closer together. In many cases, we're at a transition point between moving from traditional PS remoting modules and filling out PS coverage for newer OAuth / REST API flows.
I don't know how recently you've tried PS7, but the back-compat (particularly on Windows) is much, much better[1]. And for those places where compatibility isn't there yet, if you're running on Windows, you can just `Import-Module -UseWindowsPowerShell FooModule` and it'll secretly load out-of-proc in Windows PS.
Unfortunately, the .NET problems are outside my area. I'm definitely not the expert, but I believe many of the decisions around the default assembly load context are integral to the refactoring of .NET Core/5+. We are looking into building a generalized assembly load context that allows for "module isolation", and I'd love to get a sense in the issue tracking that[2] whether or not fixing that would help solve some of the difficulties you're having in building modules.
For Azure, you should check out the PSArm[3] module that we just started shipping experimentally. It's basically a PS DSL around ARM templates, as someone who uses PS and writes the Azure JSON, you sound like the ideal target for it.
As for the help content, that's a very funny story for another time :D
[1]: https://aka.ms/psmodulecompat
[2]: https://github.com/PowerShell/PowerShell/issues/2083
[3]: https://github.com/powershell/psarm