I feel like because of Go's concurrency model, a standalone version of Phoenix Channels (without all the MVC stuff) would be possible to implement.
122 karma · joined March 22, 2019
I feel like because of Go's concurrency model, a standalone version of Phoenix Channels (without all the MVC stuff) would be possible to implement.
As an elixir/erlang enthusiast, haven't we just reinvented BEAM and observer?
Even if I were a globe trotting immortal, I cannot legally DIY most common electronics because of patent law.
No one can DIY everything.
It's ransomware with a commission scheme.
> It’s curious to note that the program offers a 60-40 split in profits, with 60 percent offered to the customer. However, the gang is willing to negotiate up to a 70-30 split for customers that are considered more “sophisticated”, researchers say.
I don't actually have the author's usecase though, I tend to build microservices in Go!
A Diary of a Napoleonic Foot Soldier[1] is a hellhole.
https://www.penguinrandomhouse.com/books/185435/diary-of-a-n...
If not please correct me.
I was talking to some kid who wanted to be a developer, and I echoed this sentiment. A complex tool with good documentation is easier to use than a simple tool with bad documentation.
Until then iteration makes way more sense than recursion in JS.
At work, on OSX, VSCode has been fine though. Still, I've never run into a situation where nvim is slower. And I use a good many plugins (deoplete, ALE, ctrlp, fzf, and 5 sets of language specific plugins).
I hate it but I'm no Java expert.
This is my feeling too. Composition and JSX beat logic in templates.
Though I've seen some pretty hairy React, I still prefer it to badly implemented template files.
I've also heard that graph dbs are better for social data than relational dbs, though I don't know the details. So I guess another use case is you are Facebook.
On paper, Pheonix should be the default choice for large and small web/mobile MVC applications. I think the question of if that becomes the case is directly tied to adoption of Elixir.
What causes OOP to be well suited for finance's use case?
What are the short-comings of structs/interface methods that Go! provides in the financial space?
If Go! had generics, would that change it's suitability for finance?
I would think that first-class concurrency would be useful in that space, is it?
The intresting thing is there's no specific source of "piety" in the religiously/ philosophically divided West. Even if someone's moral failings get exposed, currently, every devil has an advocate.
That said, SO is still a wealth of information.
Of course, nothing beats Google, but if the docs are good (big if) you tend get a deeper understanding of your tools.
I gained a ton of productivity when I started creating a set of helper functions, examples, and gotchas for each language / domain I work in. I used to use a network call helper in JS for ages to remember all the different ways errors can bubble out of fetch. I also have a file with a bunch of ML algorithms, cause there's no way I can keep it all in my head, but I don't want to forget the right tool for a job.
I'm still self depricating, but my 'babys_first_elixir.exs' has been invaluable resource for me to dump interesting funtional patterns into while reading other folks code, then referencing when it's time for me to write.
I get that the main story is about a debtor and credit, but the concept of stratification based on surveilence-data is word-for-word 1984.
[1] https://www.reuters.com/investigates/special-report/muslims-...
It's so Orwellian. All of it.