I happen across AntidoteDB just the other day, and my take-away was that it was still under development but not really ready for production use. Curious your opinion / experience with it?
Yup, it’s a very rigorous system developed over ~10 years with solid testing, benchmarking and formal proofs. However it has some known issues, such as behaviour under high load and not currently handling node failure within a DC.
It’s not production ready and neither are we (we’re in developer preview mode, which is like a public alpha [0]).
There are also other aspects on the Antidote roadmap such as efficiently materialising consistent secondary indexes that are ongoing challenges but aren’t so relevant to how we’re using it as a replication layer.
We are working, alongside others, with the Antidote developers to help fix these issues and generally improve reliability / engineer correct behaviour under load. (Professor Annette Bieniusa, who leads the development, is our Chief Architect). We have a fork at electric-sql/vaxine [1].
We are also taking advantage of some simplifications which mitigate the known issues. We have an #antidote channel in the ElectricSQL discord [2] if you’d be interested in chatting more.
I’m just going to put the idea here… C# and Blazor, with linq to sql, in the browser… automatically synced to the backend server… that just sounds like magic, but magic I would throw money at.
The further you get in physical/geopolitical distance from the US the more you invalidate assumptions that many US sites and services make.
I've had sites fail because my local time can be one calendar day _ahead_ of theirs... and how could you be doing something in the future?
Once you get into regions with a combination of censorship on the foreign-side and aggressive 'security' measures on the US-side (blocking/triggering on IP ranges of entire countries, VPN services, could services, etc... 'cause why would a legit user be coming in through anything like that, right?) then it really gets rough.
Generally, to reliably serve a country/region it requires specific expertise, personnel and/or infrastructure.
And BTW when I priced out a "reliable" connection in Beijing years ago it was around $1K USD/mo for 10Mb. Not exactly peanuts.
Spending the night hanging out with people from Syria I think they might disagree with your depiction of US cities. Measurements in mm are different than those in lbs.
If it's feasible to write (most) all of your app backend in Elixir, then I think it's a pretty great option. I feel like language context switches tend to be very expensive and error prone for developers, plus the increased hiring and on-boarding cost associated.
I think the core advantages of micro-services are:
1. Polyglot applications. There often is some library in a language for a use case, but there is also often the library in a specific language - the one that has a far larger community around it, very active development, considerable battle testing, a wealth of examples and guides and support available online. If you use this library in this language, you just kind of know it will work as best and easily as possible. The trail is well trodden. You now have a new problem of API contracts and versioning and such, but pretty much every language can at least HTTP and JSON reasonably at this point, so it's fairly tractable.
2. You already have code written in another language that pretty much works, either because of (1) or for historic reasons. If you go all-Elixir, you're going to need to re-write that hairy-ass black-box of a Go service that interfaces with Chinese SMS delivery. But it pretty much works, and if you can just chat with that over HTTP you can keep going. However, you probably want something to turn that thing back on every week-or-two when it inevitably eats it for whatever reason, and K8S gives you a really nice interface for this.
In general, I think - and this was an opinion I read on this forum at some point - that when building from scratch it's best to build a mono-service and then break small things off from that as the need arises, and Elixir would probably be at the top of my current list.
However, if you can run that mono-service in a micro-service environment - Kubernetes and containers - then you're well prepared for breaking pieces off or rolling new isolated components using the "right tool for the job".
I know there are difficulties around BEAM and K8S with both kind-of trying to do a lot of the same things, and that's something to definitely be aware of... people that have worked with it seem divided on where it falls between terrible and not really that bad of an idea (if you're paying attention and have some idea what you're doing).
That's exactly the problem I have with elixir, or akka for that matter. It's definitely a very convenient abstraction for building microservices and distributed systems, but at the same time it's a heavy language lock-in you're getting yourself into, the moment you start your project.
And especially now, when there are the de facto standard libraries to do various tasks (like TF in Python) I think language lock-in can be a terrible idea.
If I need to do something in Python, I have options like pyrlang[0] and rabbitmq[1].
In fact, parsing in Elixir is not nearly as mature as what is provided in Python. I need to parse emails. Python has `email.parser` which is perfect for my use case. I can easily use Pyrlang to do this. But Elixir is still much better at being an email client (or many email clients). The end result is an email client in Elixir that uses Python to parse the emails.
When I started with Elixir, my goal was to use it as much as possible, but delegate as soon as the task is better handled in another language.
Yes it is better to build mono services first because everything becomes N-times more complicated (unexpected requirements, deployment and testing) when you have N services to manage/mock/deploy/test/recover from failures of/log/configure etc.
>> “High-performance polyglot VM. GraalVM is a universal virtual machine for running applications written in JavaScript, Python 3, Ruby, R, JVM-based languages like Java, Scala, Kotlin, and LLVM-based languages such as C and C++.
"Support for Ruby, R, or Python 3 is still experimental in GraalVM. We are actively working on stability and support for all modules for those languages. At this point in time, we can run simpler applications of Ruby and R, but we do not have the same full compatibility we provide for Java and Node.js applications. Our Python implementation was just recently started and can only run small examples."[1]
How long you live(d) there? It freak me out at first, like many things that are different, but after getting acclimated for a few years I actually think it works out pretty well. I had to get used to the "flow" and get used to being aware.
It now kinda freaks me out to be back in the US... realizing that everyone involved in traffic has their own assumptions of what is supposed/going to happen and won't necessarily be looking around all the time at what's actually going on, and I have to guess and premeditate that for everyone.
It's not a big problems when density is small and there is only one significant traffic element (cars) that's relatively predictable, but if the US is going to scale it's cities they're going to have to figure out how to deal with how to increase traffic density, and it doesn't seem very feasible to add more car roads and sidewalks in metropolitan areas (let's not touch on subways for the moment because that's what communism or Euro-effeminism or just too damn hard or whatever).
It's pretty easy to fit more people on those streets, all ya have to do is:
1. Slow down
2. Look around
3. Take a bit of the chip off the shoulders
Which I feel like all pretty much fly in the face of everything back-to-back World War champions cherish (and great prospects for this upcoming season!).
But I think the point of the article was "look both ways before you cross the street" was total bullshit when it was introduced... and now it's dogma. I don't necessarily wish metropolitan progress and growth on Americans, but I guess I kinda secretly hope for it.
I've been in Shenzhen eight years now as my primary home and work location. Long enough to get trained to turn around and look before I step left or right.
Whether they respond with process and patience or not, I’m hard pressed to think of powerful states that abide “f*ck yourself” once they’ve started to think national interest/security.
It definitely change, although I can't say to which direction. He makes the system legitimate, so any successor would have either to be more open and earn some political trust in a normal process or just close the country even more (deploy martial laws, etc.)
I live in Beijing, and the bike and scooter shares are everywhere, including blocking sidewalks and in huge piles and it’s absoultly great. They’ve been a terrific improvement. It’s great to use them, and it’s great to see so many other people using them.
Yeah, they’re kind of a pain to deal with them sometimes, but it turns out you can just move the bikes, and walk or ride around the piles. I have yet to see anyone get stuck in a pile. And somehow even people that don’t use the bikes seem to be able to lend some value to the idea that other people do (this was very strange to me at first, having grown up in the Bay Area).
Beijing is pretty much the perfect city for them though... completely flat and ridiculous spacious and open (except parts of the old city). I can see it being more painful in tighter cities. But they’ll figure the piles problem out; it’s already gotten better, and the net benefit has been pretty large.
I think that he's kind of right about the problem.
In my opinion, Python's primary business value has been that sweet spot it occupies. It's not the most fun, but it's pleasant. It's not the fastest, but it's not too slow. It's not great on resources, but it's not too bad either.
Good people will work with it, and they tend to be the "let's not get creative, let's just get it done" folks that businesses love. Mediocre people do great with it, because it feels much nicer than many of the other things they've worked with and it channels them towards producing better code and being more productive.
Python makes it huge pain-in-the-ass to get weird/creative, and generally frowns upon it, so people tend not to as much. Junior and low-skill contributors can't really get in too much trouble as long as they stick to the program. It's an awesome "just sit the fuck down and do your work" language.
As a language, it's carved out a great space being pleasant, consistent, well-rounded, predictable, etc.. I know there are people on here using it to build their rocket ships. And it can go there too... maybe not as flexible or fun as more extreme alternatives, but it's also less likely to blow up in your face. For those software rocketeers (probably most any SV start-up), updating makes undeniable sense. Python 3 is hands-down better, and they can handle the transition no problem.
But a lot of people don't use Python to build rocket ships. They don't build rocket ships at all. They build delivery trucks and conveyor belts and coffee dispensers. And, for them, the very things that make Python a great choice - a very clean and conservative focus on simplicity and stability - are the very reasons not to switch. There's just not really anything that's been introduced in the last 10 years that is going to make any real difference for their use cases. Whatever trouble they've had with unicode and the other bs has long been lived with. Whatever's missing they've long lived without. And things have been just fine.
Python's killer feature - being a really nice and well-rounded option that works pretty damn good for a large swath of people - is sorta it's undoing here. It's hard to really be that too much more so.
I mean I switched to 3. It's clearly better. But if I was running a Python team that had been effectively just trying to get the job done in 2.7 for over a decade I would have to admit that I wanted to switch for my own sake - I think it would be unlikely to make them that much more happy or productive.
Hell, many people can't even set their same environment back up in a week after loosing their laptop.
> But if I was running a Python team that had been effectively just trying to get the job done in 2.7 for over a decade I would have to admit that I wanted to switch for my own sake - I think it would be unlikely to make them that much more happy or productive.
Part of being a software engineer is keeping your environment up to date. Sure, I could keep using Node 0.10. But I'll get no updates for security or fixes for bugs.
If you're on a team that hasn't updated to a version that's supported, then you're neglecting one of the fundamental ongoing maintenance tasks involved in software engineering. If that's "too hard" to do over the course of a decade, then perhaps there's something wrong with your engineering culture.
Sure, you don't have to do it. But don't expect the rest of the world to continue to support your old setup. If you have to compile Py2.7 from source because RHEL doesn't come with it, that's fair penance for not keeping up with the community. It's just about the most entitled thing in the world to say "I didn't spend the two weeks in ten years time to upgrade to a newer version [using the numerous automated tools] and I'm mad that the world at large isn't making it easy for me to continue to not do anything."
I'll just say this... I still have 2.7 as my base install... for Ansible. Because they haven't switched yet.
Ansible is owned by... Red Hat. They acquired it in late 2015.
Seems like Red Hat - the people in the post that we're talking about that are shoveling folks off 2.7 - has been neglecting one of the fundamental ongoing maintenance tasks involved in software engineering, and perhaps has something wrong with their engineering culture.
Sorry, this shit is just too funny.
And it seems that Red Hat is booting Ansible from the core repos as well (looks like it's in that depreciation notice!), presumably instead of spending the "two weeks" to update it (you might want to go ask the Ansible team why they're too damn lazy to spend that "two weeks", see what they say).
However, unlink Red Hat and Ansible, some organization depend on the softwares in question, and can't just sideline them 'cause the shit they've successfully run on for a decade-plus has lost it's blessing.
It's cool. It's creative. It's different. Things that do not often top you're typical Hacker Newsie's values list, but - hey - if making software's a means to an end I never understood why anyone would write code themselves anyways.
You created something, and that's rad. Yeah, if you're trying to sell out you're doing it wrong, but sometimes I wish I had marked up my soul a little higher back in the day.
It flickers and fails and stutters all over the place, but I'm in China, which tends to get a big ol' stick up in western people's "this will always load and will be pretty fast and reliable" wheel rather quickly.
I can't figure out how to use it at all, but I want to.
The conventional wisdom is that it works better to get big with an unsustainable revenue model and convince people you can make it sustainable than to stay small with a sustainable revenue model and convince people you can make it big.
Spend whatever you can to capture the land, then charge rent.
Sometimes it turns out you can't hold the territory. Sometimes it turns out it's not worth much. But the times it works out are the times that make funds.
I'm inclined to agree with you. It's not my field but I suspect VC pressure has something to do with it: they need their 10x returns, or their unicorns, to make up for all the losses elsewhere and "get big fast" is the most reliable mechanism for doing that. Not suggesting I'm a fan of it, btw.
FWIW when I was still a student and not in a 9-5 I wondered what if would feel like to use basecamp. Now here I am happily going with flow using slack on the fre eplan. One of my coworkers sometimes asks if we shouldn't go with a subscription to have the whole logs but we rarely have to dive so far in the past at all.
In technology, it's often the cost of re-integrating with something else. MongoDB makes this lock in ever better because it's API isn't SQL, so getting off is even harder than usual.
I don't really understand your question... this is the favored approach of many Silicon Valley VC firms, and they are widely considered some the smartest tech start-up investors in the world.
If it really is a bad idea, and those firms have been so successful for so long not because of it but in spite of it, then it seems like a huge opportunity for others to come along and displace them with a better model. There's a lot of money in many of these tech markets. But we don't see that happening.
I guess the answer is that it's unintuitive... it seems like an obviously bad idea to many people, but the people that have the most experience think it's a great idea and continue to succeed with it.
There are other approaches: in China, for example, investors generally considered profitability much more important and expect it very rapidly, like in the first 6-18 months (though this has eased quite a bit towards a more SV-style model in recent years).
The gripe then is that companies can't have any long term vision or go big because they have to be making profit immediately and constantly.
Yeah, I when I thought about it I realized when I say "SV VC" I mean probably only the top 10-20 firms or so - the "top tier" or whatever, Sequoia, Accel, KPCB, Benchmark, etc. (highly subjective but you get the idea) - and I think those guys tend to do OK, and it has been mostly the same ones my whole time in tech (~10 years), and I know many go back considerably before that.
I meant that a lot of those people are down with the land-grab now / rent later model.
It's a bad idea most of the time but sometimes it works. The smart investors have a portfolio of many bets, and it's priced in that most won't succeed. For the entrpreneur I think this is a bad idea but for the investors it's workable if they can do it a few dozen times over.
It's just injection of both money and risk, amplifying the result. It'll fail more often than usual. But if it succeeds, wow.
It's a bad idea for the small business owner/startup to pursue, because investors buy into it for the 1 in how-ever-many that get big. 1 facebook is worth many failures. And to be fair, they're not just throwing money at the wall and hoping it sticks - though there is some element of that. There's also the many companies that don't make headlines but are generally - if modestly - successful as well. So, the investors don't want to lose money of course, but they're okay weathering several losses if the occasional win is big enough to more than compensate.
On the flip side, if you're a small business trying to grow your company, this hole "carve out the market operating a loss in hopes that you'll make it big" idea doesn't work in your favor most of the time, statistically speaking.
Modest investment for modest gains for modest success for long term growth is the smarter bet for the business owner (usually), but that's not as flashy, headline worthy, or profitable for the investors as the go-big or go-home approach.
So, it depends on what perspective you're taking as to whether this "conventional wisdom" really is good or bad.
> The conventional wisdom is that it works better to get big with an unsustainable revenue model and convince people you can make it sustainable than to stay small with a sustainable revenue model and convince people you can make it big.
This used to be called fraud, but now calling it out as such is thought of as regressive and anti-entrepreneurial.
I'm sorry if my wording was confusing; the company in these both situations is convincing people (investors) that they can become those things in the future, not that they are at the current time when they're not (which would likely involve some sort of deception).
It's like:
Case 1: "We are spending like mad to capture what we believe is a valuable market as fast as possible. This means we are losing money like crazy right now, but it is working and we are growing fantastically. Once are in a large dominant position, we believe we will be able to retain that market, so we won't have to spend as much on growth, and we can focus our energy on maximizing revenue and being capital efficient and start making a lot of profit."
Case 2: "We have validated our product market fit and business model, and are profitable. Our market share, growth and revenue numbers are small but stable and positive. We believe we will be able to rapidly accelerate our growth and market share in the future while maintaining our margin and start making a lot of profit."
Both are good, neither are fraud, but (1) currently tends to be the favored approach for venture financing, and one way or another it tends to be venture financed companies that end up dominating the important tech markets (though that doesn't necessarily means it's casual).
https://electric-sql.com/docs/overview/technical-intro
I happen across AntidoteDB just the other day, and my take-away was that it was still under development but not really ready for production use. Curious your opinion / experience with it?