Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I finally escaped Node

acco.io

Post reply on HN
Print view View original

81–90 of 181 posts

Re: I finally escaped Node

#81

Post by akoutmos »

holografix wrote: post #69

Right now I’m trying to unit test an API on node that does a database query. I’m using express, mocha, supertest and typeorm. Mocking the database is fucking black magic. So I gave up and simply use an in memory SQLite db and add some records in the test body for my API to fetch and return so I can test. I’d like the db to basically get nuked and recreated after every test. So I use “afterEach” to close the connectio…

Testing with the database has to be one of the things I love the most about Ecto. No need to mock anything, no need to have special branching logic for test versus prod. Just use the database like you normally do. It gives you a degree of confidence that is on another level. Check out https://hexdocs.pm/ecto_sql/Ecto.Adapters.SQL.Sandbox.html for more info!

Re: I finally escaped Node

#82

Post by striking »

akoutmos wrote: post #81
holografix wrote: post #69

Right now I’m trying to unit test an API on node that does a database query. I’m using express, mocha, supertest and typeorm. Mocking the database is fucking black magic. So I gave up and simply use an in memory SQLite db and add some records in the test body for my API to fetch and return so I can test. I’d like the db to basically get nuked and recreated after every test. So I use “afterEach” to close the connectio…

Testing with the database has to be one of the things I love the most about Ecto. No need to mock anything, no need to have special branching logic for test versus prod. Just use the database like you normally do. It gives you a degree of confidence that is on another level. Check out https://hexdocs.pm/ecto_sql/Ecto.Adapters.SQL.Sandbox.html for more info!

Testing with the database isn't particularly efficient. If you have enough tests, it becomes worth it to mock whatever would touch the database just so the tests pass in a reasonable amount of time.

Re: I finally escaped Node

#83

Post by nickthemagicman »

egeozcan wrote: post #80

Javascript these days is a very productive language, especially with Typescript. Node however, with its lack of a remotely passable standard library, is not doing it justice. The async await is amazing and top level await works just fine in a browser console. The fact that node still has it behind a flag is... I mean, they surely have their reasons and I don't know enough to question the decisions of the maintainers,…

I think the author's argument wasn't that JS was a 'productive' language but that it was an overall poorly designed and bad language.

Re: I finally escaped Node

#84

Post by int_19h »

hnedeotes wrote: post #66
int_19h wrote: post #52

Earlier quoted context omitted.

Green threads are great, right up until the moment you have to interoperate with something written in another language / using another VM. Then it's a mess (see also: Go). The nice thing about async/await is that, because it's all just a bunch of syntactic sugar over callbacks, any language that supports some kind of callbacks with state, can be mapped to async/await - even C! On WinRT, for example, such interop work…

I think I might be missing what you mean? You can write an async/await implementation from scratch in a few dozen lines of elixir if wanted, but you also have Tasks that provide that already written for you (with support for being included into supervision trees, etc)? How does JS interoperate with something outside V8?

