Spiwux

I've implemented several of these ideas, and they worked just fine.

I don't understand the architecture section. The title is "layered architecture," but then it talks about Ports/Adapters, which would be hexagonal architecture?

I was about to leave a very witty "just be idempotent ;)" response but did not consider the nonce. I'd be surprised if Google is quick to change this, so I guess be stateful on the receiving server, persist that you handled a certain request already, and if you get a duplicate request, replay the response from the first one?

They're clearly trying to imitate human interaction, and believe it or not, the vast majority of humans have genders they're perfectly happy with.

At this point, I cannot take these kinds of safety press releases serious anymore. None of those models pose any serious risk, and it seems like we're still pretty far away from models that WOULD pose a risk.

After having used Datadog for several years, going back to Grafana / Loki / Prometheus felt like regressing by two decades. As much as I appreciate free solutions, I feel like Grafana has really fallen behind when it comes to developer experience

Calling Postgres experts:

Why, exactly, do we need to put a memory cache such as Redis in front of Postgres? Postgres has its own in-memory cache that it updates on reads and writes, right? What makes Postgres' cache so much worse than a dedicated Redis?

I'm assuming you're targeting this mainly at enterprises and business use-cases such as callcenters, but are you planning to make this usable for personal use cases as well? For example, having a bot to bounce ideas off while coding. Pretty much "just" the TTS / STT layer to talk to my finetuned LLM in a natural manner while you handle interruptions and such.

I think the main issue right now for personal use would be cost (and I'm guessing STT / TTS are the most expensive parts..)

I really do not understand these memes about overengineered FactoryFactoryFactories. I have 10 YOE, did I just get lucky? I've worked at enterprise Java shops as well, but even there I'd call the software pragmatic. Are these overengineered monstrosities REALLY still a thing, or is it "just" people suffering in legacy projects? Even the juniors I worked with were following KISS and YAGNI.

Cool tech demo, not even close to a level quality I'd consider paying for

I wonder if we're at a point where you could build a voice assistant like that, except almost-realtime and streamed end to end:

User speaks and speech to text starts streaming text while the user is still speaking. That text stream is piped into a LLM, which also streams its output text. That output text is streamed to text-to-speech, which also generates audio in a streaming manner.

Guilty until proven innocent. Very thoughtful take.

Great. Glad to see we're still world leaders at shooting ourselves in the foot. It makes sense to regulate AI use in critical infrastructure and flat out outlaw use of AI to manipulate public opinion, but that's where it should have stopped.

At the risk of sounding like a complete idiot, isn't the hypothesis of the original paper still true? Let's assume self assessment score is perfectly random between 0% and 100%, so on average every group will always estimate themselves to be 50% correct

Then by definition that means people who are unskilled and often incorrect will overestimate themselves, while people who are often correct will underestimate themselves. Take a complete idiot for example. You always get 0% test score. Yet your self-assessment is random between 0% and 100%. Hence you overestimate yourself much more often than people who always get 100% test score.

In fact, if the two are uncorrelated, then that still means that

1) Idiots don't recognize they're idiots

2) Skilled people don't recognize they're skilled

Maybe I'm too spiteful, but with leadership like that I would've just looked for a new job and let the entire ship sink.

Sometimes I have this urge to try getting into a manager role. I really want to see and experience for myself if most managers I work with are just bad at their job, or if being a "good" manager is simply impossible and you're doomed to fail regardless of skill.

Are you suggesting everybody should use event sourcing instead of using transactions? Because the general consensus on event sourcing is "don't use it unless you absolutely have to."

You're saying that a software startup's selection of available engineers is so limited that it's not possible to approach general population demographics?

Yes, because engineers don't follow general population demographics.

In 2021 alone, over 100k people graduated with bachelor's degrees in computer science. That sample size is too small to approach general population demographics?

Yes. Again, that sample too does not follow population demographics.

