nrser

I clicked through to the technical intro, and it says you’re using AntidoteDB for the top-level replication

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?

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).

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'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.

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.

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.

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.

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.

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.

Something about green grass...

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).

I think all of those services are cloud-based, yeah?

Cloud services are a great option to have available, but there are many reasons organizations choose to manage their own instances... pre-existing infrastructure investment, flexibility, data location and control, cost structure, regulatory requirements, etc.

I read here that Mongo has started a cloud-based offering, but the core of their business competes against other self-managed storage software like MySQL, Postgres, Hadoop, etc.

Trying to get big.

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.

NoSQL has real use cases. The model is much closer to how you usually are structuring and handling data in your application. If you application is handling hierarchically structured, variously shaped, low-relational data - which many are because that's pretty much the default for how programming languages work - and does it's data processing and validation at the application level, then it can be nice to have a storage system that matches that closely.

It's that situation where a single structured User object would "foil-out" to like 10 de-normalized tables. It feels ridiculous. It often is a bit ridiculous. Also, I'm not sure how much Open Source RDBMS have improved in the last 8 years, but I know for a fact that MySQL used to just melt under joins like that with any serious load.

As far as the recent OS RDBMS JSON additions, they're just that - recent additions. They feel tacked on. They're treated differently then first-level values. Support in ORMs is lacking. It's hard to find examples online. They're not nearly as easy to use and well supported as hierarchical data is in systems build around it from the ground up (of course).

As far as why MongoDB... because it's the most popular solution. If you hit a problem, someone had probably hit it before, and you can probably find some material online. The leading drivers and libraries are relatively mature and widely used. It makes it a much safer bet as far as tractability of issues you will hit.

I don't really like MongoDB, but the case for using it seems pretty strait-forward to me.

Many of the top-dollar patents in FB's chest are likely very broad / fundamental to the modern web. If you implicitly or explicitly retain a license to use whatever's needed for React, etc. than you likely have a decent foothold to say you have a license to many of those key fundamental patents, significantly impacting FB's legal position, and these battles are all about position.

It's my "not a lawyer but spent way too much time in legal negotiations" understanding that if you sue FB for patent infringement then you lose license to the patents you get in the BSD+PATENTS, not the software. This would prevent you from saying "well, I've got a license to those patents because I've got a license to use React" (including a possibly implicit one under standard BSD/OSL). This agreements says that at that point, you can no longer assume you have a license to whatever patents could be construed to coverer React, etc., which could be all sorts of wonky over-arching crap from the 90's that FB bought.

The reason you is your whole org and patents is everything is because it would probably be really damn hard and expensive and risky to try to slice it finer.

Don't take this as an endorsement of the license. I'm still not sure what I make of it. FB has done a poor job of communicating about their motivations and indented mechanism, leading many to suspect treachery, and that's not an unreasonable position, but from I can kinda start to see where they may be coming from.

One of the big failing of Jinja in my opinion is that it's Python with only instance methods, but Python has a weird, arbitrary-seeming historic division between basic functionality being implemented as global functions versus instance methods.

So if you want to replace a character in a string, that's fine, because `replace` is an instance method:

    Changed plus to dot: {{ string.replace('+', '.') }}.

    My string is {{ len(string) }} long.

I really started to hate it in Ansible though, where I'm often just trying to get a one-off little operation done that I would rather have obvious right there in the template source rather than having to bounce over to a one-off filter function (or invoke some other outside code), and I can do it in Jinja, but it just looks and feels like hell... which kinda defeats the purpose.

I feel like Jinja was an especially bad fit for Ansible, but as a templating language I feel like it's main strength is it's better than D'jango templates... but that doesn't matter much outside the D'Jango world.

As a logic-ful template language I think it's deficient because it omits the functional parts of Python, which - as discussed above regarding `len()` - are very core to Python, and Jinja adds them back in a different way that requires extra mental overhead to keep track of. I really like the pipes (filters) but it would have been nice to just keep the Python globals as well for consistency.

And if you really want to go logic-less with your templates, I think Mustache(-variants) would be the way to go since they're much more truly "logic-less" and they're supported across a plethora of different runtimes besides Python, giving your much more flexibility. I've never really had the patience / discipline / right use case for logic-less though, so I'm far from an expert in this area.

Jinja is just a really weird mix... it's not logic-less, but it's not Python... it's a funky half-logic mishmash. It obviously makes sense and feels right to the people that make it, and if it makes sense and feels right for you that's awesome, but I hope you can understand how could feel awkward to others.

Check this fiasco out for starters:

https://github.com/pallets/jinja/issues/659

It was never documented that you can override variables from higher scopes

But you could, and people did... because that's what people do: they try stuff that seems reasonable and if it works they use it. And then someone "fixed" it in a minor release and things started breaking. BTW the error message is

    KeyError: 'undefined variable: 0'

I used Jinja2 happily for years on a web app, but that thing pretty much just styled a page for flash to sit in and drew some forms and menus. I use it now via Ansible and have come to despise it through and through.

yeah... are their any success stories with regards to these kind of post? all the ways i play it out in my head don't seems great...

1. someone at exec/board/mgmt-level somewhat detached from product development process sees it and comes in with the "see! this is what it should look like, this looks way better, this guy gets it and he doesn't even work here! you should hire him / do this." which doesn't tend to be received too well from the people doing the actual work, who for right or wrong have all sorts of reasons it doesn't look like that.

if they are forced to bring him in or do it they probably aren't going to like it / him.

2. someone on the team sees it and goes "well, this dude doesn't understand the massive complexities and risks involved in something like this but hey that one piece is not that bad of an idea, let me re-work some stuff", but it doesn't seem like it would help them much to bring him on-board... "uninvited" has a negative connotation for a reason.

