There was a lot of money poured into Rust by large companies and they're looking for immediate and tangible impact (this helps to explain a lot of the negative feelings on all sides imo)
Investors aren't going to abide by a long-term experiment with undefined success outcomes.
Being pushed into a different tax bracket is something people should always keep in mind. Different tax brackets affects the calculus of which 401k to use (post/pre tax), decisions about liquidating tax deferred assets, it goes on
No it doesn't. Not for people who earn tech salaries which is what this article is pointed at. You're always going to max out pre-tax 401k first, then backdoor 401k post-tax after if you have enough spare income.
Moving up a bracket doesn't change all the previous brackets, it just affects money past that level. It's not like a hard line that you cross and it changes the whole picture.
If you think otherwise, give us a scenario where is matters.
Scenario 1: If you believe that your marginal tax rate after retirement will be higher than your marginal tax rate now, you would prefer to max out your Roth than you pre-tax now. Many people in tech will be taxed at the top income rate now and at the top income rate in retirement as well; it seems likely that tax rates will have to rise in the future as we're obviously not running a sustainable balance of federal inflows and outflows now.
Scenario 2: If you want to funnel as much money as possible into your employer's plan, you might want to use a Roth vehicle to do that. (Your pre-payment of taxes on it means that $100 in a Roth is worth more than $100 in a pre-tax vehicle.) Your 401k plan might not support mega backdoor 401k contributions (many plans don't allow after-tax contributions [distinct from Roth]) and you might have other IRAs that would drag in the pro-rata rule for backdoor IRA contributions.
If you’re at the limit for the middle capital gains bracket because of one-time gains and you can afford to wait, you should definitely defer liquidating assets to the following tax year.
Yeah this is important for planning, and it becomes even more complicated when you're trying to optimize with AMT involved, reclaiming credits, etc. These things require multi-year planning, and the expected tax bracket is a significant factor.
Always sad to see a small player swallowed up by Cisco.
As someone who had the unfortunate experience of going through a Cisco acquisition, there's a familiar pattern.
You can expect that their product roadmap will be torn to shreds as Cisco VPs start streaming in to demand poorly designed integration projects with Cisco's terrible platforms to pad their own resumes. Talent drain ensues as Cisco's low bar for hiring starts to take effect.
The product will keep selling, since Cisco's MO is to leverage its massive sales machine to boost revenue, but there will be little concern for the actual tech itself going forward.
Yes, I was really disappointed to see this. I've pointed a lot of PM and folks to Isovalent and Cillium. I really like the idea of eBPF as it solves a lot of the issues that just are poorly handled by middleware/middlebox solutions. I'm not sure why a company like Palo Alto Networks didn't jump on this earlier. I know that this, somewhat, cannibalizes their core business model (middlebox solutions) - however I feel like it would have been more of an additional layer than a complete product line disruption.
At the end of the day this is a great buy for Cisco, but horrible news for customers. I feel as though Isovalent was a bit too early with their mouse trap, but damn is it a good one.
That is rather sad, Cisco will ruin another good product bringing it into their mediocre product lines to be marginalized to nothing over time. I've had friends that have come into Cisco through acquisition, they invariably last long enough to vest enough of their stock options and get the hell out as quick as possible, almost always 2 years on the dot. I bet Cisco HR can track that as a reliable metric.
Now the purchase of anyone by Cisco simply signals a death knell for them. Last words generally heard now are "they used to be cool".
Cisco has been different companies over the last 30 years, and it's not hard for me to believe their current incarnation is drastically more hospitable than their mid-aughts incarnation.
Not sure about 30 years ago, but for the last 20 Cisco has been the same. Mostly reliable hardware, but the software side sucks, the licensing and support fees are ridiculous, licensing without a direct connection to their cloud (or a satellite server) is a pain in the arse, sales doesn't even try to be realistic with product capability to product need match, and support is barely above worthless, even with a high-touch contact. Cisco is the same company today as they were back with Ciscoworks and MARS Protego.
Teams and founders who have built material value deserve liquidity and an exit. It sucks when they exit to these sorts of orgs, propose a better path that maintains the value but still provides the exit. Customers becoming shareholders through a direct offering comes to mind, but there are other avenues.
At some point I feel like customers are going to be extremely wary of buying anything from smaller players if they know their filet mignon is destined to instantly transform into a turd sandwich the moment the inevitable acquisition occurs.
They'll still take meetings - it's free information so they'll never turn that down. Even if they're a solid 'no' from the outset.
VCs aren't always transparent with their reasoning. Some of them said they don't believe in our category anymore. Some of them said "great work, show more growth". It's always difficult to parse the signal here.
It sucks, but you can't be too hard on yourself. Many of these investors haven't deployed capital in months.
What's nice about these platforms is that they scale with the complexity you need. You can drop down to Python for scripting operations and UI interfaces in TouchDesigner, GLSL if you want to build your own shader pipelines, etc.
Yes. There's some flexibility in there, though I haven't got enough experience with it yet to see whether that is a way through a ceiling or just a source of additional confusion.
Isadora has GLSL too, and a JS actor which is nice for stuff which gets tedious to patch like a calculation with more than one operator. I have used that one a couple times.
Definitely not, if you reply to a sufficiently famous person in a way they dislike there's always a risk they'll (in)directly turn their followers against you.
They added the structured concurrency package because you still need some kind of async framework for concurrency.
Maybe the confusion is just the term "framework" as opposed to API? I don't mean a third party library is needed. The built in JDK alone is sufficient but you're still juggling promises/futures and the like.
The complexity of an async lib/framework such as i.e. projectreactor stems from that your code stops being linear. And so is the dataflow.
This is the core of the issue. You trade simplicity for performance.
Using futures you can still write simple linear code.
The problem is that thread based execution doesn’t scale well when the threads are mostly waiting for io, such as i.e. an http request.
That is, it was a problem until virtual threads arrived.
You don’t really need anything, they just make forking and subsequent joining+exception handling easier. You can just use the decades old thread api over virtual threads as is if you wish, but this “structured concurrency” concept, similar to goto vs structured control flow will make it much more productive and easier to reason about.
Again, my point is that you often won't want to be blocking. You'll still want to run multiple async calls concurrently, and to do that the syntax is not the familiar synchronous style. You still need to use more complex apis.
Investors aren't going to abide by a long-term experiment with undefined success outcomes.