tzhenghao

Good point. By the way, I checked out both projects above and starred them. Pretty cool!

This. I've seen a couple open core startups that are less than a year old with thousands of stars on their repositories, so I decided to have a look at some of these profiles who starred the project. Most of them have weird usernames that resemble spam accounts, almost all of them cannot be pointed to some other profile on a different platform (Twitter, LinkedIn, HN etc.).

Another giveaway is the ratio of stars to watchers / forks. I remember one project with thousands of stars but only 10 users "watching" it. They went on to raise a sizable seed round too.

I think they're just playing a larger distribution game to get people locked into Mojo then eventually pay for their Modular engine hosting services, just about the same as most open core, VC backed startups.

Yup. I've personally used both YAML and TOML for configurations, much more the latter recently and can see pros and cons for both.

> How well suited are their syntactic choices to the community they're targeting?

Also, "best" practices. One could reduce the pain of the other, but by no means is the right solution to a deeper problem at hand. For example, if one has very deep and complex nesting for configs, TOML "may be a lot nicer" compared to YAML, but that doesn't mean using TOML will make all the config parsing problems go away. It just mask away code smell. Maybe time to check if they're overcomplicating configurations in general.

I wear them every day, but take them off if I'm going to high crime cities. The thing is I've been collecting watches for over a decade. My parents are into it, and so is my younger brother. I think it's very rare to share a common interest that won't bore anyone at the dinner table. Now onto the horological aspects - they're like the iPhone / app store back in the day. Keeping track of leap years and all in a 36mm package (think Patek 3940s). Various complications to address various "limitations" of mechanical time telling like the remontoire, co-axial escapements or solid block case constructions for better waterproofness. It's not too different than some of us on HN who fall in love with old Apple IIs, NES or Sega Genesis :)

VCs aren't always the best capital allocators - a lot has succumbed to the money management + fees disease. They push you to raise more, force you to hire and burn when you really shouldn't / haven't figured out product market fit yet.

> Whatever magical market forces that might change how funding works, they don’t seem to be at play.

I think money is scarcer these days, and founders who are constantly being burned by VCs will think twice about riding the big VC train in the coming years. As a founder myself who work crazy hours getting the business going, it's painful / bad optics to see full time VCs doing weekend Vegas trips, browse art galleries on weekday afternoons and fine dining every couple of days, knowing I've sold a chunk of my / my team's hard earned equity on that bs. Of course there are great VCs, and some businesses needing to be VC backed, but oh boy, are there really bad apples out there.

Hey there, OP and author here!

> alluding to with respect to the ONNX being an Azure on ramp

Yeah sorry, should've worded it better in the original article. ONNX is one of the industry's first attempt at standardization of ops across various deep learning frameworks. Here's a way to think about it: Like Google, Microsoft has a cloud business. Unlike Google, it doesn't have a deep learning framework (Tensorflow) and is a significant threat if the cloud players continue to vertically integrate their ML stack. So ONNX makes sense, ie. you, the ML engineer should convert to ONNX so now at least you can run it on multi cloud providers!

Tangential to this, there's also a rise in heterogenous environments, and picking the "best" is non-trivial. A lot of serving / inference hosting companies capitalize on this, and ONNXRuntime is sort of Microsoft (Azure)'s answer: "give me an ONNX or PyTorch (which we will subsequently convert to ONNX), and I'll show you how easy it is to deploy it to Azure". The key nuance here is how much user tooling friction there is to deploying models, and it's in the best interest of these cloud providers to sometimes use their open source initiatives as on-ramps to their larger cash generating products / services.