Onion creator here, happy to answer any questions!
Readit Newsyumaikas commented on Onion: Stack Language Compiled to Lua github.com/yumaikas/onion... · Posted by u/Bogdanp
yumaikas commented on JavaScript Views, the Hard Way – A Pattern for Writing UI github.com/matthewp/views... · Posted by u/voat
I've been working on https://deja-vu.junglecoder.com which is an attempt to build a JS toolkit for HTML-based doodads that shares some ideas with this.
I don't quite have proper reactive/two-way data binds worked out, but grab/patch seem pretty nice as these things go. Also, the way this uses templates makes it very easy to move parts of the template around.
It's also largely injection safe because it's using innerText or value unless told otherwise.
yumaikas commented on Core: an experimental new way to write videogames github.com/damn/core... · Posted by u/resatori
Godot is excellent, and I believe it will be the "Blender of game making" in 5 years or so. Version 4 is ready for prime time and is able to tackle most indie projects. Where Unity beats Godot is in the "Triple I" and "Double A" categories, as it has better 3D/performance features, tooling and add-ons. Neither engine is the best choice for AAA projects.
For 2D and simple 3D games, I see no reason to use Unity anymore; I predict a steady decline in Unity's market share as Godot slowly overtakes it.
In the GMTK game jam, there was a -dramatic- shift usage towards Godot from Unity this year
Location: Denver, CO
Remote: yes
Willing to relocate: No
Technologies: C#, ASP.NET, React, Typescript, JavaScript, HTML, CSS, Tailwind, Godot, Lua, Elixir, Powershell, git, Golang
Résumé/CV: https://junglecoder.com/downloads/Resume/AndrewOwenFullstack...
email: yumaikas94@gmail.com
yumaikas commented on Ergo: Erlang/OTP patterns implemented in Golang cloud.ergo.services/#Fram... · Posted by u/rapnie
This is interesting. When I think of a programming language I tend to consider it a tool to express an idea. The ideas from Erlang Behaviours (not being an Erlang developer), seemed to be a fairly generalisable. So I would have thought the language is not so important.
The example of C as the de facto cross-language standard (it’s not just in Linux), is also interesting. Creating a C interface imposes on a library author a set of restrictions in expression, but is anything truely lost in doing this?
I am much more interested in the concepts/ideas being expressed than I am the language being used to express it.
They are fairly generalizable, to a point.
The thing about Erlang behaviors is that they rely on several other pieces of Erlang to work well.
One big one is being able to be notified when another process goes down, or is aborted.
The other big one is being able to reason about state in the face of such failure.
Erlang decided to go with immutable data structures, shared nothing processes, and the OTP behaviors generally expect you to decompose the behavior of the various bits into functions that represent a single atomic step.
The more of those properties that you don't share with Erlang, the harder it will be to adopt OTP style semantics in your system.
yumaikas commented on Ergo: Erlang/OTP patterns implemented in Golang cloud.ergo.services/#Fram... · Posted by u/rapnie
Go’s concurrency model and Erlangs concurrency model are fundamentally the same.
Erlangs mailbox and Go’s channels are the same primitive.
And Erlangs processes and Go’s Goroutines are also the same primitive.
The big difference between the languages (from a concurrency perspective, there are other differences) is that idomatic Go is generally built around spinning off many short lived goroutines passing objects back and forth via channels, whereas Erlang generally spins off many long lived processes that represent objects, communicating mutation requests via mailboxes.
But you can do go style concurrency in Erlang, and Erlang style concurrency in go. You’ll just be swimming upstream the entire time, because your concurrency style won’t mesh well with any of the libraries out there which will be written in the idiomatic go/Erlang concurrency style.
So the idea you can create an Erlang style concurrency framework in Go isn’t actually surprising. Go and Erlang concurrency models are just opposite sides of the same coin.
So, the big difference between Go and Erlang style concurrency is that go style concurrency doesn't give you a readily available reliable way to keep an eye on other goroutines, as I understand it, where there are mechanisms in Erlang (links and monitors come to mind) to help accomplish that, and, in fact, it's one of the core parts of the Erlang model of concurrency
yumaikas commented on A first person shooter in 571 lines of GNU Awk (2016) github.com/TheMozg/awk-ra... · Posted by u/nequo
I wish there was like a "libawk" or something like it for programmatic usage. Its really a neat piece of work that is limited on being only a shell program.
At least, as far as I am aware, there is no programmatic interface
Where would you use this? Most languages have good enough string processing to imitate a lot of what AWK does
yumaikas commented on Sperm counts worldwide are plummeting faster than we thought nationalgeographic.com/ma... · Posted by u/Brajeshwar
Another lesson from your story (similar to many of my friends’) is to just have kids younger. It sounds like you started at around 35 — if people started at 30, even, fertility is higher.
I mean, a lot of people may not have the financial option to have had kids younger. Like, the last 15 years have included two "completely upend your life" level crises, along with a lot of smaller crises that could have swept up someone.
yumaikas commented on Monica: Open-source personal relationship manager monicahq.com/... · Posted by u/taubek
Author of Monica/Chandler here.
Thanks for posting this.
As others have pointed out, we are rewriting Monica from scratch, codename Chandler: https://github.com/monicahq/chandler
We've also written OfficeLife, an open source tool to manage your employees: https://github.com/officelifehq/officelife, yet to be released.
I think we have too many ideas and side projects :-)
Chandler reminds me of another, I'll fated PIM project, documented in Dreaming in Code.
yumaikas commented on There aren't that many uses for blockchains calpaterson.com/blockchai... · Posted by u/todsacerdoti
Isn’t this an argument for blockchains? If you could rely on blockchains instead of trusting based on past cooperation, you could save money and thus add more value. Obviously blockchains have a cost, but in some cases the cost savings you could achieve may outweigh that.
> If you could rely on blockchains instead of trusting based on past cooperation
What about blockchains would make them an effective stand-in for building trust over time? One is a ledger, the other is an interpersonal relationship, and the two really are not the same.
If I'm going to take a risk, I'd rather take a risk where there's some human expectation of managing bumps in the road, and which has some means of redress if sufficient malice is involved, instead of one where a smart contract bug means that I've lost a lot of money.