#Godocs maui how to

Trying to learn is incredibly intimidating, because you look up how to do something simple and there's 17 unique answers with a million opinions on which is best, and which will lead you into a nightmare of unmaintainable code. With C++ you have to decide which parts of the language itself you're going to use. It also has some really unique meta aspects to it which are the appeal for me.įorget about needing to decide on a web server library because there isn't one in the standard library. This can be often seen from some smaller languages, but Go is in my opinion the only mainstream language using this approach and that's only possible due to Google's involvement. It would mean that you have a near-total control over the language's evolution, so you can include whatever you want without thinking about its long-term consequence (because you know a new addition would be necessary for your use case). Pick use cases and design the standard library only for those use cases. These languages tend to weigh more on third-party libraries with their pros and cons.ģ. This is the preferred approach for most newer languages, which can't readily determine at which direction the language would be heading. It took an eon to remove some dead batteries from the Python standard library. This has been Python's approach and is showing its limitation: you end up with lots of historical baggages you can't maintain. There are three approaches to standard libraries:ġ.

#Godocs maui code

Other languages without that base layer baked in don’t get that advantage.īack to Java/Spring: usually Catalina vs netty/Reactor Core are 2 totally different worlds and often dev teams don’t know which they picked or that they switched when they generated a new project and pulled their code in from Spring Boot 1.5 to 2.x. That said, if I’m using Go, that usually means building something with net/http and handing it to the library to use instead of the default.

This is especially the case with http libraries, since it’s usually building a client or server object/whatever correctly and not just a config tweak you can slap in at 2am.Īnd back to the original point, when there are 12 implementations that can mean having to relearn this activity for each one.

It’s all there, but buried in the godoc for you to have to know what you’re looking for. I just wish all of these libraries’ docs called that out up front vs projecting plug and play. No language or library can solve that for this stuff. You don’t want optimizing a config in isolation to break a larger system either.

You have to look at the use case and the SLOs of the app and it’s up and downstream dependencies. And yeah, good testing would be great too. But there does need to be a cultural change where using a client or server library assumes a tuning exercise. I complain because the defaults here are masochistic. Inevitably it gets reported as “latency” when a quick look at shows all the time is spent waiting on a connection, or a stack trace shows which library chucked the timeout.Īnd often devs just bump connection pools higher when they see a bottleneck and there’ll be 1000 idle connections wasting DB resources and not helping the problem (inefficient query, missing index, etc). Hikari has an awful default DB pooling config, and on and on. Nearly every client library in the Spring ecosystem has the worst of all possible defaults, and all internet code examples are “look at how easy X is” without anything around making it real.ĭevs chuck code out without HTTP connection pooling or pipelining requests, let alone reasonable timeouts. I mostly fix C or identify bugs, and write integrations in Go or Python.īut I spend probably 50% of my time dealing with production problems due to this in Java business applications.