A full-stack generalist with 26 years of experience.
I currently hold a position as a Software Architect at a software consultancy, but I'm not attached to the title. I can quickly prototype things on my own, making me ideal for bootstrapping startups, or I can assemble and train a team.
For the past 7 years, I've primarily been working with, and am most proficient in, TypeScript, React, React Native, iOS/Swift/ObjC, Node.js, and Postgres. I've worked with many other languages and technologies and can easily pick up new ones if needed.
Here is a list of some other languages and technologies I’ve worked with previously: C, C++, Ruby, Rails, Lua, PHP, C#, .NET, Java (J2ME), OpenGL, WebGL, Cocoa, Qt, QML, MFC, ATL, QNX, Linux/Windows device drivers, Blockchain (miner development, wallet integrations, monitoring, Solidity), etc.
Fastify is absolutely fantastic. It has the concept of "type providers", allowing you to pair it with fastify-type-provider-json-schema-to-ts (for JSON schemas) or another typing system of choice, such as Zod, to obtain strongly typed queries, request bodies, and responses in handlers with TS types derived on the fly at compile time. It also validates data returned from handlers to conform to schemas, reducing the likelihood of accidentally leaking sensitive information. And it's faster than Express, even with validation.
If the interview is structured in a way that overloads your short-term memory, which is often the case, you'll have problems remembering things from a long time ago. Ask someone questions about recent events for a few minutes, and they won't even be able to remember not only what they worked on in projects many years ago but also their grandfather's name. Everyone has this problem; it's just how memory works, and poorly structured interviews trigger this effect. A workaround is to prepare beforehand and keep a list of things to talk about nearby.
Another approach that can work is to give your memory a bit of time to adapt. For instance, if you're asked to share a story from the past and you don't have one prepared and can't recall anything, suggest starting by discussing your past in general. For example, list the projects you've worked on and briefly describe them. You will feel how, during this process, the ability to recall events returns.
I think mine were. I strained my eyes really bad over days of work, and then one day before going to sleep rubbed them. When I opened the eyes, I seen a brown clot in the middle of vision which after a month of treatment with eyedrops fell apart into lots of floaters / worms. 2 years later most of them dissolved, but some remain and vision is blurred a bit. It also turned out that most people I asked have floaters too, but if there aren't many, they're filtered out by brain. If you aren't looking for them specifically, they aren't visible. They are hard to unsee though once you seen them, so better not to try. )
Eyedrops name of which I don't remember, but I can try find if needed as they're commonly prescribed in Russia for this condition. I wouldn't recommend them though as turning a single clot into long wormy things was scary and annoying. I seen similar complaints from others who were prescribed these eyedrops. I'm not sure if they helped with dissolving the floaters, as I had smaller recurrence recently and not used any eyedrops and it's still slowly going away. Btw, if floaters are in the center, try moving the eyes up and down 10 times in succession - most of them should stick outside of vision.
I also think so. Often script needs to access a file in actual current dir (for example a config file) or process files with relative paths supplied by user and changing working dir makes this hard.
I think an easier way is to find script's location and construct paths for accessing script dependencies, for example (works on Linux & macOS):
Location: Europe (PST is also fine)
Remote: Yes
Willing to relocate: Yes
Technologies: TypeScript, React, React Native, NodeJS; Swift, ObjC, C++
Résumé/CV: Upon request
Email: afidrya81@gmail.com
Hello! My name is Andrey, I'm full-stack dev with systems programming background. Nowadays, I specialize in web app development and native apps for iOS and macOS, can adapt to your stack or do something very niche / low level (write a device driver etc). Please let me know what you're working on and I'll describe my relevant experience.
Looking to join a team as a full-time contractor on a 3+ mo project. Small teams / early stage startups preferred. Relocation is possible if needed.
In simple words, he should have called a smart contract's function which would withdraw his tokens and send real ETH to his address. Instead, he sent tokens to smart contract's address and they will stay there forever, not associated with any account.
This complexity should be abstracted away by wallet's UI. Users don't have to call APIs directly.
Also, this whole situation could be prevented by trying to send a smaller amount first.
I've written middleware APIs for accepting currency in carts and casinos that interfaced with / polled bitcoind and other daemons. Why on earth would this person be calling APIs directly, and why would the daemon not just reject the transaction if it's an unexpected kind of token? Or if he added funds to the contract why not be able to remove them to the same address? I never dealt with smart contracts but even allowing this to happen without an error seems like a crazy, terrible design.
from the reddit comments, similar question, apparently every instruction adds gas fees to running the contract, so if you're going to use the contract a lot, you leave out any kind of validation.
>> Wow why didn't the contract creators think this through and block requests to the contract
> Because adding that check would increase the cost of every user transaction. All AMM swaps would be done with WETH so it’s the right call to not have it in there
There are, of course, other industries with financial incentives against safety features. We usually regulate them.
We can point and laugh at this one person, but according to the reddit thread they're the 265th person to make this mistake, and more than half of the money in the inaccessible account is not theirs.
And that's just for this particular token. You can go to just about any token contract and see how numerous people have sent their tokens to the contract address itself.
I hadn't even thought about this. With BTC early on, the only party to really benefit from lost coins would be "Satoshi", but his coins weren't worth anything until the currency took off anyway, so it was more important and long-term profitable to build a system that didn't lead to user anger than one that would lose coins to deflate what was already a deflationary currency. It really does show how slimy the whole cryptocurrency world has become.
I really can't think of an expression other then "lol" to sum up my response here for just how incredibly stupid this is, as a "platform of the future".
A design which actively discourages robust programming and error handling in financial software. Wow.
Ok… but then if you’re going to throw out these cases you should also address how markets can fix these issues, such as great customer service: “when I fucked up they helped me out, they’ll get more of my business”, or maybe insurance, or just better products that don’t have these issues.
Idk why people conflate libertarianism with this hyper-individualist stuff. It really isn’t the case.
Why should this person get anything back? Code is law. And if code is law all bugs are also law.
The half million was a fair and just transfer. Whoever is the recipient is fully deserving both morally and ethically of their new-found wealth.
If I was on the receiving end of this transaction, I’d thank the sender for the money and move on with my life. Of course I’d never be in the position to receive the funds because I’m not stupid enough to play this game—odds are very good I would be the one who sent half a million dollars by mistake!
I mean, I think I’m joking but not really. If you want to practice “code is law” and really mean it, this is the kinds of stuff that will happen.
The one who has the private keys to that account could give them the ETH back, yeah. But if no one has the private keys, they can not get it back, that would defeat the entire point of cryptocurrencies in the first place.
There are two types of accounts in Ethereum, externally owned accounts (EOA) and contracts. EOA are controlled by private keys where contracts are not. Since the user sent ETH to a contract, he cannot get his ETH back if the contract does not have a method to transfer ETH back. Whereas if he sent ETH to an EOA then the user of that account can send him back ETH.
But of course they can - if they are the right persons, that is. (See DAO hack. Of course, that did defeat the whole purpose of smart contracts but nobody was willing to notice.)
> See DAO hack. Of course, that did defeat the whole purpose of smart contracts but nobody was willing to notice
Of course a lot of people noticed. The problem is that cryptocurrencies are currently primarily functioning as investment object rather than an actual secure financial ledger, which is why the interest of investors will trump purity.
Low-cost insurance is an interesting idea that might actually work to smooth over some of the hard edges of "code is law".
It ought to be possible to craft an insurance policy that would pay out the $500k (or equivalent WETH/ETH) in cases like the one in this article, where the transparency of the ledger clearly shows that the tokens are unrecoverable.
As insurance companies are notorious for declining to pay out, the clear evidence trail would be helpful to allow the insuree to take the claim to a regular court for a human decision on its validity.
Not really. Having the option of a lawsuit is just a backup; the possibility is what makes sure the insurer chooses to pay without one.
An insurer that knows when it doesn't have a case and will be forced to pay (plus costs) when there's clear evidence of coverage and loss will almost always pay without a fight.
However if there are high-value decisions which are not so clear cut, then having the option to go to court or some other mediation system to settle is quite useful. One of the critisms of "code is law" is the lack of mechanism for nuanced, human intervention when something unexpected happens due to a bug, design flaw or unexpected consequence that turns out to be unreasonable.
Code can screw up at scale. And at this point if you’re capable enough to understand the edge cases and offer insurance against them, the insurance went really cover that much.
Markets don't care and they will not fix these issues, because suckers losing money is a much better market proposition than losing money on customer support.
Fo go ahead and learn some history, will you? Almost every single regulation we have in place is precisely because markets never ever fix things.
And yet, disputing charges via your bank and issuing chargebacks via VISA/Mastercard are things that definitely exist and work perfectly fine. And as long as there is no equivalent function in crypto, it won't be suitable as a currency for general use.
And no amount of mocking faux laughter will change that.
Cash transactions are done locally when you can typically inspect the object of the transaction before paying. That's why there is not the same need for these kinds of protection.
Crypto combines the worst properties of cash and wire payment into a package that has no customer protection and is almost tailor made for scammers.
There are customer protections in the form of 1) escrow 2) seller reputation 3) seller depositing some risk capital at a selling platform. That said, customer protections have never really worked for me in fiat world.
That is not entirely true. Stock exchanges will reverse some clearly erroneous trades, even when they are not required to by law, because people trade more when they feel protected against mistakes.
There are plenty of do-overs, it's called the "development phase" and involves testing things on your local computer with the team.
No one gets everything right the first time, but with a lot of testing, you can actually write software that does exactly what you think it will do, and you can achieve pretty cool stuff. Remember that humans wrote the software that took humanity to the moon!
As we know, no software has had bugs caught once launched to prod. The existence of some software that worked under this model is not evidence that it is a good model. "Just test prior to release" is not a complete solution.
Are you talking about the user from https://www.reddit.com/r/ethereum/comments/sfz4kw/did_i_just... ? And do you mean "read-only memory"? I'm not sure how that's relevant. The contract they made the transfer to is read-only yes, like any contract on Ethereum. But they could have tested the contract call with a smaller sum before actually performing the bigger one.
Just like the people writing the computer that took us to the moon, I'm pretty sure they tried it before in small-scale simulations before hooking it up to the rocket and letting it go to the moon.
The idea that people need to treat financial transactions in crypto as if they were writing software for a moon mission shows how impractical the entire space is.
If that was the case, I'd agree with you. But as outlined in the comments of this submission time and time again, it was not what happened here.
The user was not doing a normal transfer (at least, they didn't want to, but they ended up doing). They didn't know what they were doing at all, a simply Google search would have showed them the way. Using UIs instead of interacting with the contract directly would have prevented them from making the mistake they did. Doing a small test transfer before doing the big one would have revealed what was wrong as well.
It's not that I'm comparing writing software for moon missions with making cryptocurrency transactions. I was directly replying to mox1 implying that writing 100% correct code is impossible and shouldn't be attempted.
Yeah, because NASA has been utterly fucked by the congress. Because of politics it's better for NASA to spend 5x the money on 1 reliable spacecraft than to build 5 slightly less reliable spacecraft out of which only 1 fails.
Even if the economics of it don't make sense, NASA can't afford to be seen failing because because politicians will not want to fund them.
I guess my point is that NASA is an exceptionally badly managed entity, not something you'd want to aspire to. (Of course the people working at NASA are not the ones to blame for this.)
>Money matters a lot. Should this mess endure, people will forever be saying a little bit of gas would have been worth it.
That gas would probably add up to more money than has been lost here.
>And we've people with six figure arguments as to why such a check makes sense.
The gas fees of such a check would probably be higher than the losses averted, especially in the long run. And any "losses" are essentially distributed among all ETH holders anyway.
"The gas fees of such a check would probably be higher than the losses averted, especially in the long run. And any "losses" are essentially distributed among all ETH holders anyway. "
Of course not. There will be more advanced software for expert users that allows them to manually create potentially riskier transactions. That's perfectly fine.
Client software targeting end-users should have such checks.
This really doesn't line up with the reality of how most people are congregating around user friendly wallet software and steering away from the more advanced options.
You only one need one wallet software to be the official WETH-approved client, sucks for anyone else risking their money with unsupported software.
We shall see. And for me, safely and at a distance.
Frankly, the small cost of robustness in contracts should have been factored in from the beginning. It just does not need to be so damn lean and rickety.
The incentives are wrong here.
My prediction is the current state of affairs all gets ripped up and replaced after a time. And until that happens, we are likely to see activity largely limited to people who have a healthy appetite for risk.
Perhaps it all is as it should be too. Had the reverse been done, emphasis on slightly more expensive contracts that are robust and able to deny the costly errors, I would imagine others clamoring for people to adopt the rock bottom lean stacks...
There's a ton of money in providing good wallet software. Many people are making a killing by offering good UX, as offering good wallet software puts them in a prime position to offer profit-generating value added services like currency swaps.
>Frankly, the small cost of robustness in contracts should have been factored in from the beginning. It just does not need to be so damn lean and rickety.
It really doesn't seem necessary, more complicated contracts require custom frontends to interact with anyway.
There are 0 do-overs on smart contracts in production. No stopping the network for a minute to triage, no rolling back a minute, no circuit breakers. No "Error 1202, do you want to continue?" pop-up messages.
Back in the day or at least when I ran my own bitcoin node, any call against the blockchain was free. This sounds like someone charging for hitting the API on a rented node, as opposed to an actual cost imposed by the currency to consult the blockchain (?) But maybe the contract-generators aren't even running their own node, just piggybacking on someone else's API. Sure. Cheaper.
AFAIU, smart contracts on the ethereum VM can be arbitrarily complex, so you pay the network to execute them, or a random user with an infinite loop would bring down the network.
You are indeed renting a machine to run some code, and if you want many people to use your code you want to make it cheap. There's a trade off.
You can fuck up things on the BTC blockchain too, "burning" crypto by sending it to a dead address has been a thing for a long time.
It always seemed stupid to me that it was possible, compared to sending money to an invalid IBAN, but I'm not a crypto enthusiast so I may be biased.
On BTC, you could send things to the wrong address, yes. But you can't send the wrong type of currency or send it to a nonexistent address. In this case it seems like the contract has created the black hole (not the Ethereum blockchain itself), but that's even more absurd since someone ultimately should have control over everything that was put into the contract, regardless of the source.
Sending currency to non-existant addresses is how people encode arbitary data on the bitcoin blockchain, so definitely possible.
Giving a person control over the funds allocated to their smart contract probably opens holes where they can steal the smart contract's money, though obviously creating software that handles money and can't be updated is its own kettle of fish.
First time I hear about IMAP/POP3 provider being able to "undo" emails after being sent. What provider are you using and how does that work behind the scenes? And no, gmails fake "we don't actually send it until you close the tab/wait 30 seconds so you can undo it" doesn't count.
Really? If a mail server (and the post office of most countries) don't have the specified address, it either gets sent back if there is a return address written (email non-delivery notice (aka return to sender, NOT undo) or it goes into a catch all bin (same as a lost & found)(or root account for most mail servers)(or dump it in the bin).
Yes yes, as mentioned in another sibling comment, your wallet won't allow you to send anything to an invalid address. In this case, the address was not invalid, so why expect it to get rejected?
So imagine the bank give all objects in their company an address. The desk has an address, the fridge has an address and so on. Bank accounts have an address too. All these addresses look the same and use the same system to interact with them. The problem is that Johnny wanted to deposit $50 dollar into his account, but he accidentally used the wrong address, and now the fridge in the the bank's kitchen on the 5th floor now owns $50. To his dismay, there is nobody to send his funds back since no human owns the fridge and nobody is even able to break the fridge open to get it out. Don't blame the fridge they say, don't blame the bank they say, don't blame the currency or the address system or the person who made the rules so that fridge addresses and bank account addresses work the same. No, lets blame Johnny, the dumb ignorant fool who doesn't understand the glory of the banks special addressing system. It is working as intended. He should've known better, he should've read the docs etc. Fuck Johnny and his $50.
You’re using a different definition of the word invalid.
Obviously the person you replied to meant invalid in the sense of “not intended to receive funds”
It would have been a competent design decision for a system to require some type of initial registration of intent to receive funds for an address in order for a transaction to post.
I’m sure you’ve heard of it, but in case you haven’t, it’s called bouncing when there’s no valid inbox on the other end. Before you object, yes, you can set up a catch-all incinerator, but that’s not the default as is the case here, you have to explicitly set it up.
"Bouncing" can happen in cryptocurrency world as well, it's called "sending to an invalid address". It just happens to be that the address-space is so big you don't really know what address has a real physical person behind it or not, or yet even.
Try sending cryptocurrency to an invalid address and you'll see that the wallet will reject sending it, just like email bouncing.
Most people setting up mailservers don’t consider a catch-all forwarding to /dev/null a valid inbox. And no sane mailserver software forwards to /dev/null by default if you don’t explicitly tell it what to do when it receives email it isn’t supposed to receive.
A “valid” address locking up funds sent to it without recourse is /dev/null.
Hm, in order to clear up some (seemingly) confusion about how things work, let me offer you this explanation:
The user in the submission did not send funds to a invalid address. The address is valid, as otherwise funds wouldn't be able to be sent to it (the wallet would not allow you, nor the protocol, nor the miner/validators). The address happens to belong to a contract, that can also hold funds, similarly to accounts.
Now, every address/account/contract has a private-key behind it, that allows the owner of the private-key to transfer out of the address/account/contract, but it's impossible to know if the owner actually still has the private-key.
Similarly to how you can't know if john@example.com actually has access to his email account (maybe he forgot his password?), you can't know if an address actually has the possibility of moving the funds out of the address, as the private-key can have been thrown/forgotten/lost.
I’ve made myself abundantly clear that WETH or whatever smart contract shouldn’t blackhole money by default when there’s no handler code, just like mailserver software shouldn’t blackhole emails by default. This is not a case of John making a mistake of forgetting their password, it’s ridiculous fallback behavior with unconsidered edge cases (or maybe considered but intentionally unhandled due to stupidly expensive compute). The design is atrocious and apparently it’s the default for all smart contracts.
The stakes are a little bit higher when you’re sending money instead of emails.
This is the right way. Default behavior for any box should be to bounce. I forward all my wrong mail to a black hole but that's because I'm not a fucking smart contract
Again, if you try to send funds to an invalid address on Ethereum, you won't be able to. First the wallet will stop you if the address is invalid, secondly no miner/validator would pick it up from the mempool if the address is invalid and thirdly, no other party would agree that the address is valid and hence the transfer wouldn't go through.
Simply said: you cannot send funds to invalid addresses on Ethereum.
Because that feature of gmail is not a part of email, it's a part of gmail the product. And it is not "undoing" sending a sent email, it's cancelling an email that was never sent in the first place.
Because email doesn't work that way. Gmail doesn't send the email for a minute. It would be like your boss asking you to send this email and you wait a minute for him to change his mind before you presses send.
Yeah. Even in the original bitcoind API you would run a validation call on the address and the spend before actually committing it. Afaik you couldn't accidentally send coins into a black hole even if you tried.
As far as Ethereum is concerned it's valid, but the contract API is riding on top of Ethereum's blockchain. It's middleware. It's responsible for enforcing the contract. How does it have a giant black hole in it?
It's the same as you and I agreeing on a contract where it says when you send me money, I will burn it. If you then use a bank transfer to me, it's not the bank's fault your money is gone, we agreed on that contract and it's not the bank's business to deal with that. Doesn't mean that there shouldn't be safeguards, there absolutely should be, but just laying out where the responsibilities start and stop and the whole deal with crypto currency is the absence of central control so if you choose to shoot yourself in the foot, you're free to do so. But freedom of action doesn't mean freedom of consequences and in the case of a blockchain, it's forever.
It was a really bad design decision to have smart contracts have this "send to the address" capability, rather than requiring clients call a method that is explicitly defined.
> he sent tokens to smart contract's address and they will stay there forever, not associated with any account.
Wait... so the tokens are really still there, just inaccessible? In what way do the tokens still exist? What makes them inaccessible? Is there really no possibility of restoring the tokens? No possibility of cleverly hacking them out with the assumed myriad of unpublished security flaws?
The tokens are a number in a hash-map of user to balance in the weth program. Any eth program ("smart contract") can be a user. All the smart contract that owns the tokens has to do is tell the weth smart contract to transfer them, or approve mister redditor to transfer them on the contract's behalf. But that contract wasn't built to do such a thing. And now that it's published, it also can't be updated to do such a thing. A new contract could be uploaded, but that new contract won't be the same user. So they're just gone for good. Hope that cleared things up.
So, could the Ethereum community get together and agree to rewrite the blockchain and undo this transaction? Perhaps they could vote on it and have a hearing of the facts. Of course that introduces its own tyranny but is it possible?
It is possible. That's why you have Ethereum and Ethereum Classic, two different chains. The latter one is the unaltered chain, while Ethereum (which is the most popular that's everybody are using) has been forked in such a way that you're describing once after a large hack.
Specifically, it forked because even though the system is specifically designed to make rewriting history impossible, the hackers screwed so many users that they decided to undo it by ignoring history and starting from before the hack.
... Lest anyone ever think Blockchain tech is somehow immune to network effects and social considerations.
Technically, rather than ignoring history and starting from before the hack, they added a nonstandard transaction (not generally allowed) which reversed the effects of the hack.
This did not revert other transactions that happened after the hack.
But, yes, blockchain stuff is fundamentally based on consensus about what the rules are, and people/organizations with more social influence can [...] .
The chain is by nature append only, so you'd have to fork it, which they sure as hell are not going to do for a "little guy," to put it mildly. At least, that's my layman's understanding.
In simple words, he should have done what everyone else does and used Uniswap or Zapper or Sushi or ANY exchange and swapped WETH for ETH that way.
This is just a dumbass user doing dumbass things. This is basic-level stuff right here. Don't interact with contracts directly unless you 100% know what you're doing.
But people are allowed to interact with smart contracts. To obtain the WETH he needed to do that. This is a "why do we even have that lever" kind of situation. If my brokerage had a "permanently burn all of your money" button then it wouldn't be reasonable to just say "well, people shouldn't push that button."
We can even see this with the criticism of wire fraud. Wire fraud is a huge fucking mess that occasionally costs people their life savings. The entire setup is rightly criticized (heck, even by the crypto community) for having users interact with a highly error-prone system with huge consequences.
People are allowed to login as root and delete their systems too. Yes, today's software doesn't make it easy - and the same can be said about this wallet/token; this was a complex sequence of steps in the wrong direction, not a missclick.
And a lot of ink is spilled about systems to make this very difficult, with people continuing to work to improve things. We didn't simply say "well, just don't type those characters" and move on with our lives.
The set of people running a service with a revenue of 500k on a personal device must be minuscule and the people doing it almost certainly know it’s stupid.
This is qualitatively different from crypto that allows you to burn your money on accident, while the people who build the infrastructure for this tell you is a smart, safe place to put your money.
Interesting how your example has just completely changed.
But also, wiring money is a thing that laypeople almost never do. It’s nerve wracking to wire money. But the equivalent in cryptocurrency is just how it’s done. Every transaction is just a fuckup with no recourse waiting to happen.
What's so interesting? I already told you this wasn't a simple missclick. No need to reiterate.
You can dump money into a pit just as easy with the classic banking system. Where I live (EU), wiring money is the primary way of payments and money transfers. People don't use anything else.
> I already told you this wasn't a simple missclick.
Seems like it essentially was. He exchanged ETH for WETH in exactly the same way. Assuming that the reverse would work (as opposed to destroying the money) was not an unreasonable step. He still screwed up, but a design that allows this is user hostile and stupid.
> You can dump money into a pit just as easy with the classic banking system. Where I live (EU), wiring money…
In the US at least, you can get your money back through the legal system. Accidentally dropping your money into someone else’s account does not give them a right to it and for substantial amounts of money people can and do get their money back.
For this amount of money I’d consider pursuing legal avenues against the developers of Etherium. This design seems borderline negligent and Etherium has modified the code at least once already to force a refund.
Consumer wallet software gives you a warning that this is probably not what you want.
> In the US at least, you can get your money back through the legal system. Accidentally dropping your money into someone else’s account does not give them a right to it and for substantial amounts of money people can and do get their money back.
I doubt this is true in the case of uncooperative out-of-country second party - yeah they have no right to the money, but they don't care and the legal system won't do much for you.
If this guy didn't get a warning, they're using power-user software (likely CLI-based).
Of course one shitty design doesn't justify another, but the point is not justification but a reply to all the people saying "this is way worse than and would never happen with the traditional banking" that they are wrong. I agree that better UX is needed.
Regarding your point about legal action against Ethereum designers, well... That'd be like pursuing legal action against the designers of your web browser because it allows you to open phishing sites. Nonsense IMHO.
I currently hold a position as a Software Architect at a software consultancy, but I'm not attached to the title. I can quickly prototype things on my own, making me ideal for bootstrapping startups, or I can assemble and train a team.
For the past 7 years, I've primarily been working with, and am most proficient in, TypeScript, React, React Native, iOS/Swift/ObjC, Node.js, and Postgres. I've worked with many other languages and technologies and can easily pick up new ones if needed.
Here is a list of some other languages and technologies I’ve worked with previously: C, C++, Ruby, Rails, Lua, PHP, C#, .NET, Java (J2ME), OpenGL, WebGL, Cocoa, Qt, QML, MFC, ATL, QNX, Linux/Windows device drivers, Blockchain (miner development, wallet integrations, monitoring, Solidity), etc.