_ar7

Yeah I second this. Despite having a superior type system, flow is so behind in both tooling and 3rd party library definitions it's really hard to justify continuing to use it over typescript. It's weird to say, but the unsoundness of typescript doesn't matter much next to all the other advantages.

Besides, I feel like if I really want a strong type system https://reasonml.github.io/ might be the better choice over flow.

Really cool that this is built completely from scratch. I expected a dependency on something like d3 at least.

This is why electron is so popular

My question would be what's the alternative? Cross platform native apps rarely look as good, and would require entirely new code bases and different sets of developers. Sure electron sucks for users, but what's the business incentive to ship native apps other than to satisfy the minority of users who are even aware electron saps so many resources?

I think that for whomever is developing using electron in most cases the desktop versions of the apps wouldn't even exist if electron wasn't a thing. Also, just as a side note, electron apps are so _easy_ to develop. I don't know if any other platforms that target desktop are as simple, but I might just be out of the loop.

facebook

So if we were to have a rational debate, what points did he have, and points did his opponents have?

Although it wouldn't work if you were using objects and wanted to do a deep comparison e.g.

    [...new Set([{x: 1}, {x: 1}])]

If you wanted to do O(n) functionally, you could do

    [1, 1, 2, 3, 4].filter(
      (obj => x => {
        if (obj[x]) {
          return false;
        }
        obj[x] = true;
        return true;
      })({}),
    );

What's happening is that you're passing an object (hashmap / hashset) into a function that returns a filtering function, and that object is used inside the closure to track the dupes. It's still a pure function because even though you're mutating the passed in object, the filtering function is still deterministic and referentially transparent.

Yeah you're reading it wrong. This is for node so it'd never be client side, and I'm sure the pw examples are in plaintext just for simplicity in the README.

All those machines are owned by Google or Apple though. They're not completely random machines.

Really liked the blog post. Elixir and the capabilities of the BEAM VM seems really awesome, but I can't really find an excuse to really use them in my day to day anywhere.

Lol now I feel bad for perhaps coming off a bit too harsh. I appreciate you taking my feedback into consideration. Best of luck with your company!

* Why do I have to download an 8MB payload on load, most of which consists of 1MB+ PNGs, which aren't even visible until I scroll?

* Why are you doing some unintuitive scroll-jacking?

* Why are you using React for literally a single scrollable page?

* Why are you putting the scroll position into the URL instead of somewhere like local storage? It's annoying that I can't even leave the page without pressing back multiple times.

ugh

Operator mono I think. It costs a lot.

Short answer is yes. TypeScript to JS is kinda like C++ to C.

You can learn one before the other and a lot of the skills are transferable.

Because JavaScript

1. By far, has the largest ecosystem.

2. If you use a linter, a typechecker (TS or flow), and transpile your code (TS or babel or both), JavaScript is actually a pretty nice language to work in.

Sure it's a chore to set up all the initial tooling, and learn the ins and outs. However, once you're past that, it's usually not worth it to switch.

Could you elaborate on the zero allocation part? I made a CSV parser based on yours [0] before the 1.0.0-beta rewrite, and at the very least I have to allocate as much memory to hold a single field in the CSV (and then reuse that memory).

[0]: https://github.com/AriaFallah/csv-parser

Ah true. I guess what I was really getting at was that even though JavaScript has some fundamental missteps, it's not beyond being fixed and definitely not the worst language in existence i.e. that behind the quirks, is a quite nice and powerful language that isn't a waste of effort.

It sucks that all of this is valid, but it's mostly avoidable. Eslint + Flow/TypeScript will catch most of these quirks for you.

Also lets not pretend that having a bunch of quirks like these is exclusive to JS. I'd say there are equally as many ways to shoot yourself in the foot in many other languages. For example, for C++, which isn't necessarily beloved but people don't want to "eradicate" like OP's comment states about JS, you can have an entire talk[0] on the quirks of type deduction.

I think where JavaScript earns its bad reputation isn't necessarily its quirks, but its quirks in combination with a low barrier to entry, lots of beginners, a large community, being a multi-paradigm language, and the fact that most people writing it were forced to write it because it's the language of the web not because they wanted to. All that in combination results in a lot of bad code...but if you take the time to learn it and use a bunch of tooling (which isn't ideal), it's actually quite nice.

[0]: https://www.youtube.com/watch?v=wQxj20X-tIU

Most of the issues you listed with the language itself are fixed by using either Flow or TypeScript. As for that V8 issue, it's not ideal, but how about just putting comments of that size outside of the function, or not overcommenting functions small enough to be inlined.

I know a lot of people view using so much tooling as a con of the language, but if you use Babel + Eslint + Flow/Typescript, JavaScript becomes a lot nicer and safer to program in. For small to mid-sized projects, I think JavaScript is pretty great.

Was it https://fugue.co ? I think they use Haskell for their DSL

I agree with the general sentiment, but, to nitpick, Facebook uses/is transitioning to http://hacklang.org/ to avoid PHP. They literally wrote a whole new language and built a VM to do JIT compilation of that new lang just to not have to continue using PHP.

I hope you didn't just throw https://github.com/postgraphql/postgraphql and https://postgrest.com/en/v0.4/ behind some closed source code and called it a business.

What's the motivation for the schemas? Are they just verifying that the APIs haven't changed and are still returning what you'd expect them to?

I read through https://github.com/singer-io/getting-started/blob/master/SPE..., but I'm trying to better understand why they're necessary.

A multithreaded CSV parser which figures out the types of each column. It's part of a larger project, which is basically Excel, but you use SQL since the sheets are put into an actual database. It's useful for when you need to clean up, manipulate, or query spreadsheets.

I know it's probably been done before, but the goal of the project is to familiarize myself with parsers, multithreading, making a C++ project in general, and the newer features of C++11/C++14.

Almost every website I visit except HN seems to be down...