A JS library that wants to interop with something outside of its runtime (which is not necessary V8 - it isn't in WinRT, for example) can do so through FFI facilities. So long as said FFI supports all the same things that C does, it supports callbacks via function pointers. And if you can pass a function pointer + data pointer to some API, you have a stateful callback - i.e. a promise/future/task. And you can map any such abstraction to the same in another language.

But the moment you introduce green threads, the caller and the callee both have to be aware of that particular implementation of green threads. So even if you can do C FFI, and whatever you're trying to call can also do C FFI, you can't interop async calls across that boundary without some kind of callback arrangement.

Re: I finally escaped Node

#85

Post by int_19h »

willcipriano wrote: post #53
int_19h wrote: post #47

Earlier quoted context omitted.

"Most DBs" by what metric? If you count them as products, you're probably correct. But I seriously doubt that is true when adjusted for usage - say, number of requests per second, globally, across all deployed databases worldwide. (in fact, I suspect that SQLite would win that contest handily.)

SQLite is in every android phone, it wins by a mile. I'd even go as far to wager that MSSQL instances alone outnumber Mongodb or Dynamo by a good margin.

SQLite is also in every Win10 install. And in every Firefox install, IIRC?

Re: I finally escaped Node

#86

Post by Fellshard »

ClawsOnPaws wrote: post #12
benlumen wrote: post #8

I'm just getting in to Node, coming from only having used PHP and then Laravel. Is it a bad time? Using Sails.js for rapid prototyping.

No. Node is very widely used, it does work, and of course: A thing nobody criticizes is a thing nobody uses. I think you should be fine.

Except the criticisms for Node are many and widely spread.

Re: I finally escaped Node

#87

Post by purerandomness »

robin21 wrote: post #10

> data structures Spending too much time upfront thinking about the perfect data structure is a bad idea. Long walks on the beach and fasting is not going to deliver your perfect data structure. People (other than yourself) using your product and observing evolving requirements over time will reveal an optimal data structure. Rapid iteration and real-world usage is the key. I can’t count the number of times I thought…

> Why use a gendered pronoun here?

Alternating pronouns in the English language is a concept to emphasize the "randomness" of the gender. [1]

[1] https://english.stackexchange.com/questions/279494/do-any-st...

Re: I finally escaped Node

#88

Post by napsterbr »

striking wrote: post #82
akoutmos wrote: post #81

Earlier quoted context omitted.

Testing with the database has to be one of the things I love the most about Ecto. No need to mock anything, no need to have special branching logic for test versus prod. Just use the database like you normally do. It gives you a degree of confidence that is on another level. Check out https://hexdocs.pm/ecto_sql/Ecto.Adapters.SQL.Sandbox.html for more info!

Testing with the database isn't particularly efficient. If you have enough tests, it becomes worth it to mock whatever would touch the database just so the tests pass in a reasonable amount of time.

> Testing with the database isn't particularly efficient.

Anecdata, but my experience with Ecto sandbox + thousands of tests says otherwise. Mocking would be faster? Probably. But IMO not worth the effort, given it's already fast enough.

To be fair, I have worked with Elixir codebases that generated humongous amount of data per-test, only to test a fraction of this data. This kind of test was slow, but it would be much more efficient to generate only the data you actually need.

Re: I finally escaped Node

#89

Post by papaf »

mtberatwork wrote: post #26
rockyj wrote: post #20

From the title, I was expecting the article on something along the lines of how, where and why developers can move from Node.js. However the arguments are not so solid and there is no migration path. We all know Elixir is great but the adoption and maturity is low as compared to JS. Yes, Node is not perfect but (with TypeScript added) tell me a development platform that can run under 100 MB of memory, handle most req…

> tell me a development platform that can run under 100 MB of memory, handle most requests under 50 ms, can spin up a http service in a day or so and still perform well under load (and scales horizontally with ease). I'll plug Vert.x here but just about anything these days depending on your workload. > can spin up a http service in a day Surely this is a typo?

I know Vertex has a reputation for being lightweight but 100MB for a JVM webapp seems unrealistic to me.

For instance, a barely used Jenkins needs 200MB.

Re: I finally escaped Node

#90

Post by marcosdumay »

int_19h wrote: post #52
hnedeotes wrote: post #5

Earlier quoted context omitted.

> You know what's an even worse cognitive overhead? Languages without strong typing, like Elixir. I see this mentioned many times, but when I do my impression (which might be wrong) is that you haven't written Elixir or Erlang for any thing more serious than tutorials or docs examples. Besides, elixir is technically (?) strongly typed - but not statically typed. Regarding async/await, compared to the things you get i…

Green threads are great, right up until the moment you have to interoperate with something written in another language / using another VM. Then it's a mess (see also: Go). The nice thing about async/await is that, because it's all just a bunch of syntactic sugar over callbacks, any language that supports some kind of callbacks with state, can be mapped to async/await - even C! On WinRT, for example, such interop work…

I don't know why green thread based languages do not export a pooling interface on their FFI.

Pooling much nicer interface to implement than callbacks, and a quite easy concept to plug one interface into another.

Post reply on HN