Change.org solicits donations under George Floyd petition, keeps money - <AUTHOR> https://www.businessinsider.com/change-org-george-floyd-donations-petition-keeps-money-2020-6 <comment><USER2> There's a trade off from being quick to donate to any apparently righteous cause vs. being analytical. On one hand a quick donator is viewed as very generous and empathetic. On the other hand they can be easily fooled. A slow donator is seen as colder and less empathetic, however, they tend to get more good done over time.

</comment><comment><USER3> I've always found the change.org donation solicitation a bit shady (you're essentially paying for an ad on the site for the petition), but I have no idea how the donators reached for comment could not know what the donation is. It says very clearly you're "Chipping in" to get the petition noticed more. If they're confused on that I don't know how.

</comment><comment><USER4> Change.org is just an email harvester.

</comment><comment><USER5> Mods: the title of this submission ("Change.org solicits donations under George Floyd petition, keeps money") is a blatant case of editorializing, in violation of HN guidelines.

<comment><AUTHOR> I had copied the title from the article at the time of posting, that's literally the title if you search Google:

[https://i.imgur.com/Xwheqan.png](https://i.imgur.com/Xwheqan.png)

<comment><USER5> Ah, well, I guess business insider is to blame then. The way this title is written initially gave me the very strong impression that change.org has deceived people by pretending to collect donations for one purpose and then keeping them for itself. But in reality the story is people are so dumb they will click to donate $3 without paying any attention to a sentence or two describing what the donation is for -- and then get mad when they find out later.

<comment><AUTHOR> I don't think people are dumb, the language is clearly structured so that it is ambiguous to take advantage of people who care about a cause.</comment></comment></comment></comment>


Electron 7.0 - <AUTHOR> https://electronjs.org/blog/electron-7-0 <comment><USER3> I'm bullish on Electron. I think it's just a couple of technical advancements away from being the ultimate desktop toolkit.

For context, I love and have worked a ton with Qt, and I much prefer Qt UIs as a user. But Electron has brought true cross-platform development to _all_ platforms (Including Linux!). If it weren't for Electron, I wouldn't even have a bunch of the apps I use today. Hell, I wouldn't have a good IDE, and I don't think I'd be as good in Typescript had I not been a day-1 VS Code user.

I think the main thing preventing it from "feeling" good to most users is the most common complaint on HN about how each individual app is its own version of Chrome. This sucks; it's heavy, it's laggy, and users feel it even instinctively.

OSes and frameworks have tried to solve this a bazillion ways. Edge WebView, Android WebView, Qt WebView, QtWebkit, whatever the iexplore stuff was in XP, …. Electron might have the opportunity to actually solve this.

If it does, honestly, to hell with anything else. I'm sure over time the web world will gravitate towards a fairly common set of widgets that will, at one point or another be standardized. We'll reinvent UI frameworks under a different name, except this time they'll be running under the ultimate cross- platform framework.

<comment><USER4> I release two apps, across 3 OSes, in somewhat of a bimonthly cadence with a low defect rate. That's 6 different binaries. I'm a solo founder.

I know people like to rag on Electron, but without it, I wouldn't be using something else, my apps just _wouldn't exist_. It allows more people to try building more thing and that is a net positive.

The speed problems and bloat issues of Electron is just shoddy programming on the maker's part - Electron itself isn't slow. I use it largely as a shell talking to a Go binary that ships within the app package, which makes it only tasked with UI. If you're having issues with speed, it's a good approach.

A real world example of this approach is the thing I work on at [https://aether.app](https://aether.app). (An async collaboration tool for engineers)

<comment><USER5> For me, and probably others, the main issue with Electron isn't the speed or even resource usage. It's that it ignores common UX/UI conventions you expect from a native app which still makes me prefer native macOS apps.

<comment><USER6> I think this peaked some time around 2015. Back then, I remember many developers getting up in arms about following Apple's guidelines to a T, or insisting that Android apps look like a hyperactive stack of colorful paper cutouts under a direct light.

Since then, I think many of us have gotten tired of looking at overdesigned sameness that by now we all know will age quickly. Programmers no longer see the sense in chasing a perpetually changing visual standard for no reason other than "BigCo said so". Most importantly though, BigCos in question have fallen out of our good graces, and the "Design Systems" they keep pushing are now regarded as nothing but cynical branding exercises that come at the cost of UX.

<comment><USER7> You are right but at the same time I am willing to bet you 5 years later someone else will make the opposite argument and be upvoted the same.

It's a pendulum.

<comment><USER8> I'd bet on the next UI standard being a cross-platform library. Electron-like, but with much more efficient stack, and with binding to multiple languages.

<comment><USER6> I'd bet on "if you can't beat em', join em". Reactive component-based architectures a la React/Vue have won. The DOM has won for the view layer too. And with wasm, you get your bindings to multiple languages. See: Blazor (it's just the first, more are coming). As for desktop apps that could benefit from proper concurrency, lack of a browser sandbox, full system access, etc. - server side Blazor is quietly pioneering a weird new paradigm - <USER2> running a headless browser in a regular process with full privileges, and then only doing vdom diffing inside the browser.

<comment><USER8> > The DOM has won for the view layer too

As a front-end dev, I'm not entirely sure I agree with that. The DOM has some annoying performance limitations, and I'd love to be able to use something better for rendering. I think what the DOM has shown, is that cross-platform and the ability to easily do custom look and feel are crucial.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Every time Electron is mentioned I bust out the popcorn for the inevitable hate spewed towards it:

"Javascript is a terrible language and no one should use it"

"Separate instances of chrome for every app is dumb and consumes too much memory"

"Qt is amazing and elegant and desktop-native. Why isn't everyone just using Qt?"

<comment><USER10> > "Separate instances of chrome for every app is dumb and consumes too much > memory"

That one is true though. Different Electron apps could at least share the runtime.

<comment><USER11> Except they cannot, Chromium (or is it Blink?) changes too frequently to reliably code for one version and expect backward compatibility of future releases. Electron versions could be shared libraries... except again BC breaking releases proliferate.

<comment><USER12> Why can't it be based of Chrome's version number? If you know the version number at the time of release then you can say only use the same runtime if there's only a revision version difference, else you can use it's own run time. That packaged with auto-updates for the app to that developers can push updated builds every month or so should be fine.

</comment></comment></comment></comment><comment><USER13> Since this is inevitably going to generate some discussion over native apps vs. Electron (ah there's already a fellow comment about it), I'd like to point out an example that is important to me of why Electron is an inferior experience for users:

In the GitHub Desktop client, which is an Electron app, I can't spell check my commit messages, something that every text field in every native macOS app gets for free.

<comment><USER14> Web text fields should also support that functionality, so it may be a question of GitHub breaking/disabling it in some way.

<comment><USER13> You're right; I just tested it in Discord, which does have a spell checker, and it _seems_ to use the system dictionary (but it seems one way when teaching it new words), but it's still missing other global text field functionality: [https://i.imgur.com/qpOU9dz.png](https://i.imgur.com/qpOU9dz.png)

The point remains: Electron apps generally lose many of the features that the host OS gives native apps for free.

<comment><USER14> But the native web, used properly, includes many of them itself. Things like accessibility, metadata, etc. You only really lose features if you're circumventing native web functionality.

<comment><USER15> The problem is that the developers of Electron apps explicitly disable those features. Why?

<comment><USER14> Sometimes web developers will circumvent core HTML features because they don't do everything they want and aren't extensible enough, although this is generally considered bad practice if it's at all avoidable. Sometimes they just don't bother to write semantic HTML even when they could. But the platform itself has the infrastructure; it's possible to write bad software on any platform.

</comment></comment></comment></comment></comment></comment><comment><USER16> Hey, another electron thread. Wait a second, did someone already mention how horrible Javascript is? The memory consumption? The minimal integration into the OS/desktop (think accessibility)? Hmm ok, I need something new...

Here it comes: chrome is inherently instable. The Google developers give a shit about their dependency management and have trillions of open source projects just literally copied into their trunk. They also don't provide any API to speak of, chromium as a library does not exist, and don't get me started about the arcane build process of chrome.

<comment><USER17> Disclaimer: Electron dev

So few quick things, the projects that are copied are done so to guarantee deterministic builds in an isolated build environment (no dependencies on third party systems).

The API you say they don't provide is literally the API that Electron uses. --> [https://chromium.googlesource.com/chromium/src/+/HEAD/conten...](https://chromium.googlesource.com/chromium/src/+/HEAD/content/public/README.md)

And as for the build process, eh, it's kinda slow but it's hardly arcane. On linux you can run like 4 commands and it'll build Chromeium.

<comment><USER16> Yeah. Four commands. The first one downloads binaries from the internet. If I was inclined to do so, I would not need to build in the first place ;).

Give it a try with the current HEAD of their home-grown and undocumented build tool and see how far you get.

And regarding the deterministic builds: I call bullshit. They just don't want to follow the different packaging guidelines from the different operating systems, so they repackage everything. Now I have to trust them to keep all these dependencies up-to-date _and_ I have to accept the unecessary bloat? No way.

<comment><USER18> > [build process]

I agree, the chromium build tooling is unfriendly af.

> I call bullshit

Lot of works goes into deterministic builds, have fun going down this rabbit hole: [https://bugs.chromium.org/p/chromium/issues/detail?id=314403](https://bugs.chromium.org/p/chromium/issues/detail?id=314403)

> Now I have to trust them to keep all these dependencies up-to-date

Looks like it rolls on average every 10-20 minutes: [https://chromium.googlesource.com/chromium/src/+log/HEAD/DEP...](https://chromium.googlesource.com/chromium/src/+log/HEAD/DEPS)

> and I have to accept the unecessary bloat?

Ah yes, because all operating systems ship with a pristine installation of the latest pdfium.

<comment><USER16> > Lot of works goes into deterministic builds

That has _nothing_ to do with their dependency management. In fact, if you link against system libraries, it should be simpler to get deterministic builds, as you have to build less.

</comment></comment></comment></comment></comment><comment><USER19> A lot of the bloat complaints about Electron are addressed well in Sciter ([https://sciter.com/](https://sciter.com/)) although, Sciter has its own set of limitations. I have found Sciter a great option for many use cases. (I'm not affiliated with Sciter in any way).

<comment><USER20> Sciter and Ultralight are the way to go on paper. They address many of the issues of Electron and it does it in a very portable way. Instead of embedding the world in a giant toolkit, they give to you what you want as a library, easy to interface with native code.

However they are proprietary, and this is a no go for me and many. There is no way I bind my software stack to an arbitrary unstable compiler ABI and its platforms. Nor I will bet on a toolkit that can disappear tomorrow if its only maintainer disappears or get hit by a bus.

We need something like these projects, but OSS and still I would be happy to pay for that.

<comment><USER19> Ohh, never heard of Ultralight. Will check it out, thanks! I agree that licensing makes these products an issue for some, but they both seem to offer a very flexible free use option...

</comment></comment></comment><comment><USER21> There's hate directed at performance, but Electron apps are just _profoundly buggy_.

For example in Slack:

1\. Non-functional items are routinely offered in the main menu and context menu.

2\. The Undo and Redo menu items often just don't work. These do different things than the command key equivalents which should never happen.

3\. It is easy to get into a state with multiple blinking insertion points.

4\. The inactive appearance is identical to the active appearance.

etc etc.

<comment><USER3> None of these are innate to Electron. It's kinda like saying "Windows apps are just profoundly buggy", or "Telephone calls are just profoundly boring".

</comment></comment><comment><USER22> Wait ... let me see if I can anticipate the top comment

"Electron consumes so many resources ... Why so resource hungry ... My workstation already runs Chrome, can't have electron apps bogging it down ... Slack runs on Electron ... VSCode is the only good Electron app ... Why are we doing this ... Dennis Ritchie would be turning in his grave"

This topic could honestly trigger the "parse regex with html" kind of reply.

<comment><USER23> Well, Slack _is_ currently taking almost 3 GB of memory on my machine. Not entirely sure if that's due to Electron or Slack, but I have never found an Electron app that didn't consume vast swathes of memory.

[https://imgur.com/GscRFD7.png](https://imgur.com/GscRFD7.png)

<comment><USER24> It is not because of Electron.

An empty Atom window containing 5 source code files consumes about 120MB of RAM. For comparison with native apps, an empty iTerm2 window uses 100MB, and so does an empty Notes.app window. The base memory footprint imposed by Chromium is not that significant.

<comment><USER23> On my machine, an empty Atom instance is using about 400 MB: [https://imgur.com/S1POSPz.jpg](https://imgur.com/S1POSPz.jpg)

<comment><USER24> Do you have some packages installed? If so, can you re-run with `atom --safe`?

Granted, it is totally normal to have packages when using Atom, but their memory cost shouldn't be considered a penalty that you pay due to Electron. Rather, it's a penalty that you pay if you want an extensible application in which extensions are allowed to use JavaScript.

<comment><USER23> I have no custom packages installed - I use atom just to take notes and do small text editing.

When I run `atom --safe` it starts at around the same amount of memory usage: [https://imgur.com/j4Co4n6.png](https://imgur.com/j4Co4n6.png)

Side note: Running that command is now preventing my from quitting Atom using the Atom > Quit menu entry. I had to force quit it to get it to close.

</comment></comment></comment></comment></comment></comment><comment><USER25> Is there a good introduction to starting development with Electron as someone who is a C++ developer? I find web development quite difficult to grok in general; lots of frameworks and technologies.

<comment><USER26> Quelle horreur - clearly web tech is the future of UI, and electron is a reasonable choice until a better solution comes along, but the ecosystem is a foul mess for developers. `npm [anything]` fills your hard drive with an astronomical tangle of hideous code. And there's webpack. You will end up wanting to strangle yourself. Avoid unless you really need it.

<comment><USER27> I'm normally a backend developer but I was fooling around with using vue.js + jquery to build a simple SPA without the typical process of npm install <entire world>.

When it came time to finally bundle my app into a single html + js file I settled on (well was forced to really) npm install rollup. After installing rollup, I had a package-lock.json file that was 1880 lines long with approximately 150 or so dependencies and a node_modules directory so huge that vscode choked trying to parse everything in it. To its credit, vscode asked me if I wanted to exclude node_modules from future consideration.

All that from installing a single tool via npm. I just don't get modern web development.

</comment></comment></comment><comment><USER28> I love HTML/JS as a desktop UI toolkit, but much prefer the approach Qt WebView approach where javascript callbacks hook directly to code as opposed to running an entire webserver/HTTP stack. If not for the performance, for the ability to skip the sort of security problems the Signal desktop app had run into at some point.

</comment><comment><USER29> Does anyone know why they chose Node.js 12.8.1 instead of 12.13.0, the first LTS release on the 12.x line?

</comment><comment><USER30> Is there ongoing work to reduce the memory footprint of Electron apps? I'm genuinely curious.

<comment><USER31> Yes - WebAssembly. It would hopefully kill the whole thing as an end game.

<comment><USER30> I have a, probably misguided, fear that We Assembly will inadvertently usher in an era of read only web, basically breaking the "view source" idea almost unique to the Web.

<comment><USER32> I hate to break it to you, but minification has broken this idea for years already.

</comment></comment></comment></comment><comment><USER33> Electron 4 is end of life so that means many native node modules need a ton of rework to support node 10+. This is a pain point for electron app devs that rely on native modules for functionality. Time to roll up my C++ sleeves and spend weeks adding zero new features ... just trying to get my apps to build. Ugh. Any native node module gurus for hire? Totally serious here. App is [https://label.live](https://label.live)

</comment><comment><USER34> I dig Electron, and had always assumed by now we would have a multi-OS CSS toolkit for "native looking" styles. I remember [http://photonkit.com](http://photonkit.com) from back in the day, but I think there is room for something more comprehensive.

</comment><comment><USER35> Duplicate: [https://news.ycombinator.com/item?id=21338362](https://news.ycombinator.com/item?id=21338362)

</comment><comment><USER36> Electron (and also nw.js) are nice. But remember that when using a Electron app you are no longer sandboxed.

</comment><comment><USER37> As in every election threads, people will say "duh each electron has it's own instance of chromium" While you can trivially use solutions such as [https://github.com/sentialx/electron- global](https://github.com/sentialx/electron-global) To fixe the issue. Moreover, Carlo solve this too. Ionic and Cordova (the electrons of the smartphones) already use locally installed browser.</comment>


Show HN: MongoDB + open source e-commerce = Forward - <AUTHOR> http://getfwd.com

<comment><USER2> This is incredibly cool. The template syntax you have going is awesome. Reminds me of the natural language of haml/ruby with the handy pipe filter stuff of django/jinja. I _can't stand_ mustache and handlebars.

The UI is great, it's responsive, and well thought out.

Also, the data modeling issue is a great selling point. Right now, MOST all applications are the same. Take this data, validate the person sending you the data is correct, validate the data is correct, and store it. Then apply the same methodology to fetching it, modifying it, or deleting it. I've been a django/python guy for years but after recently diving into Rails, I don't think anyone has done this any better. You can very quickly get things moving in CRUD/REST without much code.

That being said, it all comes back to the modeling. Modeling is relatively simple in Rails. The ORM you get with Django _far exceeds_ ActiveRecord in usability but either way, at some point, a developer needs to sit down and define the data modeling. I realize you're marking this to developers (obviously) but I feel like with your cool UI and mongodb backing, you might even be able to expand this to administrators of the service.

Meaning, I can deliver a pre-configured product to my clients but if they want to add some fields to a product that are searchable/sortable/validatable/etc... they won't need to wait for me to do it. They won't need to wait for me to deploy it. I won't need to run a migration script.

Modern REST frameworks typically work based on a separation of a model and a resource. The model handles data storage and representation, and the resource handles serving it up, controlling access, etc... I think we need to couple these together. One unified object. I can create something, like a `Product`, give it some properties, set validations and permissions for those properties, and boom. Done.

Things like this and Meteor are shining examples of the radical change that we need in this current era of development. Yes, you guys will find faults in that statement. The neckbeards will come out and tell me mongodb does not scale, or node.js async development does not make sense. That is not the point. The point is that we're really not making it much easier on ourselves to build the things we want. Right now it makes more sense for me to pay Parse to handle an iOS back-end. Why? Because for the most part building it is a pain in the ass.

It doesn't need to be. I'm excited about Forward, very excited.

<comment><USER3> _I can't stand mustache and handlebars._

Why do you dislike them?

Separation of design and code seems pretty important, so having a template system that's really a (more or less limited) programming language of its own seems like a step backward to me.

<comment><USER2> Honestly the django/jinja syntax and library of helpers/filters is virtually impossible to beat.

        ### Example User

        user: {
          name: "Michael",
          bio: "The quick brown fox jumped over the lazy dog.",
          products: [<Product>, <Product>, ... ]
          joined: "09-07-12"
        }

        {% for user in users %}

            {{ user.name }}
            {{ user.bio|truncatewords:3 }}
            {{ user.products.count }} Product{{ user.products.count|pluralize }}
            {{ user.joined|date:"M jS, Y" }}

        {% endfor %}

        ### Would Display

          Michael
          The quick brown ...
          2 Products
          September 7th, 2012

<comment><AUTHOR> Here's what this would look like in Forward:

        {foreach "/accounts"|get as $user}

            {$user.name}
            {$user.bio|truncate:30}
            {pluralize "{$user.products.count} Products"}
            {"M jS, Y"|date:$user.date_created}

        {/foreach}

<comment><AUTHOR> Re: API endpoint, that's exactly it.

Here are several equivalent ways of expressing this:

        // PHP
        $accounts = get("/accounts");

        // Template
        {get $accounts from "/accounts"}
        {$accounts = get("/accounts")}
        {$accounts = "/accounts"|get}

Here's a really cool side effect of the way the model result works...

        {$account = "/accounts/123"|get}

        {put [role => "admin"] in $account}

When converted to a string, they represent a model URI.

<comment><USER4>
        {put [role => "admin"] in $account}

Does this mean you have all your view logic inside the templates?

<comment><AUTHOR> Generally logic that is good in a controller can be put in the template file instead. This idea came from the "Smart model, Dumb controller" concept. We made controllers so dumb, it was rather clean and easy to understand when combined with a template. We see more of this with client side frameworks like Meteor.

Still, Forward is built on a new micro MVC framework and controllers do still exist. Those that prefer to write them can do so in a more traditional way.

        class AccountController extends Controller
        {
            function index ()
            {
                $this->account = get("/accounts/123");

                put($this->account, [role => "admin"]);
            }
        }

(This is not very useful code but you get the idea)

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> We desperately need something like this. I just finished a large ecommerce project built on another open source system and it was so incredibly difficult to customize anything. It was more or less "do it the way we have in the template or you're in for a nightmare", and with the client and design specs asking for custom things, a nightmare was what ensued.

Ecommerce is super complex and it will be a really difficult mission to make this really work and be flexible without getting bloated. But if it can happen, this will be a game changing project. My full support is there, and I'll see if I can contribute as well if I have time : )

<comment><AUTHOR> Thanks for your support and encouragement, much appreciated!

Also, what you describe is exactly what Forward aims to fix. Custom features were needed for every single e-commerce site we've built, so we thought it made sense to focus primarily on this workflow.

<comment><USER6> I tried to build this years back and made a complete mess of it.

On the other hand, I still believe it can be done and I think the approach you're taking is one of the ones with a decent chance of succeeding.

Good luck; I'll be keeping an eye out for clever ideas to steal as you move forwards :)

<comment><AUTHOR> I made a mess of it also the first couple tries, but ideas came together much easier this time. You're free and welcome to build on our experience, excited to see and help other people that want to.

</comment></comment></comment></comment><comment><AUTHOR> MongoDB makes deleting records easier. Forward has a trash can:

        {get $order from "/orders/123"}

        {put $order in "/trash"}

Now the order is no longer in the "orders" collection in MongoDB, instead it's in the "trash" collection. You can still get it by ID though:

        {get $order from "/orders/123"}
        {$order|dump} -- Still here! But not really here.

We can just as easy pull the document out of the trash and put it back where it was.

It's the reason you see we can delete documents without even a warning in the demo (<http://demo.getfwd.com>).

</comment><comment><USER7> Really interesting. As someone who's done some consulting in e-commerce I've always dreamt of an open source engine based on MongoDB.

Magento and Prestashop are perfect examples of "relational databases gone wrong"... 2,000 tables? Right!

<comment><AUTHOR> I started building my own first e-commerce business around the time Magento hit beta, and the EAV (Entity Attribute Value) model is the part that killed it for me. I had ideas for my site that didn't work out of the box, so I knew I had to understand the code to customize it.

Instead we built a platform from scratch to fit the unique features of that site, and it worked. The business did $400k in revenue the first year.

Now a few years later, I can accomplish the same thing with the same basic skills (HTML, CSS, easy to understand data storage), but I don't have to start from scratch. I wanted this to exist so that I would have fun building e-commerce sites again.

</comment></comment><comment><USER8> I thought that e-commerce was one of the things MongoDB said it would not be good for [http://www.mongodb.org/display/DOCS/Use+Cases#UseCases- Whens...](http://www.mongodb.org/display/DOCS/Use+Cases#UseCases- WhenshouldyouconsiderusingMongoDB%3F) I love MongoDB and I use it on many of the projects I work on, but I'd want something transactional and ACID compliant when dealing with money and purchase tracking. How are you mitigating the risks of data integrity compromise when using Mongo?

<comment><AUTHOR> There are ways to perform document-level transactions using optimistic or pessimistic locking, in our experience so far this has been sufficient for purchase tracking. I imagine our perspective will mature as we get the system into higher load scenarios.

One of the reasons we decided to delay code release is that we need more time/resources to get it ready for the different ways developers will try to use it early on.

</comment></comment><comment><AUTHOR> Another concept in Forward that is new, REST-like models. The base Model defines 4 public methods:

        get(uri, data)
        put(uri, data)
        post(uri, data)
        delete(uri, data)

It's easy to code a model around this pattern, and the result is a system that functions entirely without procedures from the template's perspective.

For those used to WordPress style functions in templates, this model accomplishes something similar, but again without functions.

</comment><comment><USER9> I have recently been evaluating e-commerce platforms for an upcoming project. This looks very nice, but it seems to be missing one key piece of functionality: variable products. For example, shirts that come in three sizes and three colors (so 9 combinations, each with their own SKU and inventory level).

I guess since it is open source, if I want this added, I should put my money where my mouth is and add it myself. Maybe one day, if I ever have the time..

<comment><AUTHOR> It does have this functionality, but so far we've used it in different ways. What you see in the Demo admin is not all there is, but since it's meant to customize, certain features aren't visible in this version.

My last e-commerce business was a fashion site (<http://redtagcrazy.com/blog>) built on a custom platform, and we dealt with variations of course, but so far only one of the early sites we built on the platform needed this feature (and they have it).

Edit: I would add that Forward aims to be full-featured, and anything you might reasonably expect out of the box in something like Magento, will be available in one form or another.

<comment><USER9> That is good to know, thanks!

I have also built totally custom ecommerce platforms in the past (getbuckyballs.com) and I understand many of the difficulties involved. I think you guys have done a great job with this, I hope I have a project that can use it.

</comment></comment></comment><comment><AUTHOR> Developer/founder of Forward here, happy to answer questions about what it is, why, how, and take critical feedback.

Devs complain endlessly about the rigid, complex mess of e-commerce software. I'm trying to change that with a platform that is easy to understand and customize by developers. We've had a lot of success so far with early projects like <http://jellyfishart.com>.

MongoDB has been a huge help.

<comment><USER10> The layout is great, very clean, great job.

That said, how do you deal with transactions? It was my impression that MongoDB doesn't really support ACID transactions. Did you find a workaround?

I know from prior experience working on a major eCommerce store that there can be really taxing loads on the database server, right around Black Friday, and having inconsistent writes could really be disastrous. Have you tested your transactions for consistency under load?

<comment><AUTHOR> To start, I will say we haven't run into any issues relating to consistency under load. We do have a plan for dealing with it, using an optimistic locking mechanism (where each document has a revision number and an update requires it), but as an early project we haven't had the chance to put it up against high load for a long period of time.

Also, I'm pretty confident MongoDB is going to introduce an easier mechanism for document locking in the near future.

<comment><USER11> It's difficult to find the right back-end solution that can easily scale with a business and demand. I saw this post a month ago and think it looks pretty promising and might be something you could take advantage of here. <http://news.ycombinator.com/item?id=4294719>

Currently it's in alpha testing and promises multi-key ACID transactions. And also introduces a really interesting layers concept. <http://www.foundationdb.com/#layers>

Keep up the great work!

</comment></comment></comment></comment><comment><USER12> Why should a developer or a contributor pay to help develop something for the community ? seems a little too money making and less community driven.

<comment><USER2> What the fuck? Are you joking? We now live in a world where developers bust their asses to deliver _99 cent applications_. It's fucked. Slowly, here and there, we're beginning to see a shift. People will pay for a great product, especially if it makes your job as a hacker/developer easier.

Play with the demo for 60 seconds. How long would it take you to build that? How much do you charge per hour? I built a lightweight ORM for pymongo/mongodb last weekend from an empty .py file. It was fun, but it was challenging and took pretty much the entire weekend. And it's basic. You can find, find_by_id, find_one, and a few other things. What these guys have done is tremendously impressive and difficult to do. They deserve every right to ask for money and that will only fuel further development.

Everyone has to keep the lights on at some point.

<comment><AUTHOR> You get at the core of the issue here, which is that we can save developers a huge amount of time with the right mix of pre-built components and dedicated developer support.

All of our paid options surround the idea that developers can go faster and better leverage their time with time-sensitive help. We've all become used to Stackoverflow saving the day, but if the answer doesn't magically pop up in Google, we can waste many hours chasing it needlessly.

I hope the future is full of paid open source options.

<comment><USER6> Same here. The mixture of support contracts, straight up donations and the Varnish Moral License that varnish offers is, I think, a taste of things to come. Mixing support and patronage is, I think, the answer - patronage is a means to ensure the software is better, support contracts a hedge against it sucking - but if you combine the two so money spent is never perceived by the customer as wasted, the result is really quite interesting.

</comment></comment></comment></comment><comment><USER13> Great effort, I'd love to see the finished product. I have been contemplating of migrating my own e-commerce platform (<http://demo.embwebstores.com>) to MongoDB and one of the new frameworks - Laravel.

I wonder if you found the lack of relational data an obstacle? Maybe not now but do you see it being a problem down the road?

<comment><AUTHOR> We didn't find the lack of relational queries an obstacle at all. The model in Forward handles relationships in a way that makes it feel easy. Model fields can be defined as a callback:

        // class Accounts ...
        'orders' => function ($account) {
            return get("/orders", [account_id => $account['id']]);
        }

Get an account, access the relationship:

        {get $account from "/accounts/123"}

        You have {pluralize "{$account.orders.count} orders"}

        {foreach $account.orders as $order}
            ...
        {/foreach}

This also works as expected:

        {get $orders from "/accounts/123/orders"}

It would be cool if you built your platform on Forward. Just sayin' :)

</comment></comment><comment><USER14> Looks very cool.

Where is the source code repo for Forward? I take it its public as it says "open-source platform"

edit: nm i found the burb.

"Scheduled for public release in June 2013. The code will be 100% free forever, supported by our team plus a community of open source developers."

<comment><AUTHOR> Open source is important because it gives you freedom, but we want to have the resources to support developers before releasing code. Without support and great docs (which are coming), it would be a frustrating experience.

</comment></comment><comment><USER15> You should have said that with "Free style templates" what you really mean is a BPEL.

The first time I've seen the project I've thought "oh no, another MVC framework!"

Now that I've seen the {put [status => "shipped"] in "/orders/12345"} I think it's cool.

<comment><AUTHOR> You have a good point here, and we will share a lot more details around the template code on our blog soon. I hadn't heard specifically of BPEL but will check that out.

We went with the MVC pattern to leverage ours and others' experience in that architecture, but there is almost no typical MVC boilerplate to deal with in Forward.

You just create a new template file, like "mypage.html", and go, just like you would with raw HTML mockups. If you prefer to write controllers you can. If you want to write custom data models (for something like this {put [something] in "/my-custom-model"}), you can, but you don't have to.

This is meant to make it easy for less technical designers to move fast without having to learn MVC patterns.

</comment></comment><comment><USER16> Looks amazing. You should have more technical details on the site though. This is _for_ developers so they can handle it up front. I had to dig a bit to find out it's a templating engine built on top of PHP. More about the architecture would be good.

<comment><AUTHOR> You have a good point. We'll write a lot more technical detail over the coming weeks on our blog. I'm also writing a guest post (technical) for the MongoDB blog, so expect a lot more to come out soon.

The architecture: A very small PHP MVC framework (5% or so the size of Zend Framework last I checked). I started developing the earliest version of it ~6 years ago, around the time Rails picked up steam. I loved Rails and Ruby, but with so much invested in PHP (10 years back then) I decided to implement Rails-like patterns instead. Those patterns have matured a lot, but I stick to idea that the framework should be very light itself. Happy to answer more specific questions.

Also, I'm really excited about the idea of porting the framework/platform to languages like Python and Ruby. I think it's possible because it's so light weight, but time will tell. People might call me crazy for that one, but I've been dreaming about a multi-language platform for years.

<comment><USER7> What about frontend? Are you using an MVC framework?

<comment><AUTHOR> It is an MVC framework per se, but it's new and unique to this platform. It's very light, therr are about ~10 core classes. It also uses Smarty 3 (which is a big improvement over Smart 2), but the template system can be swapped out for pure PHP or another package for those prefer.

<comment><USER7> Sorry I wasn't clear enough: do you use any JS MVC framework, like Backbone etc. ?

<comment><AUTHOR> Ahh I see, there is no UI framework, just a simple list/view pattern. Views are loaded in HTML parts from the server (old school). I would like to see what people come up with using a framework like Backbone.

One of the driving ideas is that people will develop different versions of an Admin interface. What you see in the demo is just a template, like any front- end template, so creating one with Backbone would be an interesting project.

</comment></comment></comment></comment></comment></comment><comment><USER17> Damn you! I'm about a month away from re-launching an ecommerce site in MongoDB. I probably could have used this six months ago :-)

Oh well, very nice product, glad to hear of yet another use-case for MongoDB and ecommerce.

<comment><AUTHOR> I knew there had to be others building e-commerce with MongoDB, but have seen very little of it so far. We've be happy to help you in the future if your site can benefit from it.

</comment></comment><comment><USER18> I had my e-commerce website ( <http://www.modewalk.com> ) opened in a tab when I opened yours. Funny enough, our favicons are very similar :)

<comment><AUTHOR> Hey that's cool! Great looking site too, I'd be interested to know how you built it.

<comment><USER18> Python/Django/Fabric/Celery/Redis/PostgreSQL/SphinxSearch/jQuery/Sass/AWS/Jenkins/Selenium/etc and a lot of stress/tears/joy hahaha

<comment><AUTHOR> Fantastic, I think it's a rare breed that can take on the full-stack challenge like this. I would kill to hire people like you.

<comment><USER18> Thank you! Should I tell you that I am currently porting a native iOS app I wrote sometime back (in C++ / Objective C) to Android. Sometimes I feel that I have a tech version of Attention Deficit Disorder.

</comment></comment></comment></comment></comment><comment><USER19> Will this e-commerce platform support digital file download/delivery?

<comment><AUTHOR> Definitely, the goal is to support all of the most common e-commerce models (standard, drop ship, subscription, private sale, etc) out of the box and free. There may be different default admin versions to start with also, but the admin is easy to modify for anyone with HTML knowledge, so it's expected that certain features will work differently for different models.

MongoDB makes this much easier because the database only needs to know about the way you are using it, and not the various other ways that unrelated businesses might use it.

Digital file delivery is on the roadmap now (will publish this in the near future).

<comment><USER19> Thanks! I am really looking forward to using Forward (no pun intended). It looks so damn good. I think your solution is what LemonStand cart is TRYING to be but is not quite there in my opinion (and probably will never be).

</comment></comment></comment><comment><USER20> This looks promising. Having worked with Magento for a few years now I appreciate the thought you put into the UI and the choice of MongoDB is excellent.

<comment><AUTHOR> Thank you, I'd be really interested to get you working with the current version. I'm looking for Magento developers that can help connect the dots with that community. E-mail eric at getfwd if you're interested.

</comment></comment><comment><USER21> Congrats! This is truly awesome.

<comment><AUTHOR> Thanks Cam :)

</comment></comment><comment><USER22> Looks incredibly cool. What JS library/framework is this using?

<comment><AUTHOR> Only jQuery at the moment. The UI seems fast because MongoDB is very good with caching and speed in general, so it kind of feels like a client-side UI, but it's actually all server side rendering.</comment></comment>


South Carolina Bill: Compensate People for Forcing Them to Give Birth - <AUTHOR> https://rewire.news/ablc/2019/12/13/groundbreaking-south-carolina-bill-compensate-people-for-forcing-them-to-give-birth/ <comment><USER2> This is incredible. Imaging growing up and discovering your mom swore that if it weren't for the SC state government giving her services she would have aborted you. Hey mom how did we get this college savings account?

These pro life laws are unfair, because this can happen to a woman and not to a man. That's obviously unfair. It doesn't make them wrong. Government money would be best served incentivising adoption. After such human tragedy of injustice as rape that's the only possible path forward.

<comment><USER3> I think it would be just as devastating for the child to learn that they only exist because their father raped them into existence. If the money incentivizes the mother to give birth and potentially raise a child she might understandably otherwise detest, so be it. That's the least of the child's concerns once they are born.

I agree that late-stage abortion presents ethical issues. But before then, it shouldn't be up to governments and law enforcement to mandate what grows inside their population members bodies.

</comment></comment><comment><USER4> Sounds reasonable in cases of rape.</comment>


Ask HN: Does anyone use Nim language in production? - <AUTHOR> How has your experience been compared to your previous tech?<p>How mature is the standard library? How abundant are third party libraries? <comment><USER2> Judging by the upvotes there is a lot of interest in hearing answers to this question and yet there are few comments so far. I will share my thoughts but keep in mind that I am (extremely) biased as I am one of the core Nim devs.

> How has your experience been compared to your previous tech?

Previous to using Nim I was primarily using Python. This was a few years ago now, but recently I was working on a project in Python and found myself yearning for Nim. There were multiple reasons for this, but what stuck with me was how much I missed static typing. The Python project used type hints which I found rather awkward to use (of course the fact that we didn't enforce their use didn't help, but it felt like such a half-baked solution). Dependencies very often required multiple guesses and searches through stack overflow to get working. And the resulting program was slow.

As far as I'm concerned, Nim is Python done right. It produces fast dependency-free binaries and has a strong type system with support for generics.

Of course, that isn't to say that Nim is a perfect language (but then what is). For example, JetBrains has done a brilliant job with PyCharm. Nim could use a good IDE like PyCharm and with its strong typing it has the potential to work even better.

> How mature is the standard library?

To be honest the standard library does need some work. In the next release we do plan on making some breaking changes, but we always lean on the side of keeping compatibility even though Nim is still pre-1.0. Of course, sometimes this is not possible.

> How abundant are third party libraries?

Not as abundant as I would like. Great news is that you can help change that :)

The Nimble package manager is still relatively new, but you can get a pretty good idea of the third party libraries available by looking at the package list repo[1].

Hope that helps. Please feel free to AMA, I'd love to introduce you to our community.

1 - [https://github.com/nim- lang/packages/blob/master/packages.js...](https://github.com/nim- lang/packages/blob/master/packages.json)

<comment><AUTHOR> I love the simple and clean syntax of Nim. The first time I was very impressed with vim was when I used a wikipedia xml dump parser. What would have literally taken days to complete in Python (atleast on my machine, and god forbid if it had crashed somewhere in the middle) was done in a few mins by nim (again on the same machine). I was blown away!

The one thing that concerns me a bit is that identifiers are partial case- insensitive right?

(That means only the first letters are compared in a case sensitive manner. Other letters are compared case insensitively and underscores are ignored.)

Does it hinder when you need to do refactoring?

Also, I work in vim, and grep for stuff when I need. I am not sure if autosuggests and locating definitions/usage for variables would work. I am sure I must be wrong as I believe the core developers would have thought about it :) I just would like to know how

<comment><USER3> Identifiers are "style-insensitive", so case changes and single underscore insertions don't actually change the identifier. There is exhaustive tooling such as nimgrep and ide support built into the compiler (such as find symbol at point equivalents) for helping when a convention is different. It is a strong philosophical position, but it does allow style consistency across a code base even when dealing with foreign symbols.

<comment><USER4> Wouldn't it have been better to just enforce one style over all nim code?

<comment><USER2> Perhaps, but I bet that would dissuade a very large proportion of people from trying the language.

<comment><USER5> The "style insensitivity" decision dissuades me much more strongly than some case sensitivity style enforcement in the language would.

It seems odd to me that Nim developers chose to go with that "style insensitivity" (which I would have predicted would be highly controversial and very discouraging for many, many developers) but indentation sensitivity (which is less controversial, but still _more_ controversial than indentation insensitivity; shockingly large numbers of people dislike it, including me at least when combined with some other language features).

If the goal was widest possible appeal and adoption, those two decisions should have been swapped, I think. If the goal is related to some specific philosophical stance, however, I suppose every language developer who doesn't just want to recreate PHP or VisualBasic needs to pick the hill on which he or she is willing to die, and only time will tell whether it will be worth it.

<comment><USER2> The goal of any language designer is not to appeal to the widest possible group of people but to create a language that appeals to them. In this case style insensitivity is something that Araq wanted in his language and so he implemented it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> I did, and do at my new place of work too. Usually for tooling, automation, etc. As of 0.17, I'm quite happy with the standard library, though I still think the Futures impl needs a bit of work.

I'm now using it extensively for a confidential computing and block chain project, which is quite exciting.

</comment><comment><USER7> > How has your experience been compared to your previous tech?

Having used Python, Go, C, Perl, Java, Nim is a breeze to code in. Occasionally the compiler glitches and you have to delete nimcache. Very rarely it fails to compile something and you have to rewrite few lines differently. Not an issue. Build frequently to avoid any surprise.

> How mature is the standard library?

Not that much: it lacks examples and helper procedures that you would expect, yet I still feel more productive with Nim than other languages.

> How abundant are third party libraries?

Look at the packages. Most of the basic stuff it's there. For small and medium projects it's usually not an issue, occasionally I have to wrap functions from a C library.

If you are looking for big, fancy libraries like Pandas and Sklearn, they are just not there. Use Nim for tool and services instead.

<comment><USER8> > Very rarely it fails to compile something and you have to rewrite few lines > differently

This is a huge issue. If you can't trust the compiler, it's not ready to be used for any function that is system critical.

<comment><USER2> That depends on the frequency. Even gcc has bugs, albeit more rarely than Nim. The great thing about Nim is that you can very easily get in touch with one of the developers (me or Araq) on IRC/Gitter.

<comment><USER8> Yeah I don't care if you guys were on site providing 24/7 support, im not going to use a language in production that can't be trusted to compile accurately.

</comment></comment></comment></comment><comment><USER9> Not myself personally, but I know this game was written with nim: [https://impbox.itch.io/vektor2089](https://impbox.itch.io/vektor2089).

<comment><USER2> Yep, impbox is extremely talented having won the latest Ludum Dare recently with Nim too[1] (A web version that uses Nim's JS backend also exists![2])

1 - [https://ldjam.com/events/ludum- dare/38/smalltrek](https://ldjam.com/events/ludum-dare/38/smalltrek)

2 - [http://static.impbox.net/smalltrek/nicojs.html](http://static.impbox.net/smalltrek/nicojs.html)

</comment></comment><comment><USER10> Yes, my startup Object AI uses Nim code in production. We have in-house implementations of machine learning, computer vision & image processing code in Nim, using a library called "Nim-Pymod" to integrate with Python's Numpy: [https://github.com/jboy/nim-pymod](https://github.com/jboy/nim-pymod)

(As you can see, I was one of the authors of that library in a previous startup. We haven't worked on Nim-Pymod in a while, alas -- I've been focused on the new startup! -- but Nim-Pymod is sufficient for our needs right now.)

Our webserver main-loops are in Python; our number-crunching ML/CV/img-proc code is Python extension modules written in Nim.

As a C++ & Python programmer, I'm a huge fan of Nim, which to me combines the best of both languages (such as Python's clear, concise syntax & built-in collection types, with C++'s powerful generics & zero-cost abstractions), with some treats from other languages mixed in (such as Lisp-like macros and some Ruby-like syntax). I find Nim much more readable than C or C++, especially for Numpy integration. I also find Nim much more efficient to code in than C or C++ (in terms of programmer time).

And Nim is a very extensible language, which enables Nim-Pymod to be more than just a wrapper. For example:

1\. Nim-Pymod uses Nim macros (which are like optionally-typed Lisp macros rather than text-munging C preprocessor macros) to auto-generate the C boilerplate functions around our Nim code to create Python extension modules.

2\. Nim-Pymod provides statically-typed C++-like iterators to access the Numpy arrays; these iterators include automatic inline checks to catch the usual subtle array-access errors. Nim macros are themselves Nim code, which can be controlled via globals, which in turn can be set by compiler directives; by compiling the Nim code in "production" mode rather than "debug" mode after testing, we can switch off the slowest of these checks to get back to direct- access speed without needing to make any code changes. (And of course Nim's static typing catches type errors at compilation time regardless of the compilation mode.)

3\. Nim exceptions have an informative stack trace like Python exceptions do, and Nim-Pymod converts Nim exceptions into Python exceptions at the interface, preserving the stack trace, meaning you have a Python stack trace all the way back to the exact location in your Nim code.

Earlier on in our development of Nim-Pymod, there were some occasional headaches with Nim due to its in-development status. Occasionally the Nim syntax would change slightly and that would break our code (boo). We've also debugged a few problems in the Nim standard library. I suppose these problems are an unfortunate consequence of Nim having a small set of core devs contributing their time (rather than being supported by Microsoft, Sun, Google or Mozilla). Fortunately, these problems seem to have stabilised by now.

The Nim standard library is reasonably large, somewhere between C++ STL (data structures & algos) & Python stdlib (task-specific functionality). I recall that the stdlib could use some standardisation for uniformity, but I haven't been watching it closely for the last year or so.

Third party libraries are not abundant, aside from a handful of prolific Nim community-members who have produced dozens of fantastic libraries (eg, [https://github.com/def-](https://github.com/def-) , [https://github.com/dom96](https://github.com/dom96) , [https://github.com/fowlmouth](https://github.com/fowlmouth) , [https://github.com/yglukhov](https://github.com/yglukhov) ).

I'm happy to answer any other questions about using Nim in production!

<comment><USER11> Being a hosted language (compiles to C/C++/Javascript) which are the biggest pains?

Is there any way to ensure type checking for the exposed interfaces in runtime? Let's say, exposing a function to the host language (C or Javascript) which accepts a String and then passing an integer in the host language.

Did you ever use the javascript backend? How is the experience having a shared code base among very different platforms?

How does interfacing to existing libraries look like? Any examples out there?

Does it really compile to C/C++ or just binary? If it compiles to code, then is it possible to write libraries for mobile platforms as well?

<comment><USER10> I've never used the JS backend or C++ backend, so I can only talk about the C backend.

With the C backend, the Nim code is transpiled to C code (surprisingly readable C code, as far as auto-generated C goes), which is then compiled to one of: a binary executable, a shared C library, or a static C library: [https://nim-lang.org/docs/nimc.html#compiler-usage](https://nim- lang.org/docs/nimc.html#compiler-usage)

In fact, Nim-Pymod _relies_ upon the Nim->C->library compilation, because it uses the Python C API to produce Python extension modules: [https://docs.python.org/2/extending/extending.html](https://docs.python.org/2/extending/extending.html) , [https://docs.python.org/2/c-api/](https://docs.python.org/2/c-api/)

If you want to see a shared C library produced by Nim, have a play with some of the examples provided with Nim-Pymod: [https://github.com/jboy/nim- pymod/tree/master/examples](https://github.com/jboy/nim- pymod/tree/master/examples) It auto-generates the appropriate Python C API boilerplate functions around your Nim functions, then compiles the whole thing as a shared C library, exposing the auto-generated functions in the shared library.

Regarding runtime type-checking: Again, I can only talk about the C backend. The type checking provided by shared or static C libraries will be whatever the C compiler enforces... I haven't tested whether (or how much) this can be violated.

Nim-Pymod _does_ auto-generate the Python->C type-checking code for you, so you can't (for example) pass in a Python string when an int is expected by your Nim function.

</comment></comment></comment><comment><USER12> I've just started writing a few scripts I'd normally use Python for (no production) and have been impressed with the speed and binary sizes. Nim in Action (book) is really good and what is missing to get the beginner started. I'd like to see a PyCharm like IDE for Nim as well, but Vim seems to work well.

<comment><USER13> For those interested in "Nim in Action", its publisher, Manning has a 50% off all e-books sale going through midnight today (27-May). Use code `wm052717lt`.

Usually when they have this sort of sale on a holiday weekend, they spin up some new 50% off sale the following day, so check in again Sunday if you missed it today.

<comment><USER2> Here is another discount code for today: wm052817lt

Also here is my referral link (helps me when you buy via this link :) ) [https://www.manning.com/books/nim-in- action?a_aid=niminactio...](https://www.manning.com/books/nim-in- action?a_aid=niminaction&a_bid=78a27e81)

<comment><USER12> Can't remember if I thanked you on here before, but nice book. I'm eagerly awaiting the print version to eventually show up at my house. Isn't it supposed to ship this month?

</comment></comment></comment></comment><comment><USER14> One outsourcing company named Xored have choosen Nim as their primary language few years ago, at least that is what a company owner have declared.

</comment><comment><USER15> For those using Nim: how is the compile speed?

<comment><USER2> Very fast. I can bootstrap the compiler in under a minute. Compilation times are further reduced while developing thanks to incremental compilation.

<comment><USER15> Sounds great! What about debugging? I understand that Nim compiles to C/C++ so I am curious if I can use Xcode on a Mac and Visual Studio on Windows to debug the generated C/C++ code.

</comment></comment></comment><comment><USER16> Noob question: differences between Nim and Crystal?

<comment><USER17> From the crowd-sourced intr feature table I initiated [1] it turns out light- weight threads is one of the the more prominent features that is only supported by Crystal, and not Nim.

[1] [https://docs.google.com/spreadsheets/d/1BAiJR026ih1U8HoRw__n...](https://docs.google.com/spreadsheets/d/1BAiJR026ih1U8HoRw__nzbCSFnnHicWrjxpW5l6-O3w/edit#gid=0)

</comment></comment><comment><USER18> Here's a small teaser of yet not fully released game: [https://www.youtube.com/watch?v=3Hzhqjiz- Wo](https://www.youtube.com/watch?v=3Hzhqjiz-Wo)

> How has your experience been compared to your previous tech?

IMO. Comparing to C++, Objective-C, Java, Python, JavaScript, Python, D. Nim is an amazing language from its design standpoint. First, why we have chosen Nim for a pretty significant commercial project 2 years ago? Even though at that time Nim was not as stable as it is now, the main bet was on its hackability and compilation through C. That means a lot of things. E.g. we can fix some bugs in Nim ourselves, because the entry level is much lower than, say, with LLVM-based compiler. And if things go completely wrong and we can't fix them, we could use Nim's {.emit.} pragma to actually inject C code. A hammer of last resort :). As it turned out, there were some minor problems, but all of them were fixed pretty quickly either by our team, or by friendly Nim community. As for the language itself, it's simply amazing. These key points about efficiency and expressiveness are 200% true. But you can easily learn that from some simple pet projects.

> How mature is the standard library? How abundant are third party libraries?

The standard lib is OK, still could be polished a bit. We haven't had any critical issues with it. As for the third-party libs. Of course you can't be serious comparing Nim ecosystem to some more mainstream one, like js, python, go, you name it. During our project we had to reinvent a lot. There's an interesting observation though that things in Nim may be invented a lot faster than in aforementioned techs, but yeah, someone has to do it =).

To summarize. If you're thinking whether it is worth to start a real commercial project in Nim (the answer is of course YES! DEFINITELY! =), consider the following:

1\. Of your products' 100% functionality how much can be done with third-party libs? If the answer is "you take ruby on rails, write a couple of lines of code, and done!" then unfortunately Nim is not your option yet. But if this is a game, or a backend with a lot of logic, an app with simple UI and a lot of business logic, there is a good chance that Nim is your option.

2\. If this is embedded code (like firmware or driver) you'd otherwise write in C or C++, you should consider Nim in the first place.

3\. If so happened that Nim is a good option for you (which is rather likely), make sure your team has one or two experienced developers which can handle unexpected issues. Such developers should be fluent with C/C++ and JS (if you're using Nim JS backend or asm.js compilers). They should know how stuff works for the case, when you need a lib which is not available in Nim, and you decide whether to bind an existing one from foreign ecosystem, or to write your own.

4\. Don't be afraid of the fact that Nim is still pre-1.0. Minor things may break occasionally, but nothing that single developer could not fix in a couple of hours in a 100KLoc project. Such things happened pretty rarely in our case and they are becoming even less frequent as Nim develops.</comment>


500+ Times Faster Than Deep Learning - <AUTHOR> https://arxiv.org/abs/1802.05319 <comment><USER2> What I want to see is something that I can relate to, like beating AlphaZero for example.

<comment><USER2> That didn't come across as intended. To rephrase:

I would like to read about a success story of SVM in practice for some types of generalized (e.g. video games, other games, or some other categories), unsupervised problem solving. To say it's 500x faster it should be comparable in the problem space.</comment></comment>


How I Became HackerRank #1 in Two Hours - <AUTHOR> http://williampross.com/became-hackerrank-1-two-hours/ <comment><USER2> I hope there will be more articles like this exposing HackerRank and its ilk. Recently, I found myself on that site, and quickly gave up on it after having to deal with bugs and artificial impediments, even having problems copying and pasting from my text editor to their textbox.

It is a waste of time for anyone who can program.

<comment><AUTHOR> Yea I agree. Their own site is programmed very poorly, yet they are supposed to be the graders of who is a good programmer?

</comment></comment><comment><USER3> See another somewhat recent post about HackerRank [0]. No surprise that it was flagged.

[0] [https://news.ycombinator.com/item?id=12667174](https://news.ycombinator.com/item?id=12667174)

</comment><comment><USER4> Funny, this article was reposted about an hour ago but instead of using the actual link, they appended:

?ref=yc

Nice touch to suck up the karma for an obviously hot topic.

</comment><comment><USER5> The stdin nonsense on Hacker Rank is what got me. I neither know, nor do I care how to process standard in in Swift. When a ten line program needs 70 lines of boilerplate you have a lousy system.</comment>


Ask HN: Is it possible to get a job at Facebook without going to ivy league? - <AUTHOR>

One of my dream jobs is to work at Facebook. I didn't go to an Ivy League school, but I'm about to have my CS degree from a public university. I am self-taught developer as well. <comment><USER2> I went to CMU and am a software engineer at Facebook.

Out of curiosity, why do you think that having an Ivy League degree is necessary? Is there anything we did to convey that impression, or anything we can do to combat it preemptively?

<comment><AUTHOR> Well, I just have noticed that many people have gone to Stanford or Harvard, you know big name schools. I don't have hard data, but thanks for the comment :)

<comment><USER3> Just as a quick note, Stanford isn't an Ivy. The ivies are Brown, Columbia, Cornell, Dartmouth, Harvard, Princeton, Penn, and Yale.

</comment></comment></comment><comment><USER4> I'm a drop out from a 3rd world country and I'm an engineer at Facebook. I'm also an interviewer, an trust me guys. We really don't care where and if you graduated. If you are good, you are in.

<comment><AUTHOR> Did you create an account to answer this question?

<comment><USER4> Yeah, I didn't have one, I guess. I was hoping to get notifications from this thread, but no. :-(

</comment></comment></comment><comment><USER5> Yes, it's possible.

Source: I went to San Jose State University and I'm a software engineer at Facebook. :)

</comment><comment><USER6> Hello. I am an engineer at Facebook. My CS degree is from a small school. Our CS department had 5 professors and 50 graduates per year. One of our cafes on campus is called "Living the Dream". That is the kind of people we are looking for. We hire by talent not by school. That said, keep living your dream!

</comment><comment><USER7> I have a non-technical BS from Ithaca College, did my graduate work in social science, and do research at Facebook. It is a wonderfully heterogeneous place.

</comment><comment><USER8> I attended University of Illinois (also a public university) and dropped out, and I'm an engineer at Facebook. :)

</comment><comment><USER9> Just like Google, I'm sure they only admit the best of the best. However, if the skills, creativity, and out-of-box thinking that they desire are present, it shouldn't matter where you went to school. You either have "it" or you don't.

</comment><comment><USER10> Hi!

Please, please, please, please, please, please, don't forget the opening text from Y Combinator:[http://ycombinator.com/ad.html](http://ycombinator.com/ad.html)

Then remember WhatsApp's founder was rejected.

<comment><AUTHOR> Hi. I don't understand. I've read it, but can you please share some insight to what that means?

<comment><USER10> Whenever I see a post that is like "How do I get a job at <POPULAR_COMPANY_XYZ>" I am reminded of the fact that Google tried to sell to Yahoo before they were Google, and that the founder of WhatsApp was turned down by Facebook.

I just have a feeling that you aren't interested in Facebook as much as you are in doing something interesting, which might include a new company.

</comment></comment></comment><comment><USER11> I know several engineers at Facebook. None of them went to an ivy league school

</comment><comment><USER12> You can do better than work at Facebook. It is now a big company with all the travails of Corporate Tech America, on the same levels of Ebay and Google.

<comment><USER13> Well, the 'pro' arguments are that these companies you named probably pay well, involve working on interesting and cutting edge technologies, and, having one on your resume would guarantee consideration for jobs in the future.

The cons are, what... they're not tiny startups which no one will even remember a year after they're gone?

</comment></comment><comment><USER14> Facebook hires a number of Stanford people and that's not an Ivy League school.

<comment><USER15> Stanford has a better CS program then any Ivy League school so that's not a surprise</comment></comment>


Why Warren Buffet Disdains The Private Equity Crowd - <AUTHOR> http://www.forbes.com/sites/robertlenzner/2012/01/14/why-warren-buffett-loathes-the-private-equity-crowd/

<comment><USER2> Strange article. Not much content about what Buffet actually thinks and it goes onto some sort of political diatribe against Mitt Romney.

In my opinion PE shops fill a different sort of gap. Whereas Buffet benefits by buying a company that is extremely well managed, PE shops can sometimes create value by changing the management team of a company that is not optimally run.

Mitt Romney's track record at BCG, Bain, and Bain Capital should be examined, but I don't understand why it's in an article about Warren Buffet.</comment>


Rock-Paper-Scissors: You vs. the Computer (2011) - <AUTHOR> http://www.nytimes.com/interactive/science/rock-paper-scissors.html?_r=0

<comment><USER2> I did the mistake of looking of it's algorithm after a few turns. After that it is not possible for the AI to exploit you any more. Or I haven't played long enough for the AI to discover it's algorithm has been exploited. So as an advice to other players, don't click on the button "see what the computer is thinking" until you feel you have deducted it's algorithm yourself. Takes away too much of the fun.

</comment><comment><USER3> I read an article a while back that said good computer simulations should expect the human to usually not choose the same throw repeatedly, and especially not choose the throw if the player lost the previous time.

Also, humans tend to choose throws that make up an even distribution of R/P/S — that is, the chances of a rock being thrown after 2 paper and 2 scissors is much higher.

</comment><comment><USER4> Doesn't seem too hard to beat it, since all you have to do is imagine what a person would most likely do given your history. Do scissors three times, and the AI will assume you'll do it again.

<comment><USER5> And then what? If you do 3 scissors and a rock, what would a human typically do next? By making use of the pattern you have to break it.

</comment></comment><comment><USER6> A previous discussion from several years ago: [https://news.ycombinator.com/item?id=2290936](https://news.ycombinator.com/item?id=2290936).</comment>


Exploiting rootpipe again - <AUTHOR> https://truesecdev.wordpress.com/2015/07/01/exploiting-rootpipe-again/

<comment><USER2> Apple: security is hard, let's go shopping (for yet another UI change for the OS!)</comment>


What I Learned in San Francisco - <AUTHOR> http://blog.kera.io/post/35140210619/what-i-learned-in-san-francisco

<comment><USER2> Great follow up</comment>


Ask HN: Who uses computer eyewear? - <AUTHOR> I just stumbled into https://gunnar.com (there are probably more) it seems from reviews on Amazon that they give some benfit.  But i'm very skeptical.<p>does anyone were it and have some feedback? <comment><USER2> My girlfriend bought me some of these. I like them.

I try to wear low-power reading glasses while at the computer, on the advice of my (retired) optometrist friend, to avoid nearpoint stress, despite having 20/20 vision.

She bought me a pretty simple-looking variety, with amber lenses. I don't really care about the tinting, I primarily want to get the assistance for my eyes.

They fit well and I can wear them comfortably all day.

FWIW I am a remote developer (at home).

I read some bad reviews on them, but nothing that affects their usage as I've stated it above. It's possible they claim more benefits in their marketing, I don't really know.

</comment><comment><USER3> I tried Gunnar products years ago and was not impressed. What are you trying to solve with them? If it is eyestrain and dryness, trying taking regular breaks from the screen and blink more often.

This sounds silly but when we are focused and in the zone, we often blink far less than normal, this contributes to eye discomfort.

</comment><comment><USER4> My coworker ordered some. Wore them for a few days, then just stopped. It's probably easier if you work from home or don't mind looking goofy.

I wear prescription lenses, so I would need to swap out glasses while I'm working, or buy some clip ons.

</comment><comment><USER5> I use these every day: [https://shopfelixgray.com/](https://shopfelixgray.com/). They look pretty good, and the slight magnification really helps with eye strain.

</comment><comment><USER6> Try flux (or for macOS- nightshift). I haven't felt issues with my eyes with a quality monitor and a flux-type application.</comment>


René Auberjonois, actor who starred in M*A*S*H*, Star Trek and Benson, dies - <AUTHOR> https://www.theguardian.com/film/2019/dec/09/rene-auberjonois-actor-who-starred-in-mash-star-trek-and-benson-dies-aged-79 <comment><USER2> Lots of deaths in the Star Trek world recently :(

Aron Eisenberg (Nog) died about a month ago. D. C. Fontana a week ago. The actor who played Charlie in the TOS episode "Charlie X", Robert Walker. And Marina Sirtis (Deanna Troi) posted that her husband died just today.

René Auberjonois who played Odo in DS9 is especially sad for me. One of the best characters on the best Star Trek show. You will be missed. Enjoy the Great Link.

[https://twitter.com/ShimermanArmin/status/120381039190771712...](https://twitter.com/ShimermanArmin/status/1203810391907717120)</comment>


Ask HN: Why do you avoid Telegram, arguably one of the best cloud messengers? - <AUTHOR> <comment><USER2> I avoid everything else apart from Signal (this includes Telegram) because with Signal I trust that they have:

\- end-to-end encryption enabled by default, and as far as I know there is no possible way to disable this even if I wanted to.

\- no logs/state stored server side, or at least that's what they claimed.

\- no SPAM. The only people that talk to me on signal are the ones I actually intend to talk to. Not sure if this is just because so few people use Signal or because they don't have a chat-bot API they try to push as a commercial offer.

\- a non-profit organization structure, not that being a for-profit is bad, but I tend to trust non-profits more when it comes to things like respecting privacy as a core value of their business (a for-profit would scrap that and abuse their market share at the snap of a shareholder finger).

<comment><USER3> I'd agree with all that. An in the past I'd also tend to like non-profits more until I've realized that these are as vulnerable as a for-profit in terms of ideological contamination.

</comment></comment><comment><USER4> No end-to-end encryption per default, and if I activate it I'm not able to see the conversation on other devices. Signal does that better.

<comment><USER5> \- end-to-end encryption

\- able to see the conversation on other devices

You can choose only one. Otherwise I can't see how it would be end-to-end encrypted. Your devices should create some sort of a group chat to make this work.

Group chats have large enough attack surface and "end-to-end encryption" will create false sense of security.

<comment><USER4> I use Signal on multiple desktops. It's a good experience and really works well. I can choose both.

<comment><USER5> In general there is a simple rule: either usability or security.

All general consumer grade tools are fighting with this equation: How can we make an app which will appeal to the broad audience which will be easy to use.

I can't say anything about signal but in general if something is easy to use and you can chat super secure with your grandma then most likely it isn't secure how you might think it is and it's actually an issue because you may want to send data which otherwise you wouldn't if you know you're on compromised channel.

Sharing history between e2e encrypted devices is a tricky thing because you should have forward security with some ratchet keys.

</comment></comment></comment></comment><comment><USER6> I don't know anyone who uses Telegram. Everyone I talk to uses SMS/iMessage, or _maybe_ Discord (but that's a pain in the butt for individuals).

<comment><USER7> I recently signed up to an online course at Helsinki Open University, there is an online message-board for students (empty) and a Telegram group for the users of the course which has 350+ members.

This is the only real time I've used telegram. Mostly people that I know here in Helsinki, Finland, use WhatsApp (friends, neighborhood kids-group, etc), or facebook messenger (pottery teacher, local companies).

</comment></comment><comment><USER8> I use Whatsapp, Messenger and iMessage. Simply because they are convenient and there I can reach ~95% of my friends.

</comment><comment><USER9> their encryption is closed source. If we don't know exactly how Telegram works at it's core, any encryption it might have is almost worthless IMHO. Signal and Keybase FTW

</comment><comment><USER10> I don't. Why do you think people avoid it?</comment>


iOS 12.2 Beta: Progressive Web App Capabilities - <AUTHOR> https://twitter.com/mhartington/status/1089292031548145666 <comment><USER2> I developed a web-app photo editor [https://www.Photopea.com](https://www.Photopea.com), that is used on 100 000 iOS devices at least once a month.

I am very happy, that I never had to go through the pain of submitting my "app" to Apple store or paying any fee. I never even owned any iOS device.

<comment><USER3> That is a really cool app! I bookmarked and I will definitely check it out later.

</comment></comment><comment><USER4> Without fanboying to much, I want to add how important PWAs are to breaking the walled gardens of the App Store and Play Store. Apple and Google can and will stop your app from distributing via their stores if they see fit, but they can't stop users from adding a PWA to their home screen.

This is great for user rights and moves the needle more towards a decentralized and open ecosystem, while maintaining strong security guarantees to the end-user.

<comment><USER5> It bothers me that PWAs are a thing too. If we have a perfectly capable computer in our smartphones, just let a native app (whether it uses a higher level language or not) handle it.

Better performance, better battery use, better integration, more platform features available, better look and feel, and so on...

<comment><USER2> \- "better performance, better battery use" \- this is not true at all. What makes you think so?

\- "better integration, better look and feel" \- it depends a lot on available web standards, which are constantly improving.

You forgot about disadvantages: Developers need to develop several versions of their app (they could spend that time on improving one version). They need several devices for testing (luckily, there are Unity and Xamarin). Authors have to pay fees for having their product in various "stores". Big corporations (such as Google, Apple, Microsoft, Steam) can throw you away anytime for any reason, accuse you of various violations. But noone can prevent you from going to a website.

<comment><USER5> > _- "better performance, better battery use" \- this is not true at all. What > makes you think so?_

How is that even remotely controversial? With native you run direct native code, in C/C++/Obj-C/Swift/etc and optimized native UI libraries. With a PWA you run a browser engine, a DOM rendering pipeline, and on top of it you run Javascript, and on top you run one today's frameworks. Guess what uses less battery? Ever did a comparison of native vs Electron apps on the desktop, where it's easy to compare?

(To preempt a facile counter-argument: yes, a native app can be coded very silly, do busy wait or whatever, and eat all the cpu/battery/memory. We're interested about baselines and what happens "everything else being equal").

> _- "better integration, better look and feel" \- it depends a lot on > available web standards, which are constantly improving._

Doesn't matter how much they improve, they will always not be 1:1 with the access to the smartphone OS's SDK libs a native app has.

Nor would be the exact same look/feel as the platform (which native gives you), ever compare to someone's ad-hoc UI or re-implementation of the native L&F.

> _You forgot about disadvantages: Developers need to develop several versions > of their app_

That's a disadvantage of the developer, not the user. Why would I as a user care? So that I can get more worse apps more easily?

Besides, WPA still need testing -- especially if they use the "available web standards, which are constantly improving".

> _Authors have to pay fees for having their product in various "stores"_

Still good in my book. Puts a somewhat higher barrier for crap.

<comment><USER6> As answered on another thread, PWAs are native apps on some OSes, like ChromeOS and Windows.

<comment><USER5> The OS, like ChromeOS, having "first class support" for web technologies doesn't make those apps native.

ChromeOS still runs a Linux underneath, and could run apps without a web layer, DOM, etc, if allowed.

When most of us call for "native apps" we don't mean "first class OS support" we mean "as little BS layered crap as possible on top of the CPU" \-- so AOT or even a low level VM fits that, a web rendering engine, the DOM, and JS, does not.

<comment><USER6> ChromeOS native apps are web apps, like it or not,that is what we get, even Android and the alternative Linux environment run inside VMs.

As for the second part, that is exactly what Chakra within UWP does on Windows.

<comment><USER5> > _ChromeOS native apps are web apps, like it or not,that is what we get_

Again, I explained what I mean by native apps (which is what everybody means). What "we get" and whether we "like it or not" has no bearing as to whether they're native.

When iOS at first had no public Obj-C SDK and only allowed web apps, those web apps weren't magically "native" just because that was what Apple encouraged/allowed.

"The only type of apps that are encouraged/supported by the vendor" is not the same as them being native apps.

<comment><USER6> So Chackra isn't a "even a low level VM"?

At which point do you draw the line between bitcode on watchOS, ART on Android, and Chackra on UWP?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Buried in that thread are some key details:

        Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, etc.

Basically, forcing native apps to use their in-app purchases. Won't this trigger anti-trust laws?

<comment><USER8> They've always forced native apps to use IAP (or no purchase on the device at all; go buy an eBook on Amazon's web site, and you can read it fine in Kindle on iOS) for digital goods.

Forcing web app IAP? I don't see them pulling that off successfully.

</comment></comment><comment><USER9> I _guess_ Services Worker is fine on iOS and iPhone. Because you rarely have Safari opening all the time. On macOS it is god damn awful. [1]

I am also a little uneasy with PWA, on quality, safety and without some sort of App Store firewall guarding it. But then I also don't see the point of KFC, McDonald, or every restaurant / services sector require an App for their business. When it could be on the Web or as Web App.

[1] [https://twitter.com/gruber/status/1083810719009787904](https://twitter.com/gruber/status/1083810719009787904)

<comment><USER4> Yeah, agreed. User permissions need to become more granular. A web app should not be able to use all CPU power for prolonged amounts of time. Instead the browser should drastically limit computing usage of a web app, till the user gives the explicit permission for more. That way web apps can gain more capabilities but only with the users permission.

On your second point I wholy agree that not every fast food chain or coffee shop needs a native app on their customers phone. Starbucks PWA shows the way.

</comment></comment><comment><USER10> nice. Still no push notifications which is a huge no for me when it comes to PWAs at this stage. I know there's pushover but their licensing sucks, not every user can and wants to buy it.

<comment><USER11> I agree. If Apple would support push notifications for PWAs, it would almost level the playground for most kinds of apps.

<comment><USER12> That is precisely the reason they are not going to be supported.

<comment><USER13> I'm not so sure. The Push API and Notification API are two separate things on the web, and one and the same on iOS. It wouldn't be immediately straightforward to wake up a service worker in response to a push event on iOS, so I can believe they are trying to find the optimal way of doing it.

(I also believe it's not a huge priority)

<comment><USER12> I understand that push notifications are being abused by many sites who just try to spam users but a good number of potential PWA's will become possible of push notifications become available. On the other hand I see Apple being worries about losing control over their walled garden if they give too much freedom to the browser.

<comment><USER13> I will never understand why push notification permission wasn't put behind click activation like many others are. The span of that permission prompt is very annoying.

</comment></comment></comment></comment></comment></comment><comment><USER4> "2) State is maintained if it goes in the background. A bit buggy though, but promising"

So happy about that! I almost thought Apple would deliberay cripple the PWA experience on iOS just enough in order to not be competitive to native apps. This is a huge step towards PWAs becoming a real contender in the app space. Starbucks and Twitter PWAs show what's already possible. Very bullish on this development.

<comment><USER6> Me too, I do favour native over Web, but there are a good set of applications that can be made good enough with Web stack, without any FFI or build tooling headaches.

</comment></comment><comment><USER14> A dream of Steve Jobs is coming closer to his fulfillment. When presenting iOS, he said that people will run web apps (in the browser).

<comment><USER4> I'm in favor of PWAs but I never understood why Jobs originally planed to distribute apps in such a open way. He must have known that this would drastically limit Apple's power to decide what runs on customers devices. Do you have more information on this?

Anyway, Apple seems to have changed their mind rather quickly after releasing the App Store.

</comment></comment><comment><USER15> It really bothers me that "Progressive Web Apps" are a thing. If Apple and Google allowed it, there's no need for a new paradigm - just let the browser handle it. The same way slack sends notifications over the browser on desktop, we could make use of.

Instead they want to control the interface, likely for their own gain, but also som added security. So, I get it. However, the whole buzz word and excitement is good, but it's annoyingly stifled to begin with

<comment><USER16> I don't quite getting what you are objecting to. Slack cannot send you notifications when you're not on the website, unless they have access to one of the APIs commonly bundled under the PWA umbrella.

Is it just the name you're objecting to? Do you believe it's a bad idea to strive for feature parity between native apps and the web? I seriously can't tell.

<comment><USER15> Two things:

1\. Apple and google are going to set a new set of APIs. And likely edge out the importance of other browsers.

2\. They went the app route to begin with... they could have always gone the PWA route (especially the last few years). I don't know why I have to have a native app if the entire web is now mobile friendly.

<comment><USER17> For what it's worth, Apple didn't go the app route to begin with. They were all in on web apps on the iPhone, and had no plans to allow native app development until developers demanded it. The iPhone didn't have native app support until around a year after it's release. They thought browsers had the capabilities necessary to make web apps mobile friendly enough to fill the need at the time, but that was overly-optimistic.

</comment></comment></comment></comment><comment><USER18> I wonder whether there's a difficulty in Apple about how much power to give web apps in light of their privacy play. The browser isolates permissions - Facebook can let me upload a picture in a chat without giving them permission to all my pictures, their app can't or at least doesn't. If they had notifications working for PWAs I'd probably drop Facebook Messenger for example.

</comment><comment><USER19> Is there a real primary source for this?

I'd like to know whether PWA developers need to register as developers with Apple. Hopefully not, although I don't see how Apple wants to prevent the use of third-party payment systems without forcing everyone to get their apps signed.

</comment><comment><USER20> The resuming state after leaving the PWA is awesome. My hobby project is a PWA but has a bug now since the beta where all user interaction is lost when resuming the state. I have a hunch it has to do with google maps and it's fun trying to figure it out right now.

</comment><comment><USER21> You still can't save local files with PWA...

<comment><USER22> sure you can, but the user must choose where to put it, no arbitrary saves.

[https://github.com/eligrey/FileSaver.js](https://github.com/eligrey/FileSaver.js)

<comment><USER21> [https://github.com/eligrey/FileSaver.js/issues](https://github.com/eligrey/FileSaver.js/issues)

Doesn't seem to be working well. A few people I know got burned trying to use it and expecting universal functionality across all browsers.

<comment><USER22> Seems like regular browser compatability issues to me. Specific safari not working, a few edge cases here and there. You have that in all cross browser libraries.

<comment><USER21> With save the specific problem is that Mozilla guys wanted to move all save capability to local DB + download, and to never allow writes to arbitrary local files, treating it as a security issue, which obviously is a problem for any sort of web apps running locally. Google tried to standardize FileWriter API that never made it outside Chrome, then later dropped it due to aforementioned issue.

</comment></comment></comment></comment></comment><comment><USER23> Great. Now we can have app lookalikes built with someone's pet JS framework contaminating our iPhones.

<comment><USER4> "contaminating"? PWAs are contained a whole lot stricter than native apps. Specifically on Android I would worry a lot less about adding a PWA to the home screen than installing a native app.

Do you speak out against implementing apps in JavaScript or is your criticism pointed at PWAs specifically?

<comment><USER5> > _" contaminating"? PWAs are contained a whole lot stricter than native > apps._

Contaminating as in "with their mere presence", doesn't have to be an exploit...</comment></comment></comment>


Show HN: Convert website to audiobook - <AUTHOR> https://www.txtpen.com/tts <comment><USER2> Didn't txtpen used to be an inline commenting tool, like RapGenius?

This is a significant & weird pivot.

</comment><comment><USER3> What is the ai behind the tts service ? Google Cloud Wavenet , AWS Polly or your own AI solutions ?

<comment><USER4> Perhaps it was added after you wrote the comment, but the second line on the website now says _" powered by WaveNet from Google Deepmind"_.</comment></comment>


T * sin (t) ≈ Christmas tree - <AUTHOR> https://github.com/anvaka/atree <comment><USER2> Neat idea. Hidden within the ReadMe file, someone re-wrote this tree in Wolfram but made it ornamented looking. [0]

Going further, the same author of the latter tree had a post picked by staff titled "Random Snowflake Generator Based on Cellular Automaton."[1] Another very cool idea for this time of the year.

[0][https://community.wolfram.com/groups/-/m/t/175891](https://community.wolfram.com/groups/-/m/t/175891)

[1][https://community.wolfram.com/groups/-/m/t/235291](https://community.wolfram.com/groups/-/m/t/235291)

</comment><comment><USER3> [http://dwitter.net](http://dwitter.net) has rad minimalist christmas trees every year. best bit is it's easy to remix them!

<comment><USER4> How on earth does this one work? The code is just a bunch of escaped kanji?!

[https://www.dwitter.net/d/11506](https://www.dwitter.net/d/11506)

<comment><USER5> It is not just kanji. For instance, the 3rd character is ⡸ (a braille character). I suspect what happened is that the author choose the characters needed based entirely on their unicode value, and it just so happened that many of them fell into the kanji region of Unicode[0].

Anyway, what is going on is that each character takes 4 decimal digits to encode its Unicode value.

When you escape it, the characters are replaced by their unicode values expressed in decimal, so the string looks like:

"%u7769%u7468..."

At this point, it uses a regex to change it from being a sequence of 4 hexadecimal digit characters to 2 hexadecimal digit characters, so the string becomes "%77%69%74%68%..."

At this point, it escapes the string. Giving the intended script of

        with(x)for(j=c.width=412+S(t/2)*98;v=j--<<3;beginPath(fill()))for(i=5;i--;clearRect(a*a%712,t*v%400,i,3))fillStyle=R(j/2,98-v,j<98?190-v:j),lineTo(98+S(a=i*98+v+t/8)*v,80+C(a)*v+v-j/2)

Essentially, what is going on is that the rules state there is a 140 _character_ limit. Most people interperat that as a 140 _byte_ limit, however, in exchange for 48 bytes of overhead, you can actually pack 2 bytes into a character, which gives 184 bytes of usable payload. Which is good for this submission, as the unencoded payload is exactly 184 characters (and 184 bytes).

[0] A quick search says that 4E00-9FFF is CJK (Chinese, Japanese and Korean) Unified Ideographs, and that is not the only Unicode block that seems to be devoted to CJK.

Combined with the fact that that the lower ascii characters are control characters that would't be used in a script, and you end up with almost all CJK characters. If you actually wanted to be entirely CJK, it probably wouldn't be that difficult to fudge the characters around so it fits.

</comment></comment></comment><comment><USER6> Nice. A spiral with decreasing radius essentially. On a side note, I wonder what configuration/distribution of magnetic force will make a charged particle move like this.

<comment><USER7> A charged particle moving at an angle to a magnetic field like that found at the ends of a solenoid (increasing field strength) would produce the desired motion.

Example: [https://s3-us-west-2.amazonaws.com/courses-images/wp- content...](https://s3-us-west-2.amazonaws.com/courses-images/wp- content/uploads/sites/1989/2017/06/13230250/figure-23-05-04a.jpeg)

<comment><USER6> Thank You! I'll explore it soon when I get some time.

</comment></comment></comment><comment><USER8> Suggestion: to make the tree self-similar at the vertex point, use [x, y] = t * [cos, sin] ( k * ln(t) ). The constant k determines the tightness of the spiral winding.

Another way to describe it: the spiral's uphill slope stays constant.

</comment><comment><USER9> e^it is a spiral.

t*e^it wraps the spiral round a the cone |x|=t.

</comment><comment><USER10> Inspired by this I threw this together (warning: contains music)

[https://www.vertexshaderart.com/art/rBjrdN2CvsneEkgEk](https://www.vertexshaderart.com/art/rBjrdN2CvsneEkgEk)

Yea, too much code but I'm lazy

Here's a smaller one

[https://www.vertexshaderart.com/art/uDBqerAHTiHEjQMdR](https://www.vertexshaderart.com/art/uDBqerAHTiHEjQMdR)

but it's missing the motion at the moment.

</comment><comment><USER11> If you appreciate other kinds of trees, here's a fractal pot leaf written in PostScript:

[https://www.donhopkins.com/home/archive/NeWS/leaf.ps.txt](https://www.donhopkins.com/home/archive/NeWS/leaf.ps.txt)

</comment><comment><AUTHOR> Obligatory mention that this shape could also be represented as a dual quaternion.

<comment><USER12> And is a dual quaternion simpler than a sine wave?

<comment><AUTHOR> It's more general and composes nicely.

</comment></comment></comment><comment><USER13> Very cool! Simple and elegant.

</comment><comment><USER14> Reddit thread from 4 years ago: [https://www.reddit.com/r/programming/comments/1tswai/t_sin_t...](https://www.reddit.com/r/programming/comments/1tswai/t_sin_t_christmas_tree/?st=JQ4CPBMT&sh=7574f3bc)

The neat thing is that /r/programming chipped in like a stone soup and improved it. It's surprising how small tweaks can make a big difference in rendering quality.</comment>