I overheard a fascinating conversation on a plane once, about the difficulty in packaging salads/leafy vegetables. Finding the right plastic is incredibly hard, and you can’t just stick it into a paper bag. There would be so much spoilage that would far outweigh the cost and environmental impact of the throw away plastic, when you scale this to millions of units
As I understand it, plastics that come “post consumer” are too polluted to be used for anything but lowest grade of products: tyres, though probably not even that as people want “performance” from their tyres.
Where I live (UK) most plastic waste can’t be recycled yet, and they took our bins when I accidentally (optimistically) tried :(
Just like plastic use in medical setting, single use plastic straws have a similar sort of use, but they are obviously not needed everywhere.
Another source of major plastic waste is fishing, but people love their fish /shrug
As with everything, there’s some truth to that, but also C#’s json parsing libs are sub-par… and that’s really the least that a modern language should do well
Your information is very out of date. Microsoft long ago worked with the Newtonsoft.Json creator when introducing their native .NET replacement for Newtonsoft.Json. Performance in the new set of libraries is excellent as they rely heavily on the newer performance primitives like Utf8String, Span, etc.
No, it never does. There are better containers than dynamic, that do not have its performance drawbacks and have way better UX. The fact that this does not raise an eyebrow is a legitimate concern over the state of the codebase that uses it!
type Data struct {
Moon string `json:"m"`
Sun string `jsn:"s"`
}
func main() {
var d Data
err := json.Unmarshal([]byte(`{"m": "m1", "M": "m2", "Moon": "m3", "s": "s1"}`), &d)
fmt.Printf("err=%v, data=%+v\n", err, d)
}
The answer is "Moon:m2 Sun:"
In list form:
1. Specifying unmarshaling shapes isn't checked by the compiler at all, typoing `json:"s"` as `jsn:"s"` should be a compiler error in any sane statically typed language, but in go, struct tags are untyped strings, it does not help you.
2. There are hidden unchangeable unmarsheling rules, like the fact that Moon=m2 is because unmarshaling is case insensitive, even when you specify an exact key name.
3. It's very slow, due to reflection.
4. The API also is not really type safe, things like `json.Unmarshal([]byte, d)` return an error, but should instead not compile because that's a type-error (non-pointer passed to function that requires a pointer).
5. It's slow. It requires a lot of allocation.
6. `json.RawMessage` is subtle and difficult to use
7. It can't stream, so it's very easy to open yourself up to DoS, or to run across json documents `encoding/json` simply cannot handle
I can't think of any other supposedly statically typed language, other than C, where the most commonly used json library integrates so poorly with the language's type system.
Rust's `serde` is what a good well-typed json library looks like.
No matter how smart people are or how much money they get, they won’t create something good if the incentives for the individuals aren’t there. Everyone wants to prove that they are above the pack by instead implementing llms from scratch and boosting on Twitter, even though they just followed a guide for a week.
Im not sure how to fix it, but I think it starts with management that are strong willed, have pride, are aligned with the customers are able to make the developers proud in turn and dishing out low status tasks to everyone from time to time.
Thanks for the link. It looks like it might be a bit less painful?
It's still a pretty sharp disappointment to compare Go's json/encoding to Python's Pydantic or Rust's serde. One is all sharp edges, bad DX that permeates every use you make of them, and its only upside is that it provided as part of the stdlib. The other two are unobtrusive and just work.
Good in theory, but try that on a project with real customers and you’ll get a very simple “remove it and we’re done here” /shrug. Team’s processes and decision chain must have agreed to enforce this already, and that above is just a symptom
You’re completely right about entanglement: Id go further to say that simplicity in its purest form is almost always more useful than clever upfront design, but it’s funny because clever upfront design process can be tweaked to bias simplicity.
What I’m trying to say is that there are two ways of designing systems: Make them flexible to meet unknown future objectives by incurring tech debt, or build them so simple that they are easy to change when those unknowns come in.
You may say that there’s no “right way” to build systems, but some ways are certainly better, perhaps it’s possible to distil a way from that, but i agree that it can be paralysis inducing. can’t go wrong with building Simple working systems, imo.
the 10 -> 100 bit is absolutely right. a cross functional team has to learn how to work together well, and spend a non trivial amount of time discussing the problem and tempering solutions until something is achieved where each of them are some state of “happy”. This is I think the crux of many tech debt issues in companies
Consider a case where every non trivial refactor ends up in several rabbit holes, requiring lengthy meetings with lots of people to discuss, and many disagreements about direction. And in light of that the trivial refactors start to feel like you’re taking a bucketful out of a tsunami.
What ends up happening is it’s much more impactful for the team to just focus on shipping what they can, partly because they don’t have the tools/procedures/experience (anymore) for dealing with tech debt in this context
And that is exactly how the cruft I see has built over many years (well before I joined the team). It is not that devs before me were not smart; they just focused on doing the bare minimum without any attention to keeping the code easier to manage and reason with. An append only garden.
reply