For serious apps it's impossible to escape reading Erlang or Erlang documentation. Many functions and libraries simply aren't available for Elixir or are partial (see `opentelemetry_*` family as an example). Deep debugging is almost exclusively done with Erlang functions.
I'd even say that the more serious/critical application becomes the more weight shifts toward Erlang. Personally I'd go with Erlang-first, but only because I've accumulated thousands paper cuts from Elixir.
For starters Elixir has much more palatable syntax, though.
> For serious apps it's impossible to escape reading Erlang or Erlang documentation
Erlang documentation yes, but I VERY RARELY look at Erlang code. The only times I've really done it have been fiddling with an ODBC driver issue, which isn't really supported anymore by OTP, a crash dump maybe twice, and writing a dialyzer wrapper. I've been building elixir systems for over 10 years, and use OTP heavily,
But beyond syntax, how does the tooling compare? It seems that Mix is very convenient and feels like similar tools in other languages. I'd imagine that Erlang doesn't have an equivalent.
Overall Elixir tooling has more modern feel to it, but often it wraps around Erlang tools but.
Keeping mind that Erlang exists much longer than Elixir tooling for Erlang is more robust and mature. BUT its tooling revolves around advanced features e.g. hot updates. For webdev Elixir's tooling is capable enough.
There's no difference between you advertising something on your website vs. the chatbot that is on your website advertising something. It's something "the company" said either way.
There's generally protections in many jurisdictions against having to honor contracts that are based on obvious errors that should have been obvious to the other party however ("too good to be true"), and other protections against various kinds of fraud - which may also apply here, since this was clearly not done in good faith.
If you have an AI chatbot on your website, I highly recommend communicating to the user clearly that nothing it says constitutes an offer, contract, etc, whatever it may say after. As a company you could be in a legally binding contracts
merely if someone could reasonably believe they entered into a contract with you. Claiming that it was a mistake or that your employee/chatbot messed up may not help. Do not bury the disclaimer in some fine-print either.
Or just remove the chatbot. Generally they mainly piss people off rather than being useful.
There's a difference between the chatbot "advertising" something and an hour-long manipulative conversation getting the chatbot to make up a fake discount code. Based on the OP's comments, if it was a human employee who gave the fake code they could plausibly claim duress.
Think about if this happened in the real world. Like if I ran a book store, I’d expect some scammer to try to schmooze a discount but I’d also expect the staff to say no, refuse service, and call the police if they refused to leave. If the manager eventually said “okay, we’ll give you a discount” ultimately they would likely personally be on the hook for breaking company policy and taking a loss, but I wouldn’t be able to say that my employee didn’t represent my company when that’s their job.
Replacing the employee with a rental robot doesn’t change that: the business is expected to handle training and recover losses due to not following that training under their rental contract. If the robot can’t be trained and the manufacturer won’t indemnify the user for losses, then it’s simply not fit for purpose.
This is the fundamental problem blocking adoption of LLMs in many areas: they can’t reason and prompt injection is an unsolved problem. Until there are some theoretical breakthroughs, they’re unsafe to put into adversarial contexts where their output isn’t closely reviewed by a human who can be held accountable. Companies might be able to avoid paying damages in court if a chatbot is very clearly labeled as not not to be trusted, but that’s most of the market because companies want to lay off customer service reps. There’s very little demand for purely entertainment chatbots, especially since even there you have reputational risks if someone can get it to make a racist joke or something similarly offensive.
If having "an hour-long manipulative conversation" was possible, we have proof that company placed an unsupervised, error prone mechanism instead of real support.
If that "difference" is so obvious to you (and you expect it will break at some point), why don't you demand the company to notice that problem as well? And simply.. not put bogus mechanism in place, at all.
Edit: to be clear. I think company should just cancel and apologize. And then take down that bot, or put better safeguards (good luck with that).
Will the company go out of their way to do right by customers who were led to disadvantageous positions due to the chat bot?
Almost certainly not. So the disclaimer basically ends up becoming a one way get out of jail for free card, which is not what disclaimers are supposed to be.
If I go to your website and see a big banner with a promo code, you are obligated to honor it.
If you walk into any retail store in the US, the price on the shelf is legally binding. If you forgot to update the shelf tag, too bad, you are now obligated to sell at the old price.
If you advertise a price or discount, you are required to honor such. Advertising fictitious prices or discounts is an illegal scam.
Likewise, if you have some text generator on your site that gives out prices and promo codes, that's your problem. A customer insisting you honor that is not a scammer, they are exercising their legal right to demand you honor your own obligations to sell products at the price you advertised.
So, this is a scammy business trying to get out of their legal obligations to a customer who is completely in the right.
Lesson: don't put random text machines in your marketing pipeline in a way that they can write checks your ass can't cash.
This only applies to advertising. Not long, manipulative conversations with salespeople. Which is what happened. Any questions about this were conveniently deleted from the subreddit too.
Someone bashing on my pet language? Cracks knuckles
Just kidding. Some of those are stylistic choices I don't have gripes but can understand the criticism. There is however one thing about "Non-cuts are confusing" I'd like to clarify:
In this example:
foo(A, B) :-
\+ (A = B),
A = 1,
B = 2.
It's very obvious why it fails and it has nothing to do with non-cut. Let's say A can be apple and B can be orange and now you're asking Prolog to compare apples to oranges! ;)
In short one has to "hint" Prolog what A and B can be so then it can "figure out" whethever comparison can be made and what is its result. Assuming there exist is_number(X) clause that can instantiate X as a number following would work just fine:
foo(A, B) :-
is_number(A),
is_number(B),
\+ (A = B),
A = 1,
B = 2.
(note that this would be stupid and very slow clause. Instantiation in such clauses like is_number(X) usually starts with some defined bounds. For A = 10000, B = 10001 and lower bound of 1 pessimistic case this clause would require 100M checks!
I think that should be nonvar(A), nonvar(B) because the reason the unification succeeds and \+(A = B) fails is because A and B are variables (when called as foo(A,B). What confuses the author is unification, as far as I can tell.
But, really, that's just not good style. It's bound to fail at some point. It's supposed to be a simple example, but it ends up not being simple at all because the author is confused about what's it supposed to behave like.
My site is hosted on Cloudflare and I trust its protection way more than flavor of the month method. This probably won't be patched anytime soon but I'd rather have some people click my link and not just avoid it along with AI because it looks fishy :)
I've been considering how feasible it would be to build a modern form of the denial of service low orbit ion cannon by having various LLMs hammer sites until they break. I'm sure anything important already has Cloudflare style DDOS mitigation so maybe it's not as effective. Still, I think it's only a matter of time before someone figures it out.
There have been several amplification attacks using various protocols for DDOS too...
Yeah I meant using it as an experiment to test with two different links(or domains) and not as a solution to evade bot traffic.
Still, I think it would be interesting to know if anybody noticed a visible spike in bot traffic(especially AI) after sharing their site info in that thread.
act is often mentioned as a drop-in replacement but I never got it to replicate GitHub actions environment. I didn't try it for this particular case, though.
Also branches that are write-only by a single person by consensus. E.g. "personal" PR branches that are not supposed to be modified by anyone but owner.
Allow me (today) to be that person to propose checking out Jujutsu instead [0]. Not only it has a superpower of atomic commits (reviewers will love you, peers will hate 8 small PRs that are chained together ;-)) but it's also more consistent than git and works perfectly well as a drop-in replacement.
In fact, I've been using Jujutsu for ~2 years as a drop-in and nobody complained (outside of the 8 small PRs chained together). Git is great as a backend, but Jujutsu shines as a frontend.
You don't have to chain 8 PRs together, Github tries really hard to hide this from you but you can in fact review one commit at a time, which means you don't need to have a stack of 8 PRs that cascade into each other.
Yup, that's what my team does. It works wonderfully, and it fits well with Github's "large PR" mindset imo. It could be a bit better in the Github UI, but so can most things. I vastly prefer it to individually reviewing tons of PRs.
The funny thing about this debate for me is that i find it comes down to the committer. If the committer makes small commits in a stacked PR, where each commit is a logical unit of work, part of the "story" being told about the overall change, then i don't personally find it's that useful to stack them. The committer did the hard part, they wrote the story of changes in a logical, easy to parse manner.
If the story is a mess, where the commits are huge or out of logical order, etc - then it doesn't matter much in my view.. the PR(s) sucks either way.
I find stacked PRs to be a workflow solution to what to me is a UI problem.
I've seen that you can read one commit at a time, but never anything for reviewing (or diffing between them if they change) - is there a UI beyond just clicking on the list of commits?
Though I forget if you can even comment in the individual commits in that view. Complex multi-commit PRs have generally been a nightmare on GitHub in my experience.
You can comment on the individual commits' changes, but you can't comment on the commit (e.g. its message) itself. I believe you can do this in Gerrit.
Which means it's probably all I have seen - so you can't approve commits either, or track file-reading progress through commits (I think? i.e. "viewed file X at commit Y, but not at commit Z"), or diff changes to a commit (e.g. by order/message) after a rebase, just "you can see the current commit history". Not sure I'd consider that "can review one commit at a time", just "can read one commit at a time". "Review" means "there is support for this thing as a first class entity" imo, and that ain't what github is offering, nor anything even close to it.
That's true, but acceptance is still all or nothing.
When chaining commits it's possible to (for example) have a function that does THING and then have another PR that have a function that uses first one.
It's somewhat PITA when team has no-dead-code hard rule, but otherwise it's quite manageable and invites rich feedback. Reviewer and feedback can focus on atomic change (in example: function that does THING) and not on a grand picture.
Does that happen on merge or before PR creation? I thought the setting only applied it when you hit the merge button, so you'd still have commits prior to the merge. Though that won't help if someone pre-squashes them :s
Happens on merge, sure, but the end result is that you kinda lose the individual commits. You can still find them in the PR, but you won't see them in the git history, so git blame will just point you to the one big squashed commit.
If you, however, open a chain of 8 PRs, and merge them in the right order, the individual commits will be persisted in the git history. Potentially worth it if you like to have a "story" of several commits...
The key thing to point out is that jujutsu is a rebase-based workflow, and no on who uses jujutsu ever worries about rebasing (they may not even be aware of it). It's a good demonstration of a tool that got rebase right, unlike git.
Pre-jujutsu, I never rebased unless my team required it. Now I do it all the time.
Pre-jj, I never had linear history, unless the team required it. Now most of my projects have linear history.
And if a major problem, `jj op log` + `jj op log restore` fix it. This is the major super power of jj: Before I need to nuke the git repo on bad rebases (not chance in hell I can find how undo the massive 20+ steps bad rebase)
What is the problem with submodules? I like to use them because it means the code I need from another repo remains the same until I update it. No unexpected breaking changes.
I'm a big fan of rebasing to keep the commit history clean and as a form of self-discipline when coding to make sure I'm grouping the changes atomically.
I will try to give Jujutsu a go based on your recommendation!
The comments sections in git posts vs. jj posts are always hysterical to me.
If there’s a jj post on HN, people come out of the woodworks to say that git is easy and it’s crazy to suggest that anyone finds it difficult or confusing. Also people saying they’ve figured out git is super usable if you only ever use commit, merge, pull.
Then you have git posts where everyone talks about how hard some basic things are, how easy it is to mess up your repo, how frustrating rebase is, etc.
I used to think like this, but then I realized: jj-mode.el exists[0] and you can still use magic since it's still a git repo underneath. Seriously, don't let this hold you back.
I took a look at both, and I think I'd need the jj split function (comparable to staging individual lines) to be implemented in jj-mode to match my use of magit.
You can already do this if you just open up your change in magit and repeatedly commit pieces of it. I agree it's not super ergonomic since it leaves an old change behind and it requires using magit on top of jj-mode but it's 90% of the way there.
I’ve not had any luck with that tool in terms of creating meaningfully reviewable prs. I’m hoping I can maybe leverage graphite for the stack generation while authoring everything in jj. We’ll see how that goes
I'd even say that the more serious/critical application becomes the more weight shifts toward Erlang. Personally I'd go with Erlang-first, but only because I've accumulated thousands paper cuts from Elixir.
For starters Elixir has much more palatable syntax, though.
reply