K8s is amazing piece of tech, but still there is a big cost and complexity inherent in adopting & managing it.
I enjoy using it and playing with it, but so many use cases can be addressed with something simpler - either just Docker / Swarm / AWS ECS etc. alternatives or just going for VMs with well defined CI/CD processes that let you tear down the infrastructure and set it up again easily.
What very interests me are the concepts K8s build on that are not usually recognized - to me K8s seems a lot like a JVM, just that it operates on infrastructural (and not runtime) level.
I enjoy experimenting with these concepts when applied back in the runtime world - it is for instance interesting to run 100s of servers with JVM and let them load/execute new dependencies and code at runtime (JVM is very well suited for that).
This is area that is not yet explored and would probably deserve more attention as it allows for distributed rapid computing that is infrastructure/platform independent (the downside is that it requires (just) JVM and the isolation is not perfect).
E.g. If I am net long in my portfolio and I fear some headwinds I can buy a put or two for the peace of mind. Now those puts should be always considered as worthless, and it is just the price to pay for the peace of mind.
Similarly you sell options. Trading options on the other hand is just pure gambling. Even if you get the direction right you likely won't get the timing right (or the volatility).
> E.g. If I am net long in my portfolio and I fear some headwinds I can buy a put or two for the peace of mind. Now those puts should be always considered as worthless, and it is just the price to pay for the peace of mind.
Why don't you just change your allocation?
If you can't sleep at night because of your current portfolio, and gyrations that are occurring, or that you are worried could occur, I would say it's obvious that it's not suited towards your risk profile.
You're burning up some of the potential upside by spending money on the options, so why not simply take some money off the table instead and have a less complicated setup?
Year ago when we were reading the news about what is happening in Wuhan, some of my friends bought SPY puts as an insurance against the potential crisis.
The best outcome for them would be if those puts expired worthless. When you insure your house, you don't usually wish for it to burn down.
I haven't acted and my portfolio took a -30% hit right after.
Your suggestion (to change the portfolio allocation) would mean temporarily selling stocks and holding money. That strategy has an unlimited loss potential[0] if the stocks rise before you buy them back. With puts you are limited to whatever you pay for them.
edit:
[0] unlimited loss potential provided you want to keep the same stake at the companies
Rebalancing is a thing, though generally for risk reasons. It would/could have saved one's returns during the so-called Lost Decade of the 2000s with the S&P 500:
As your equities dropped, there's a good chance bonds would have at least stayed neutral, or even risen: so you'd sell some of those (sell high) and pick up equities at a discount (buy low).
There are even products available that do this automatically for you:
>When you insure your house, you don't usually wish for it to burn down.
You're leaving crucial information. You don't buy insurance (or puts) at any price. It has to make economic sense, and the person on the other side presumably has the same information.
Of course, being safer (more conservative) brings lower profits. I'm for sure not suggesting to be puts-insured all the time! It is just a useful instrument when one wants to hedge.
The person on the other side is likely a market maker selling both kinds of options. The price is dictated by market.
It's unlimited opportunity loss. If you sell at say $100 and it goes to $1000 while you're in cash, you "lost" $900 vs your original position. However if you hold at $100 and buy a put for $2 that hedges you, you can still participate in the upside while limiting your downside. Also, downside risk has been historically undervalued (this may be changing though) which is why tail risk funds exist.
everything has an unlimited opportunity loss though. if I put all my money in SPY, I'm forgoing the "opportunity" to buy a bunch of OTM gamestop calls at the perfect time and 10x my net worth.
The strategy forces you to time the market. You might get unlucky by holding cash during a market rally, then buy back for a dump.
An investor who sells when they think the market is going to go downhill, with the intention to buy back later is not acting as an investor but as a trader.
That's why hedging with options is less risky (and less profitable in the best case).
edit: My use of word 'unlimited' applies if you want to keep the same stake at the companies. In money terms you cannot lose more than the value of your holdings.
Yep, then I agree. I'm not advocating for trying to time the market, or holding cash instead of being on the market.
But selling your position simply does NOT mean you take on "unlimited loss potential". It's simply being outside of the market, which means you're missing out on gains. It's not like selling stock is suddenly the same as shorting the same stock. I think the terminology here is clear-cut and well established.
I get what you're saying and I think your terminology makes sense.
But the way to understand this is to reframe your view of "money" from being some special, neutral thing to just being another asset.
At any given moment, you could own $1000, or some gold, or some bitcoin, or whatever else. There is nothing special about the fact that it's $ you're holding rather than DOGE or SPY.
So imagine a 2-asset world, that has SPY and $ in it. You are holding $1000 right now, and the market goes from 1 SPY = $1 to 1 SPY = $1000. That is a loss. Denominated in SPY, you just lost 999 SPY.
It’s unlimited because in the time he is holding cash there’s no limit to the amount the stock market could increase. If he sells a stock for $10, and then it goes from $10 to $10,000 he’ll only be able to buy back 1/1,000th of what he had. He lost $9,990.
It’s the same as writing call options. There’s defined upside and unlimited downside.
> How does holding money have an "unlimited loss potential"? You just buy back at whatever value the stock is at the time.
It does not have unlimited loss potential, I'm not sure why the poster said it did. It's the opposite - holding has unlimited upside potential(however slim).
People don’t realize you have unlimited loss potential on every stock you are not holding right now, and that’s why cash is not a great position. When you sell and wait for a dip, you are basically in a short position except you’re not borrowing stock.
I had SPY puts expiring in April at the same time, but as a hedge against Bernie Sanders doing unexpectedly well on Super Tuesday. He didn’t, but my timing was still good against a factor that I had been entirely ignoring.
You can also write them in a low risk way for the benefit of others. If you hold some stock write options for people to buy it off you for twice what you paid, or if you are thinking of buying a stock write options for people to sell it to you at lower than the current price. But yeah trading can be iffy.
The problem with covered calls is you take on all the downside risk of the stock collapsing and get none of the upside gains if the stock rockets. Writing way OTM covered calls will not net many proceeds unless the stock is super volatile which means you likely have a lot of downside risk.
A good example from recently is Ford. Was trading at around $6 a few months ago and not too volatile. OTM calls were pretty cheap that were a few dollars up and essentially worthless at double the price. Anyone writing those was getting almost no premium. But then the stock took off quickly and hit over $12. Anyone who wrote those calls enjoyed none of those gains.
So even a stock like $F can move in very unpredictable ways.
I guess now the question is if Nubank could/will also promote Clojure and to what extent (or if they will support Cognitect enough to do that). I would wonder if they went through that thought process and what RoIs for that are from their perspective.
It might even take much lesser investment than equivalent of $1bil from 90s... The Java/JVM market is huge so it might need just a little nudge :)
Within the JVM ecosystems it seems that basically Kotlin (as nice as it is) has been stealing some market share that might have belonged to Clojure. And all that just by selling some cheap cut syntax sugar on the corner.
There definitely is a huge desire within Java/JVM community to innovate and if approached correctly Clojure could actually shine - there are just few misconceptions and fears that could be put to sleep by some smart marketing strategy. Nubank is great first step in that direction, because it gives an example of a mature large yet innovative company relying on Clojure in production.
> And all that just by selling some cheap cut syntax sugar on the corner.
I suppose you could dismiss a lot of what Kotlin adds as mere syntactic sugar. But it also makes some much more fundamental improvements. It provides a much cleaner, unified, object-oriented type system. It provides about as sane an approach to null safety as is possible on the JVM. (Clojure's is arguably better, but I'll concede that nil punning is not for everyone.) And it provides a clean set of core libraries that doesn't have nearly as many friction points and inconsistencies as the core JDK does.
Clojure has no null safety. You may encounter it less because of the foundational building blocks you use in the language, but NPEs are most certainly there.
NPEs exist but I probably go months or even years between encountering them. Most Clojure functions are polymorphic on nil and provide safe default behavior. You primarily encounter them when invoking Java APIs via interop.
I don't see any technical reason why Kotlin couldn't have done the same.
Kotlin does do the same. I totally disagree with GP's assertion that Kotlin has no null safety. I use both Kotlin and Clojure and I find Kotlin much better than either Clojure or Java with respect to NPEs.
Kotlin now has a new master and needs to decide how much they want to innovate on the JVM or keep the language compatible with ART capabilities and Android libraries.
KMM can only help so much, specially when all the big Java projects are all integrated into stable releases.
Cancer survivor of 20 years here. You sir seem to understand exactly how things are. This is how it is, not bad, not good, just the nature of life i guess.
Really appreciate your time looking into this and apologies, missed your original post. You got the answeres right. Re 2 - it shouldn't be that hard to add, since everything is just data. It is however partially covered by the retry property on each step.
Will read through your additional comments and will respond tomorrow (busy day, plus it's midnight here in Europe)!
Cheers
Miro
Yes, I would still be careful with passwords in the public beta.
It goes via SSL and you get a unique UUID URL so all-in-all it is kinda secured (plus time-to-live of the instance is only 3 hours which limits any time to hack it) but still this is not 100% secure and I would not recommend it for any kind of production use (including any use of passwords you dont want exposed).
The free instances are not (yet) password protected (other then the UUID) - this on the other hand is useful if you want to share the envrionment with somebody, just send them the link...
This is just a beginning of the public hosting so I will need to think through further improvements that would go into the hosting, security-wise and other aspects as well.
My main objective at this stage for the free hosted instances was to give people way to play with Titnaoboa or quickly test something, especially if something is not working in their local environment (say dependencies) and they want quickly re-test in vanilla environment.
That is a fair criticism, I am aware of the AGPL license shortcomings.
I just picked up the more restrictive license at the beginning - being a sole funder and not working on this full time etc. I simply did not want somebody (e.g. a big company with a big team) grabbing my code along the way and running away with it.
Since now Titanoboa got to the shape I envisioned it to be in I am starting to focus more on adoption, so yes I am definitely thinking about switching to less restrictive license since it will probably help.
Also at the beginning I was not aware how badly AGPL is perceived (I always thought if it was good for Mongo it could work for me, but I may have been wrong).
>>I just picked up the more restrictive license at the beginning - being a sole funder and not working on this full time etc. I simply did not want somebody (e.g. a big company with a big team) grabbing my code along the way and running away with it.
Sounds like a great reason to use the AGPL! Can always switch the license for later releases as you gain traction.
Gdoc form for suggestions. 1 mail to all users (small enticement, reward for winner, pro account for life or something else really nice). Remove any lewd suggestions. Then pick one you love, or if you can't choose a poll.
I enjoy using it and playing with it, but so many use cases can be addressed with something simpler - either just Docker / Swarm / AWS ECS etc. alternatives or just going for VMs with well defined CI/CD processes that let you tear down the infrastructure and set it up again easily.
What very interests me are the concepts K8s build on that are not usually recognized - to me K8s seems a lot like a JVM, just that it operates on infrastructural (and not runtime) level.
I enjoy experimenting with these concepts when applied back in the runtime world - it is for instance interesting to run 100s of servers with JVM and let them load/execute new dependencies and code at runtime (JVM is very well suited for that).
This is area that is not yet explored and would probably deserve more attention as it allows for distributed rapid computing that is infrastructure/platform independent (the downside is that it requires (just) JVM and the isolation is not perfect).