of course if could play out very differently, but responses along those lines (if any at all) seem most likely from my experience. it seems like a good approach to rally community support for something, but the community is not the people building the product by definition.

hey Josh!

i am the original poster.

i was clarifying the compassion.

it's a business decision comparison, not a technical categorical comparison. you need something to receive http request and return http responses, and you're comparing different popular (because hiring, training, and available community / support resources) ways to do that. they might be apples and oranges but at that level you're concerned with comparing fruits.

as the other commenter said, php is a web framework... and it's what we were using. it's actually more of a web framework than a language in my opinion (or at least was at that point). it's centered around receiving http requests and writing http responses. the article mentions this in fact.

it was a huge pain to try and get php to do anything else. it was totally unpractical to do the kinds of back end processing that we needed (since the database was pretty much off limits during a http request)... long running processes with hundreds of millions of objects were a no-go. believe me, we tried. which meant you had to sync all your logic into Java or something else that could handle the job. which is really error prone when you have a bunch of people moving fast on something.

one of the greatest things about php is that it's a super minimal focused framework. it's also one of it's major short-comings when that model no longer suffices.

you can layer something else on top of it, but the stuff available at the time certainly didn't help the performance or memory characteristics.

it's the "good problem". and the good problem can always be solved, though lack of reliability can seriously hurt your growth. but that doesn't mean that it's as easy as people make it out to be.

i wrote and ran a big php app (Zynga's Mafia Wars). this is just about the app server (apache + php side), single-master MySQL will give you far greater problems at that scale.

everyone is tearing away adding features, and the code just keeps getting bigger. everything includes everything else. so you can't just start fresh with every request, it takes way too long. so you use APC or whatever. now you have global shared state (and people start using it), but as long as no one really fucks it up that's ok.

php processes are always erring and dying in weird ways that no one can figure out, especially if anyone uses the half-baked OO stuff (circa 2008-9), and tracking down obscure php state errors ranges from difficult to impossible since you're never quite sure when or where something went wrong, but it works for most people most the time, as long as you remember to clear out the error logs so they don't get big enough to crash the box.

memory use still sucks at around 30M a process, meaning you can only have around 500 workers on at 16G RAM server, but it's workable. at least it's not rails.

because it takes a while to talk to even Memcache (go forbid you talk to MySQL) and do all your silly user updates (games are really write-heavy) you are taking a few hundred ms per request, so 16G mem servers (it's 2008) safely top out at around 500-600 req/sec, and i think would melt close to 1000 or so. remember, your throwing everything you have at growth and features so you're not really optimizing shit.

cool, just need more hardware. which is no problem. if you can get hardware. when you're co-located it takes forever to get new hardware online. not really an option. and even the F5 load balancers can only take so much. and there are issue with getting too many app servers talking to too many memcache servers. or something like that. after i left i think they saturated the data drops, which really puts you in a bind.

but that's not a problem now, with cloud services, right? except that those are not limitless either. i think FarmVille ran into a wall where AWS wouldn't / couldn't supply more instances (again, this was around 2009-10 so prob a lot better now). and those are still physical machines in physical datacenters somewhere that will have all the same problems and limitations and then some.

but you're going to have problems with any app runtime at that scale. and php's performance was an order-to-two or magnitude better than rails, and we never figured out how to get significantly complex and traffic-heavy java apps to stop leaking memory. though i'm sure you can. and you will! like i said, it's all solvable. hell, even MySpace didn't fail because of tech infrastructure.

what i'm saying is that php wasn't (and maybe still isn't?) particularly fun when throwing hardware at it doesn't work, and you end up losing a lot of the purity / simplicity of the model because it's too damn expensive. ffs, Facebook re-wrote the runtime. that's what it took for them. and my friends there tell me it's pretty much like writing java at this point. it's a fine choice, but i'd rather not use it again. had a much better time with python before javascript ate the world.

RethinkDB is AGPL? can you elaborate more on the issues? was planning on using Rethink, and this is making me, well, re-think it.

not sure if interpretations have changed in the last six years, but i went through an acquisition with a lot of focus on open source licenses in 2010 and from what i remember AGPL was not something you wanted to have touched with a ten foot ethernet cord if you had any proprietary code - the conservative stance being that AGPL could be read to potentially open source anything that communicated with it.

i know that's not how the license is explained or is "supposed to work", but the IP team's explanation (WSGR, seemed to know what they were talking about) is remember it was that copy-left licenses didn't have a lot of case law built up around them to clearly defined their de-facto legal mechanics. if you were a large company like Google, FB, etc., you could pretty much decide how you were going to interpret those licenses because you have the resources to defend those interpretations in court, but as a small company going through an acquisition this was a great way for an acquirer to say "hey, doesn't look like this stuff is really worth all that much because it's potentially all free."

people thought evernote was worth a bit of money at some point

yeah, I guess I sorta missed that... I mean the 'X' in AJAX was for XML... I've def been guilty of outputting "XML" with php tags. by the time we got to JSON there were libs available, or maybe we just wrote our own.

i think a major problem is that XML kinda looks and feels like HTML (and there was the whole XHTML thing to further confuse), and outputting HTML programmatically (vs string / print / template based) has most been frowned on as overweight and cumbersome.

you come from web dev doing HTML like that and you see XML and think "hey, that looks the same, i'll do it in the same way".

XML is a programmatic data exchange format like JSON or YAML, which most people would never think of outputting as templates or printed text, but it looks and feels like HTML, which most people deal with first and where that's the standard approach.

it's what you call the cops when you're more inclined to make a donation than make a run for it