_______ __ _______ | |
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----. | |
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --| | |
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____| | |
on Gopher (inofficial) | |
Visit Hacker News on the Web | |
COMMENT PAGE FOR: | |
Pydantic Logfire | |
OutOfHere wrote 21 hours 47 min ago: | |
I would rather use something five times worse or simpler that I could | |
self-host than be forced to rely on some service. | |
gazpacho wrote 22 hours 47 min ago: | |
Iâd like to address a lot of the questions about self hosting: we do | |
not currently have any way to self host, but we do plan on figuring | |
that out eventually. Offering self hosting introduces challenges around | |
updates, support, etc that we donât want to slow us down while we | |
refine the product to its initial state. We are cognizant of data | |
restrictions and other factors that would require self hosting. That | |
said, we donât at this time plan on completely open sourcing the | |
entire product. It would be more of a licensing setup. Of course this | |
is all subject to change in the future based on feedback and product | |
direction. | |
The most important thing is that you share with us WHY you want to self | |
host. Is it compliance? What does that compliance mean (min/max data | |
retention, right to be forgotten, data at rest needs to be | |
geographically located or you have to own it, etc)? This will help us | |
build the ârightâ kind of features in this area so that it works | |
for you and your company. | |
feydaykyn wrote 6 hours 47 min ago: | |
GDPR on our side too, we need to reduce subcontractors as much as | |
possible to handle all the requirements you listed. Also, we have to | |
renegotiate with our own customers every time we want to had a new | |
subcontractor, so we avoid doing so at all costs. | |
I like the prefect.io approach to have the control plane on the | |
external provider, with the data and workers being run on the | |
customer infrastructure. It seems fair for both sides: | |
- as the subcontractor, you keep trace of the real usage, without | |
having to handle end user data which is a pain to manage, so you | |
don't have to offer outrageous license pricing to compensate for | |
being stolen (looking at you Grafana) . | |
- as the company, you comply with gdpr, while alleviate the operating | |
costs, and also supporting the companies providing the tooling you | |
need. | |
kbumsik wrote 21 hours 32 min ago: | |
> WHY you want to self host. | |
In my case, I am hesitate to add another cloud service in the | |
Sub-Processor list to meet GDPR. | |
Actually, if it is an Otel wrapper, I don't think you don't need to | |
offer self-hosting the server at all. Making easy to integrate with | |
other Otel ecosystems would be enough. | |
> It would be more of a licensing setup. | |
At least this is much better than FOSS first than switching to a | |
non-FOSS license like what happened to hashicorp and redis. | |
mulmboy wrote 1 day ago: | |
Is self hosting possible? Can't see any mention in the docs | |
ryanisnan wrote 1 day ago: | |
It looks like it's on the roadmap, but my interpretation of the | |
project would be that this is would be behind a licensed paywall. | |
[1]: https://docs.pydantic.dev/logfire/roadmap/#on-premise-deploy... | |
mariocesar wrote 1 day ago: | |
It is a great tool! Congratulations on launching it! | |
Could you clarify if it's possible to self-host the service? | |
scolvin wrote 1 day ago: | |
We'll offer self hosting for enterprise. | |
I want the entry level for "enterprise" to be much lower than some | |
other companies in this space. | |
cqqxo4zV46cp wrote 1 day ago: | |
For your consideration: I work in an industry which commonly | |
involves data residency requirements / restrictions. Contrary to | |
the belief seemingly held by every VC-funded cookie | |
cutter-business-model SaaS company out there, this doesnât make | |
us âenterprise-yâ, nor does it mean that we are flush with cash | |
to splash on âcontact salesâ-tier Enterprise SaaS | |
subscriptions. This ham-fisted market segmentation is a constant | |
frustration for me. Please, please, please keep this in mind. | |
logfire_q wrote 1 day ago: | |
can i self host logfire? based on the âlogfire authâ in the docs | |
iâm thinking no? | |
barapa wrote 1 day ago: | |
I'm already using it and I think it's great. Well done Samuel and team! | |
megaman821 wrote 1 day ago: | |
Does this do logging or just traces? More to the point, is it | |
economically to store tens of millions of log lines a month? | |
dmontagu wrote 1 day ago: | |
I'm one of the Pydantic/Logfire devs â we are actually aiming to | |
unify the ideas of logging and tracing a bit more than seems common | |
in most such tools â our logfire SDK actually emits spans for all | |
of the traditional logging statements rather than relying on OTel | |
logging infrastructure (which seems to be kind of a legacy-oriented | |
afterthought relative to the tracing APIs/infrastructure). So, yes, I | |
would say we do support logging (certainly on a conceptual level), | |
though the point is to try to move toward a world where as much as | |
possible is done with spans, if only as an implementation detail. | |
We also have explicit integrations with popular logging packages (see | |
the bottom of [1] ), so if you use the standard library `logging` | |
module, `structlog`, or `loguru`, you should be able to set up your | |
logs to ship to Logfire with minimal modifications to your existing | |
code. | |
While we have not announced our pricing yet, I am confident that tens | |
of millions of log lines a month will absolutely be economical to | |
store. | |
(Also, I'll just add that we also support metrics, though our metrics | |
support is not as well-integrated yet as tracing. But soon!) | |
[1]: https://docs.pydantic.dev/logfire/integrations/#opentelemetr... | |
laborcontract wrote 1 day ago: | |
I was just looking for a logging service. Really enjoy Pydantic so | |
this looks like it may be a delight. | |
Try not to surprise us on pricing, though. | |
cipherself wrote 1 day ago: | |
From the screenshots, it seems very much to be about tracing. | |
jmduke wrote 1 day ago: | |
OP: as someone who runs a Python business and is a happy user of | |
Pydantic (via Django-ninja) â something I would want this splash page | |
to convey, at least implicitly, is âwhy use this over Sentry?â As | |
far as I can tell, the answer is: an OpenAI binding and stronger Otel | |
support. | |
(That being said, I am a sucker for all new tooling in this genre and | |
am excited to play around with it!) | |
cqqxo4zV46cp wrote 1 day ago: | |
Also, Iâm pretty sure that Sentry has OpenAI bindings now? | |
jmduke wrote 1 day ago: | |
Responding to my own post: this comment ( [1] ) I think is a very | |
compelling answer. I love the design language of the splash page, but | |
I think the copy could be improved by a little less "here is why | |
performance insights are useful" (which I think most people are kind | |
of already on board with) and more "here is why our performance | |
insights are _particularly_ more useful than the competition". | |
[1]: https://news.ycombinator.com/item?id=40214695 | |
drchaim wrote 1 day ago: | |
The ideal business model (from a user's point of view) for successful | |
libraries like Pydantic, Ruff, etc., is like a foundation or | |
sponsoring. But (almost) nobody pays for them (me included), so their | |
creators have raised VC money, citing: 'We have xxM users and yyyyyM | |
downloads per month.' Not to blame library authors here, they are | |
trying their thing, which is indeed admirable. It's just that open | |
source is difficult to sustain. Wishing them all the best | |
MapleWalnut wrote 1 day ago: | |
It'll be hard to position this against Sentry. Sentry's a joy to use | |
and their performance product is so helpful in debugging performance | |
issues | |
Lucasoato wrote 1 day ago: | |
One of the Sentry inconvenience is self-hosting: it relies on so many | |
services it can be very complicated to maintain. | |
mdaniel wrote 1 day ago: | |
I draw ones attention to the actual Open Source glitchtip which has | |
a much more sane deployment, akin to the good old days of Sentry | |
before they got Big Data-itis: [1] (or its helm version, similarly | |
not JFC [2] ) | |
[1]: https://gitlab.com/glitchtip/glitchtip-backend/-/blob/v4.0... | |
[2]: https://gitlab.com/glitchtip/glitchtip-helm-chart/-/tree/6... | |
feydaykyn wrote 7 hours 1 min ago: | |
GlitchTip is very simplistic and miles away from Sentry. | |
We really wanted to keep using it, since it was easy to selfhost, | |
but the UI was not giving enough information from a dev | |
perspective to be very useful : grouping, filtering and labeling | |
issues is very basic, which prevents understanding. | |
We decided to self host sentry, which is an absolute beast to | |
deploy, the open-source helm chart is nowhere near production | |
level, and the underlying technologies are quite hard to maintain | |
(Kafka, zookeeper, clickhouse...). We had to work on it | |
constantly for two months to stabilize it, and now fear the | |
moment we'll want to update. The dev teams love it, so it was | |
worth the hassle! | |
mdaniel wrote 6 hours 1 min ago: | |
Out of curiosity, did you file issues against GlitchTip about | |
your needs and they received no traction? | |
zeeg wrote 6 hours 48 min ago: | |
This is something we're (Sentry) not happy about. Always hard | |
to maintain the simplicity with growing product functionality. | |
There's efforts underway (e.g. [1] ) to reduce the footprint if | |
you only need portions of the functionality. | |
[1]: https://github.com/getsentry/self-hosted/issues/1763 | |
threecheese wrote 1 day ago: | |
Iâm not sure if you are responding to the wrong comment, or OP | |
edited, but I am fascinated by what you posted and so can you | |
explain a little bit? | |
mdaniel wrote 21 hours 53 min ago: | |
I was responding to the One of the Sentry inconvenience is | |
self-hosting: it relies on so many services it can be very | |
complicated to maintain part, and also reminding readers that | |
if they, too, hate companies that rug-pull their open source | |
licenses, there is a band-aid for both parts | |
Compare [1] with [2] for what life used to be like for running | |
Sentry on-prem. It was awesome | |
It would take a ton of work to dig up the actual memory and CPU | |
requirements of each one, but rest assured they're not zero, so | |
every one of those services eats ram and requires TLC when, not | |
if, they shit themselves. So, more parts == more headaches with | |
all other things being equal | |
Then, I deeply appreciate that there are a whole spectrum of | |
reactions to the various licensing schemes in use nowadays, and | |
a bunch of folks don't care. I care, though, because I have | |
gotten immense value from open source projects, and have | |
contributed changes back to quite a few. It has been my life | |
experience that many of those "source available" licenses | |
usually are very hostile toward making local real builds and if | |
I can't build it to match how prod goes, then I can't test my | |
fixes in my environment and then I can't contribute the PR with | |
any faith | |
[1]: https://github.com/getsentry/self-hosted/blob/9.1.2/do... | |
[2]: https://github.com/getsentry/self-hosted/blob/24.4.2/d... | |
zeeg wrote 6 hours 52 min ago: | |
Where was the rug pull? The only people negatively impacted | |
by Sentry's relicensing were people trying to monetize it. | |
Did we negatively impact you? Anyone else in the community? | |
Not that I've ever seen evidence of. | |
Live and die on your hill. We'll keep focusing on building | |
our product - which requires us to be able to be able to pay | |
developers for the enormous amount of time it takes them. | |
mdaniel wrote 6 hours 4 min ago: | |
> Where was the rug pull? | |
I ordinarily would have just ignored your troll comment, | |
but this was so incredibly short sighted that you were | |
obviously wanting some sparks so now you'll get them. | |
Sentry didn't start life with a source available license, | |
even though the threat model to the business was exactly | |
the same at that time: the cloud for sure existed, I know | |
because I ran Sentry self-hosted upon it. And your cited | |
enormous amount of time and money to pay developers didn't | |
spontaneously spring into being 6 months ago, either. So, | |
the tone that was set was that Sentry was open source with | |
all the rights and privileges that came with it. Until | |
someone got butthurt and decided they needed not just one | |
source available license but then their own source | |
available license just to ensure lawyers never go hungry | |
> Live and die on your hill. | |
You, too. Enjoy your mansions and yachts from all the | |
ontold riches that your new licensing scheme will surely | |
bring you in exchange for lighting fire to any trust gained | |
zeeg wrote 5 hours 39 min ago: | |
The challenge with making statements like this is you're | |
making them against not only the person who made the | |
decisions, but also the person who holds 100% of the | |
facts, and will openly share them. | |
So lets talk about the facts, because the paint a pretty | |
clear narrative, rather tha one that people would prefer | |
to believe. | |
1. I built most of Sentry (back then), and while we had a | |
few contributions here and there, it was almost | |
exclusively my time, or future employees times. So no | |
community contribution concerns. | |
2. We relicensed because of a new threat, not one that | |
existed 16 years ago when I started the project. That | |
threat was GitLab, who was openly trying to commercialize | |
Sentry. They never once contributed to the project, nor | |
did they want to contribute back as part of that | |
strategy. I know this to be true because I asked them to. | |
3. We built the FSL because the BUSL did not create a | |
strong enough conviction to our values - of which we | |
repeatedly have put words into action on. We wanted to | |
cement those values, and make it easier for people who | |
had our same concerns, but also wanted to create more | |
open source, to be able to achieve that _without_ undue | |
risk or legal fees. | |
There is a huge difference in the way Sentry operates, | |
and the way some of these other organizations have chosen | |
to relicense (or in some cases, legitimately rug pull). | |
So you can say what you will, but we've always been | |
straight forward with our beliefs, and talk about these | |
things publicly all the time. I'm not here to convince | |
you of changing your beliefs, but I will never sit idly | |
when people spread false information, especially about | |
us. [1] | |
[1]: https://cra.mr/the-busl-factor | |
[2]: https://cra.mr/open-source-and-a-healthy-dose-of... | |
mdaniel wrote 21 hours 35 min ago: | |
I'm also going to enjoy some popcorn when they don't upgrade | |
their redis image past 7.2.4 due to the "AWS^H^H^HSentry | |
gonna steal our shit" license change. Turns out, everyone | |
taking their ball and going home doesn't make for a | |
collaborative environment -- who could have foreseen?!11 | |
esafak wrote 1 day ago: | |
Does the self-hosted version have all the features? | |
easton wrote 1 day ago: | |
yes, every feature (but billing, iirc) is in self hosted. which | |
means you need all of their backend dependencies (kafka, | |
zookeeper, other things that are probably easier to manage than | |
those two) | |
whit537 wrote 6 hours 40 min ago: | |
We've started working on addressing this, fwiw: | |
[1]: https://github.com/getsentry/team-ospo/issues/232 | |
zbentley wrote 1 day ago: | |
This smells a bit like someone is using the brand of a famous | |
open-source tool they built to promote their startup. If so, that's | |
lame; if the new business is unrelated to your open source project, | |
branding it as Pydantic Logfire seems a bit disingenuous. | |
I think there's a less-misleading way to use open-source reputation for | |
business credibility, though: "so-and-so business, by the creators of | |
so-and-so project". Knowing that respected and skilled folks are | |
working on a business is great! It's a fine distinction, but I think it | |
matters. | |
cqqxo4zV46cp wrote 1 day ago: | |
Itâs very telling that you didnât give an actual concrete example | |
of how someone could get confused/misled, what that would look like, | |
and what itâd result in. This is nothing more than a baseless | |
whinge. | |
barapa wrote 1 day ago: | |
From the website: | |
From the team behind Pydantic, Logfire is a new type of observability | |
platform built on the same belief as our open source library â that | |
the most powerful tools can be easy to use. | |
robrenaud wrote 1 day ago: | |
Finding ways to reward people for building great open source software | |
is something that we need more of. It's not lame at all. | |
esafak wrote 1 day ago: | |
It is related, though: the creator is the same, so you can expect the | |
same DX. | |
scolvin wrote 1 day ago: | |
If anyone is mislead about whether Pydantic is Logfire or visa-versa, | |
I'll eat my hat. | |
Other than that, see my answer to the other comment. | |
nsteel wrote 1 day ago: | |
For the record, I don't agree with the grandparent comment at all. | |
None of this is "lame". It's a path to sustainable OSS and it's | |
more obvious than ever that we need these pathways. | |
But to be fair, the branding here is a little weird. If you were | |
living under a rock and hadn't heard of pydantic then the website | |
reads like pydantic is the company and logfire is a product of said | |
company. That's fine. But then you've also got a product called | |
pydantic. Or is it now called pydantic pydantic? I realise it's | |
kind of an extension to pydantic but the AI focus doesn't make it | |
feel that way and so I think that's where the GP is coming from. | |
Sorry to nitpick, I hope it does well. | |
scolvin wrote 1 day ago: | |
I think that's fair. It's a hard problem. | |
We could have called the company a completely new name and | |
everyone would have been confused, or just called us "pydantic". | |
I think Pydantic being the company name, and a standalone entity, | |
and there being other products is fairly common. I think if | |
Logfire is successful, it will end up just being known as | |
"Logfire". | |
JimDabell wrote 20 hours 10 min ago: | |
> We could have called the company a completely new name and | |
everyone would have been confused | |
I donât see how anybody would have been confused in that | |
scenario? People start new companies with new names all the | |
time. | |
What you are actually doing is what is confusing. Itâs a | |
really weird branding choice to name an observability platform | |
startup after a validation library. | |
esafak wrote 1 day ago: | |
This is just how you brand when you have one product. If he made | |
up a new brand to subsume both products nobody would recognize | |
it, so he wisely decided to recycle the existing brand; familiar, | |
and liked. | |
Google was originally just the search engine, without any | |
qualifier. Now it's Google Search. In the same way, pydantic can | |
become "Pydantic Validate" or something. | |
serjester wrote 1 day ago: | |
I love pydantic but I really have to wonder why they chose this route. | |
There's already a ton of companies that do this really well and I'm | |
trying to figure out how their solution is any different. | |
The llm integration seems promising but if you care about LLM | |
observability you probably also care about evals, guardrails and a | |
million other things that are very specific to LLM's. Is it possible to | |
build all this under one platform? | |
I do hope I'm wrong for the sake of pydantic-core. | |
scolvin wrote 1 day ago: | |
Pydantic creator here. | |
I understand why this might be your reaction, but let me just share | |
my thoughts: | |
Can we build all the LLM things people want? Yes I think so, early | |
feedback is that Logfire is already much more comprehensive than LLM | |
specific solutions. | |
How is our solution any different? AFAIK: | |
* no one else offers opinionated wrapper for OTel to make it nicer to | |
use, but with all the advantages | |
* no one else does auto-tracing (basically profiling) using import | |
hooks the way we do | |
* no one else has dedicated instrumentation for OpenAI or Pydantic | |
* no one else provides metadata about python objects the way we do so | |
we can render a semi-faithful repr of complex objects (Pydantic | |
models, dataclasses, dataframes etc.) in the web UI | |
* no one else (except Sentry, who are doing something different) | |
makes it really easy to start using it | |
* no one else lets you query observability data with SQL | |
In my mind, the obvious alternative would be to do the thing most OSS | |
companies do, and build "Pydantic Cloud", then start adding features | |
to that instead of the open source package. I didn't want to do that, | |
and I don't think our users would like that either. | |
In the end I decided to build Logfire for two reasons: | |
1. I wanted it, and have wanted it for years | |
2. I think building a commercial product like this, then using OSS to | |
spread the word and drive adoption is a really exciting way to | |
incentivize us to make the open source as good as possible â good | |
as-in permissive and good as-in well maintained. And it means that | |
our commercial success is not in tension with the adoption of our | |
open source, which has been a recurring issue for companies trying to | |
capitalize on their open source brand. | |
nirga wrote 15 hours 32 min ago: | |
OpenLLMetry creator here. Weâre building the most popular | |
OpenTelemetry instrumentation for LLm providers including OpenAI, | |
Anthropic, Pinecone, Langchain and >10 others since last August | |
[1]. Weâre using import hooks (like other otel instrumentations), | |
and offer an sdk with a one line install. | |
Iâm also aware of other OSS initiatives doing similar | |
initiatives, so I wouldnât say no one has ever done what your | |
doing. | |
[1]: https://github.com/traceloop/openllmetry | |
kakaly0403 wrote 7 hours 54 min ago: | |
+1 to this. Langtrace core maintainer here. We are building a SDK | |
and a client for automatic instrumentation of LLM based | |
applications using OTEL standards. The OpenLLMetry team along | |
with the CNCF OpenTelemetry working group has been doing some | |
great work standardizing semantic naming conventions and we are | |
starting to adopt the same set of standards. [1] | |
[1]: https://github.com/Scale3-Labs/langtrace | |
[2]: https://github.com/open-telemetry/semantic-conventions/b... | |
btown wrote 1 day ago: | |
This is very cool. Could someone use Logfire alongside Honeycomb or | |
another OTel platform? Honeycomb's strengths in drilling into an | |
interactive chart vs. Logfire's strengths in drilling into a stream | |
of text logs (and SQL support!) seem very complementary. | |
Certainly seems like the Logfire initializer could coexist with | |
code like in [1] - is this a reasonable assumption? We're looking | |
into modernizing our Honeycomb integration from their older direct | |
integration to their OTel SDK, and would be very curious if Logfire | |
can exist alongside this. Do you do any patching of OTel internals | |
that would make this impossible? | |
[1]: https://docs.honeycomb.io/send-data/logs/opentelemetry/sdk... | |
scolvin wrote 1 day ago: | |
You can send data from any OTLP endpoint, so yes. | |
I don't think we currently expose an easy way for you to send | |
data to two (e.g. honeycomb and logfire), it it should be | |
entirely doable, and if people want that, we can make it easy. | |
serjester wrote 1 day ago: | |
Thanks for the response, massive kudos - I look forward to trying | |
it out! | |
hakanderyal wrote 1 day ago: | |
Useful product, great marketing site. This is obviously a labor of | |
love. Keep it up! | |
Sadly I've moved on from Python world. | |
Funny anecdote, using Pydantic everywhere to improve | |
maintainability made me realize I'm fighting an uphill battle with | |
Python and I should move to a statically typed language, so I | |
switched to C#. | |
Thanks for your work. | |
BurningFrog wrote 1 day ago: | |
When I get tired of Python, I think of working in Ruby instead. | |
Maybe it's the Python disease of trying to be everything at once, | |
which can end up as the worst of all worlds. | |
Ruby is a proudly untyped language, and that's all it is. | |
neonsunset wrote 10 hours 1 min ago: | |
It does not offer better productivity, sometimes worse due to | |
brittleness, at the cost of 0.1x performance of .NET. | |
It is this easy to make a back-end application with ASP.NET | |
Core: | |
[1]: https://learn.microsoft.com/en-us/aspnet/core/fundamen... | |
necovek wrote 1 day ago: | |
This is admittedly an unpopular opinion. | |
I've actually really wondered why one wants static typing, | |
especially with a language as expressive as Python, and where you | |
can be so efficient with it? | |
At a time, I was mesmerized with Zope (esp 3), but learned that | |
nobody really learns to use it, but instead learns to work around | |
it â for the uninitiated, Zope provided "interfaces", you'd | |
have classes implementing those interfaces, and you could happily | |
mix and match with "configuration" that lived in ZCML (an XML | |
schema) files, way back in early 2000s. | |
Static typing really kills off some of the biggest benefits of | |
using Python (like "duck typing" to quickly emulate an identical | |
API without having to construct a hierarchy of types before you | |
can do that). | |
How many bugs have you really hit in your Python code because of | |
lack of static types? For ~20 years of doing Python, I honestly | |
believe that it could have helped me at most once or twice. | |
Generally, doing sufficient level of testing has covered most | |
potential misuse of code, and you need to have tests anyway. | |
The reason I'd want to move away from Python is mostly pure | |
performance (loops should not be this slow) and library ecosystem | |
(crappy code has risen to the top), but I find nothing is nearly | |
as expressive, has a comparable standard library plus allows one | |
to be so efficient. | |
hakanderyal wrote 21 hours 4 min ago: | |
Main selling point for me is productivity. Performance benefits | |
are just icing on the cake. | |
Being explicit about types allows the IDE and platform to help | |
you write & refactor code, allowing your brain to work on the | |
actual problem instead. | |
This may sound surprising but modern C#/.NET is almost as | |
expressive as Python. You don`t need unnecessary boilerplate or | |
AbstractBaseFactorySingletonProxyDecoratorAdapterWrapper style | |
types. LINQ alone is a game changer. I`m still writing code | |
with almost same style as Python in C#, but now with the power | |
of IDE behind me. I`m much more productive. | |
Interfaces are duck typing in an explicit form. Being explicit | |
about it may sound more work, but you also need that work in | |
Python if you want your solution to become maintainable, in the | |
form of tests. | |
I`ve been using Python for ~10 years (with years of PHP/Ruby | |
before) and written probably hundreds of thousands of lines of | |
code. One thing I don`t like while programming is doing | |
unnecessary work myself if the computer can do it. So I do a | |
lot of meta programming and build abstractions when it becomes | |
annoying to repeat myself. There had been a lot of moments | |
where I return to a highly dynamic part of code that I`ve | |
written months before to fix a bug and spend a lot of time | |
trying to figure out how everything is connected. Same code in | |
C# is both quicker to write (once you grok how reflection works | |
and how everything is tied together), and infinitely more | |
maintainable for less work. | |
Give C#/.NET a serious try. You may become surprised. I was. | |
imiric wrote 23 hours 22 min ago: | |
> How many bugs have you really hit in your Python code because | |
of lack of static types? | |
I don't work with Python much anymore (happily moved on to Go | |
:), but was a heavy user for ~15 years. And honestly, typing | |
issues were pretty common, if not the most common issue across | |
all codebases I've worked on. | |
The problem with dynamic typing is that, at the end of the day, | |
you're still working with and thinking about types. You have to | |
be implicitly aware of which type the function you're calling | |
expects, which not only increases your mental burden, but makes | |
refactoring much more unreliable. You have to rely on | |
documentation or _very_ thorough tests, which most codebases | |
don't have to the extent and quality they should. | |
With static typing, all of this goes away. Types become | |
explicit (remember "explicit is better than implicit"? | |
Yeah...), you get immediate feedback from your IDE when passing | |
the wrong type, and the code simply doesn't compile. | |
Best of all, you don't learn about a TypeError exception from a | |
Sentry alert after your users run into it. The amount of times | |
this happens in the wild is shockingly high. | |
> For ~20 years of doing Python, I honestly believe that it | |
could have helped me at most once or twice. | |
I honestly struggle to believe this, but good on you if true. | |
> Generally, doing sufficient level of testing has covered most | |
potential misuse of code, and you need to have tests anyway. | |
But that's the thing: in order to catch basic typing issues, | |
you would have to have dozens of tiny and mostly pointless | |
tests for each function. Yes you need tests, but most tests, | |
even at the unit level, shouldn't be concerned about types, but | |
about the functionality. And you won't catch typing issues at | |
the boundaries in integration, or higher level tests. Static | |
typing simply helps you avoid all of this nuisance, and | |
ultimately write more robust and maintainable code. | |
If I was ever to work on a Python codebase again, I wouldn't | |
consider it without a runtime type checker like Mypy, or | |
whatever state of the art tooling is these days. All the | |
supposed freedom of dynamic and duck typing just isn't worth | |
it. | |
rewsiffer wrote 13 hours 54 min ago: | |
You perfectly articulated how I feel about python and why I | |
am trying to move my teamâs projects to Go. | |
neonsunset wrote 10 hours 3 min ago: | |
Hopefully Go being such a bare bones language with unsound | |
features will tire you out soon enough to follow the | |
sibling comment in moving to C# instead :) | |
sirsinsalot wrote 1 day ago: | |
Honestly, after spending the last 10 years developing in Python, | |
I'm considering doing something similar. I've lived the problems. | |
They suck for engineering software with longevity. | |
wferrell wrote 1 day ago: | |
Who do you like who does this well? | |
I think Pydantic is great software and so I am inclined to see if | |
this too will be great software. | |
OutOfHere wrote 21 hours 50 min ago: | |
This is more a service than it is software. It can't independently | |
be used as a software without relying on their service. | |
emmanueloga_ wrote 1 day ago: | |
Looks like "Pydantic Logfire" is another entry on the category of | |
"APM"s? [1] Gotta echo the sentiment that Logfire doesn't seem to | |
be too closely related to Pydantic... Also, afaict it looks like | |
the frontend is not open source, unless I'm missing something [2]. | |
So, not a tool that one could self-host? | |
-- | |
1: [1] 2: | |
[1]: https://github.com/topics/apm | |
[2]: https://github.com/pydantic/logfire/ | |
threecheese wrote 1 day ago: | |
Iâve observed that Pydantic - which weâve used for years in | |
our API stack - has become very popular in LLM applications, for | |
its type-adjacent features. It serves as a foundational | |
technology for prompting libraries like [DSPy]( [1] ) which are | |
abstracting âup the stackâ of LLM apps. (some opinions there) | |
Operating AI apps reveals a big challenge, in that debugging | |
probabilistic code paths requires more than the usual | |
introspective abilities, and in an environment where function | |
calls can have very real monetary impact we have to be able to | |
see whatâs happening in the runtime. See LangChainâs hosted | |
solution (canât recall the name) that allows an operator to see | |
prompts and responses âon the wireâ. (It just occurred to me | |
that Langchain and Pydantic have a lot in common here, in | |
approach.) | |
Having a coupling between Pydantic - which is *just about* the | |
data layer itself - and an observability tool seems very | |
interesting to me, and having this come from the folks who built | |
it does not seem unreasonable. WRT open source and monetization, | |
I would be lying if I said I wasnât a little worried - given | |
the recent few months - but I am choosing to see this in a | |
positive light, given this teamâs âbelievability weightâ | |
(to overuse Dalio) and history of delivering solid and really | |
useful tooling. | |
[1]: https://github.com/stanfordnlp/dspy | |
clintonb wrote 1 day ago: | |
My last company used Splunk and SignalFx. They were fine, but I | |
wasn't necessarily in the weeds with configuration and usage. The | |
Observability Team made it easy to use. | |
My current company, a much small startup, primarily uses Datadog | |
and we are starting to better integrage Honeycomb. We mostly | |
abandoned Google Cloud Monitoring because the UI/UX are not that | |
great. Honeycomb is a paradigm, so took some time for us/me to | |
understand. It's growing on us. | |
Despite the ability to completely blow up our bill (which is now | |
better controlled), Datadog is a good product that lets us quickly | |
answer questions when things go wrong. It's not perfect, but it's | |
the best we have right now. The UI is intuitive, and facilitates | |
more discovery (esp. for metrics and their attributes). | |
cipherself wrote 1 day ago: | |
I am kinda confused by your comment, OP is about tracing as far | |
as I understood, but you're referencing Google Cloud Monitoring | |
(whereas the comparable thing would be Google Cloud Trace) and | |
then again | |
(esp. for metrics and their attributes). | |
but OP isn't about metrics at all rather traces. | |
clintonb wrote 23 hours 28 min ago: | |
Google Cloud Monitoring ( [1] ), perhaps not what you call it, | |
supports the big three signalsâlogs, traces, metrics. | |
[1]: https://console.cloud.google.com/monitoring | |
gazpacho wrote 1 day ago: | |
Hi, I'm one of the developers of Logfire. We do support | |
metrics! Our vision is a single pane of glass observability | |
where you can easily go from metrics <-> traces both via | |
correlation and by creating metrics/dashboards from traces. | |
We also support logging as an integrated concept into tracing | |
(you can emit events without a duration that are just like a | |
log but carry context of where they were emitted from relative | |
to a trace). | |
thenipper wrote 1 day ago: | |
Agreed. I use pydantic daily and I'm in the position to try this | |
out... but why? It really seems to be a weird divergence from their | |
core product. | |
Yenrabbit wrote 1 day ago: | |
They also have a UI framework (fastui). They have funding and devs | |
looking to be useful, I think it's fine that they get to try out | |
new things that work well with their core product. | |
<- back to front page |