anko

> Node.js is 13 years old now.

> But at this point it's established, mature technology

I have to disagree. Day to day I maintain a variety of node.js, scala and kotlin services. By far, the most gotchas have been from the node.js services.

Simple things like validating incoming payloads are made ridiculously complex. You can get a library to do that, but which do you use? And then most of them don't export the typescript type signature so you don't get any type safety unless you re-define the type in typescript.

Let's say you want a tiered caching library? I've spent weeks of my life debugging concurrency issues because the memory store shared objects whereas the redis store didn't (because they were serialised and sent to redis). That's on the most voted caching library for node.

The quality of node.js libraries in general is far below that of scala/kotlin, and the maintenance cost is way higher. You can't easily tell if signatures for the apis of the libraries you import have changed as well. The ecosystem is still moving very fast, and while I agree that es6+ makes it a much better language, it causes its own issues when interacting with older code/libraries.

Expressive as the language may be, in production systems it leads to poorly understood code because of all the ways to do simple things, and the gotchas associated (something i believe it shares with scala).

> The multi process concurrency model is sometimes a pain in the ass and sometimes just want you want.

Give elixir a serious go and see if you ever say this again. Concurrency should be managed, much like garbage collection has been for 30 years.

does anyone have any similar articles targeting arm64 (m1)?

I think that's a good idea as long as it's balanced. A list of things you can't do is reasonable.

btw, you can do nfc beyond payments on ios and have for years; https://developer.apple.com/design/human-interface-guideline...

I agree.

I think most of arguments against what Apple is doing are based on an incomplete picture of Apple's product. They are based on someone not appreciating an aspect of what Apple is doing. Maybe they don't like the price. Maybe they don't like a lack of complete control over their hardware. The rest of it is always a rant to justify that position.

There is provable value in what Apple is doing, or the app store would not be a success. Some people just want to have their cake and eat it too.

any idea what liquidmetal is used for?

When i was a youngster, back in linux kernel 2.0.33 days, I hacked my kernel so that it spoofed traceroute.

When it was going to send an ICMP time exceeded, it would change the source ip to the next one in a list of curious ips. Simple change but taught me heaps about network programming, the kernel, c, etc..

I wonder if the management at google actually use their products. If they did, there is no way they would allow them to be killed.

Apple's senior staff definitely use their products.

I agree it's not honorable. But if he wanted to protect what he made he should have at least registered the trademark. By not registering the trademark you're saying that you don't care.

that's really cool, thanks!

how about for an optical switch? for switching network packets over fibre?

Any idea how the neural engine does vs the gpu?

From the article;

> You could of course say that it’s “a slippery slope” sort of argument, and that we should trust Apple that it won’t use the functionality for anything else. Setting aside the absurdity of trusting a giant, for-profit corporation over a democratically-elected government,

And then later it reads

> and has previously cancelled their plans for iCloud backups encryption under the pressure of FBI.

Isn't the FBI in place because of the democratically elected government? It seems like the for profit organisation is trying to do the right thing, and the government is stopping them.

This is the fundamental problem with arguments based on "trust" - the government seems to be doing the wrong thing.

Why is that so important?

1) in production, hosts like aws have cheaper options for arm based compute 2) software emulation on m1 is largely comparable to native x86 performance, certainly per watt.

wow thank you! this was great to see

If you've come from java and you like node, maybe you should spend some time with the alternatives?

A big part of it depends on what your exact requirements are but my experience with node didn't bite me for quite a while.

1/2) my experience is that even the supported packages have had glaring holes where they don't in other languages. Just to give a quick example, I had a project that used node-cache-manager to implement a tiered cache. There was a bug (in the cache library with the most stars) just last year where the cached values in a memory cache were passed by reference as opposed to copied. That meant any mutation on them affected other fetches from the cache! That would never happen in java. This particular bug took weeks to debug in production because values were being randomly mutated. After the fix, it also had different behaviour for when the cache value was new vs when it was retrieved. So two mutation bugs in the same cache codebase see https://github.com/BryanDonovan/node-cache-manager/issues/13....

I'm not blaming the author, he's a really good guy. What i'm saying is this is a wart both in the language and the library ecosystem - it's not unreasonable to expect a sensible caching library.

3) I agree that threads aren't necessarily the way to go. But can we agree that a language that CAN efficiently take advantage of multiple cores would be better? It's not just for your application. It's also for any compiling eg. typescript!

> Just check out the recent GitHub report where they were accidentally leaking information from other users into their sessions.

Concurrency is hard! except in a language where it isn't. In elixir each "thread" (erlang process) would get a different copy of the data so this type of bug doesn't happen.

4.

> Typescript (combined with autogenerating typescript type files from GraphQL schema definitions) has been honestly heaven for us, and the benefits I've seen with the structural-based typing of TS made me realize the huge number of times I had to battle the nominal-based typing of Java and the immense pain that caused.

That is an interesting assessment. I've never really noticed a difference in practice between structural/nominal type systems to the extent that i didn't realise typescript was structural. Normally if you have multiple classes implementing the same structure, you want an interface anyway to make sure they don't diverge i.e. there is a higher purpose for them being the same.

Would you have an example of how this would be a deal breaker?

I think besides this aspect, Kotlin might be up your alley.