Okay, let's lower the bar. Why doesn't your staffing at least approximate the demographics of computer science graduates?

It does. Which is why I said "mostly" (but not exclusively) male. However that is not a "lowered bar", that is the only possible way things can work out. Unless you argue that a number of male engineers should be systematically doomed to never be hired in the name of equality, because otherwise we cannot reach your perfect demographic distribution.

That makes no sense. You don't just hire people out of the whole general population, you hire people with skills you need. If a tech startup hires engineers those will be mostly male. Not because the startup is sexist, but because there are more male engineers around.

Yes, pretty much. It's a pain to write, but easy to read. On a larger scale the average engineer likely spends more time reading code than writing code

You discovered the Zen of Go. There are no magic one liners. It's boring, explicit and procedural.

Proponents argue that this forced simplicity enhances productivity on a larger organisational scale when you take things such as onboarding into account.

I'm not sure if that is true. I also think a senior Python / Java / etc resource is going to be more productive than a senior Go resource.

I have such a love-hate relationship with this language. I use it professionally every single day, and every single day there are moments when I think to myself "this could be solved much more elegantly in language X" or "I wish Go had this feature."

Then again I also can't deny that the lack of ""advanced"" features forces you to keep your code simple, which makes reading easier. So while I hate writing Go, I like reading unfamiliar Go code due to a distinct lack of magic. Go code always clearly spells out what it does.

e.g.

  var typeA Interface = (*TypeA)(nil)
  println(typeA == nil)           // false
  println(typeA == (*TypeA)(nil)) // true

Is this the best possible demixing you can get? Or did you have to use a smaller / lower quality model to make it run in browsers?

I'm going to get blasted for this, but you *are* doing scrum wrong. Scrum was invented by engineers to defend themselves against incompetent middle managers. The moment you let management take the process over and warp it you are already doing it wrong.

Story points and sprints are a *self-calibrating* tool that will give you an advance warning (nicely visualized in burn-down charts) if an estimate you might have given a middle manager will be missed.

You do not "decide" how many points fit in a sprint, you just work at a sustainable pace and *measure* how many points fit in a sprint.

Nearly every single point in that tweet just screams bad management and bad engineers without any agency.

Marketing hint: Given that you'll be competing with Copilot I'd love to see examples where Copilot fails and Cody does better.

Also there are several typos on the linked page, you might want to read it over a few more times

Don't think I could disagree any harder. Requirements change. Business needs change. You want your FE to be able to evolve independently without having to wait for the BE to implement the precise logic you need.

Why, what's wrong with

func TraverseParTuple10[F1 ~func(A1) ReaderIOEither[T1], F2 ~func(A2) ReaderIOEither[T2], F3 ~func(A3) ReaderIOEither[T3], F4 ~func(A4) ReaderIOEither[T4], F5 ~func(A5) ReaderIOEither[T5], F6 ~func(A6) ReaderIOEither[T6], F7 ~func(A7) ReaderIOEither[T7], F8 ~func(A8) ReaderIOEither[T8], F9 ~func(A9) ReaderIOEither[T9], F10 ~func(A10) ReaderIOEither[T10], A1, T1, A2, T2, A3, T3, A4, T4, A5, T5, A6, T6, A7, T7, A8, T8, A9, T9, A10, T10 any](f1 F1, f2 F2, f3 F3, f4 F4, f5 F5, f6 F6, f7 F7, f8 F8, f9 F9, f10 F10) func(T.Tuple10[A1, A2, A3, A4, A5, A6, A7, A8, A9, A10]) ReaderIOEither[T.Tuple10[T1, T2, T3, T4, T5, T6, T7, T8, T9, T10]]

(https://pkg.go.dev/github.com/IBM/fp-go/context/readerioeith...)

Go is not a functional language and its generic type system is very restrictive. Why not use a functional language to begin with?

Reading the comments to this submission made painfully clear that a significant portion of HN commenters are posting their opinions without even reading the linked article first.