Quite often I use the search to find a string across projects (we have quite a lot of microservices).

It would be great if you could exact match and also if the results would be from master by default. Quite often it puts me in a commit and I have no idea why or if it's still current.

I'm not the parent poster but I'll have a go. Please feel free to correct me if I've got parts wrong, I'm hoping to learn something too.

In other languages, lets say Erlang as an example, actors themselves do not have concurrency concerns. The receive loop/handler just executes everything as though it's single threaded. The code is very easy to reason about. It also applies backpressure in that if your synchronous loop is blocked, your mailbox will fill up.

If you need concurrency, it's done by talking to other actors, which can be processing on another thread under the hood. But the thread part of it is managed and you are not dealing with threads per se, you just know that if you have multiple cores and you send a message to another actor, it can be scheduled to run on another core safely.

If you want to run a bunch of tasks in parallel, you could use a pool of actors up to around the number of cores you have, and the parallelism is at maximum the number of actors in the pool.

Sorry if i'm over explaining, I just wanted to set the stage.

One of the benefits of this arrangement is if something is going slowly you can order the list of actors by biggest mailbox and you can see where your bottleneck is. And if you are using a lot of memory you can just order the actors by the memory usage and you can see where the big state lives.

With akka actors, instead of just dealing with the actors and actor pools, they suggest you make actors non-blocking. The way you do this is with Futures. Suddenly all the simplification of the actor model goes out the window. It mixes an async programming style with an actor model that doesn't need to be async! So you have the negatives of asynchronous programming and very few benefits of the actor model. I realise

How do you identify the bottlenecks of the system? Maybe your execution context is full - actually I'd love to know how people debug their execution contexts in general.

Last I checked, execution contexts would spawn new threads as well, so not only are they heavyweight (compared to erlang processes) but you have the operating system schedule them instead of the thing that knows how to best schedule them which is your language runtime.

https://github.com/oblador/hush if you use safari :) Basically the regulations say that if a user doesn't respond to this popup, by default all the cookies are rejected except the ones the site needs.

This app hides the popup :)

I'm no expert but put too many extensions in there and you're looking less like RISC and more like CISC. It would make more sense on x86 platforms.

Besides the ridiculous ranting, a lot of the problems aren't bluetooth per se, see Apple's W1 implementation. With Airpods Pro and an iPhone I get near instant setup, great range, etc.

It's also that sometimes they stay on that codebase because they weren't the best engineer, and all the better ones move on to bigger things.

do you think having lower altitude satellites will help with the jitter much?

> What you are saying is about iteration in the language and does not have anything to do with concurrency or architecture.

> There is also nothing difficult about avoiding infinite loops in C++.

I don't know how to explain it to you if you think you get it already but you don't. Please come into the discussion with an open mind.

Making sure every library you use won't ever block a core is not trivial. If it's a feature of the platform, then it becomes trivial. On Erlang it's a feature of the platform, in c++ it is not.

I get what you’re saying but it’s not fully right. In c++, the language allows you to have infinite loops. In erlang/elixir you can’t - you need to do recursion instead. This language feature makes sure that one piece of code doesn’t lock a core indefinitely.

That’s why Java/scala’s akka is crazily complicated. They encourage you to use futures so you don’t lock a core! So suddenly you’re still dealing with concurrency but with even more complicating layers.

I think you're missing the point.

There is no problem with multiple stores existing as a model. In fact, on android you can have that. If you like multiple stores, and you want the hassle of using reputation services to manage which things you trust, that's fine. Nobody is saying that you can't.

But by going against Apple's store as part of the platform model, you want to stop people from having a simpler option.

They are deciding that simpler option when they buy into the platform. My mum HATES PCs but loves her iPad because she doesn't have to deal with antivirus updates or downloading dodgy software. She doesn't have to understand multiple stores.

With a multi store model, there is an incentive for competition on store pricing. How do you compete on pricing alone with other stores? You reduce the quality of your review process. It's the only way to compete on cost. And that's what forcing multiple stores does.

It's amazing how much easier it is in erlang/elixir.

having lightweight isolated processes and no (or little) shared mutable state matters a lot. :)

That's arguable. For the top developers it's about 48% more on app store see https://www.valuewalk.com/2019/06/ios-app-store-vs-google-pl....

And Google's play store has value to Epic too - they started by only allowing Fortnight to be side loaded, and moved to the play store.

I suspect that the reason lots of people prefer these devices are precisely because of the app stores. They have confidence that they won't get viruses, confidence in the payment process, ability to lock down devices for kids etc. The ecosystem clearly has a lot of value.

This whole thing is about money. In the first year Epic made $500m from fortnight on ios. Of course they want a larger piece of the pie - Apple got $214m.

if you need to do some batching operations such as read from a queue, do some processing and publish to s3, I can recommend Broadway https://github.com/dashbitco/broadway

I have seen lots of codebases in lots of languages do this type of task, but aside from maybe spark on the high end, i haven't see it done better.

The beauty of erlang is your code reads like synchronous code so it's easy to read/maintain, but it has all the power of the parallelism of async code.

They aren't that accurate and actual promote bad prescriptions - they tend to suggest higher myopia and astigmatism.

https://pubmed.ncbi.nlm.nih.gov/16815252/

https://en.wikipedia.org/wiki/Autorefractor