I didn’t think it was hard, but it definitely is different! I recall a moment of “oh duh, “ when I set up a function with the type signature of all the errors it could have. Then I was told about the parent of all errors, anyerror, so my return could be !anyerror without me going through all the functions I called and assembling all the possible errors.
Little things it takes a hot second to get into it. I’ll be thrilled to use it again for advent of code this year.
“I don’t think it was hard” feels like exactly the subjectivity that the post opens with.
I feel like objective measures aren’t that interesting. We have very few facts to work with. Even a language’s mission statement or design goal is a claim. If we went with objective measures, I guess we’d all be using the fastest language that uses the least amount of memory or something. But that’s not what people want. I think people want subjective takes up front because they might invest 2-4 years learning whatever-lang. Zig is fast, we could probably prove it. That’s good to know, but not the “worth it” part.
Maybe if we had a subjective recommendation engine at scale, we could smooth out the opinions? Recommendation engines, metacritic, amazon reviews, glassdoor and others are all smoothed out opinions, collected. I’m not disagreeing, I just wonder if we are missing some tool or site? What else is it? Random stories through search engine hits?
You make good points.
I think easy vs hard is largely a factor of your background and breadth of programming experience. Some things will be easy and obvious to me if they embed ideas from languages I’ve used before. Others will be extremely hard if they use ideas from languages I’ve never touched. As I gain more experience and broaden the types of languages I have used, the subset of new languages that are hard to learn begins to shrink.
Quantifying that for a broad audience is the thing that feels like the hard part. Maybe what we need is a matching system that takes into account the languages you know. :-)
That would be neat. We sort of already know how to quantify experience (flawed maybe) and background. Maybe it would double as a job site or some other purpose. I guess then the hard part is the recommendations or tagging system (bleh, ontologies).
If I could visualize or organize my boundaries in terms of a heat map or mind map, I’d love to see it. Maybe I don’t know how to do it but I don’t find value in these tools. The best one I’ve found is a result of tests on Triplebyte (things may have changed, no endorsement). I didn’t directly make the map (and it was simplified) but when I saw the results, I thought it was pretty fair. It would be great to have this be an output of exercism or something: “you learned the concept of closures from Erlang” but as evidence, not self-assessment.
Note that you can also just omit the error type and it will be inferred precisely. This is usually better than using anyerror, and works most of the time (not e.g. for recursive functions, or writing a function pointer type).
I don’t recall if this worked on 0.8 but that was the version I used at the time. Oh, I think I was using a callback or something, where I needed to write the type elsewhere?
A recent comment from HN about C and C++:
“Coding in C is like camping. It’s fun for a while, but eventually you really miss things like flushing toilets and grocery stores. You can fancy-up your sleeping bag + tent with a huge motorhome/caravan by using C++. Its like you have this house on wheels, but if you just want to take a sleeping bag + tent with you on a trip - you can. Take whatever you need.”
I’ve always been curious where Zig fits in this camping analogy.
I think the camping analogy only works from the perspective of the modern mass-market software engineer. Zig isn’t really for them, and neither is C, but if they have to end up lightly using one of them at some point, they’ll probably like Zig better than they like C.
Still, I can try: Coding in C is like camping 1800s style: you make a fire by rubbing two sticks together, you carry a giant heavy framed backpack with a bedroll and a tent, boiling water and using chlorine tablets, hunting wild game for food, and if anything goes wrong you basically die in the wilderness as g*d intended. Coding in Zig is like modern camping where you get a blank check to pick up all the latest cool gear at REI: your basics are all lightweight and waterproof, you can purify water with a simple filter bottle, you get a Jetboil propane stove, tasty freeze-dried food options to drop in the pot, and if there’s a medical emergency you’re gonna break out your satphone and get a helicopter rescue. It’s still camping though, and you still have to shit in the woods and sleep without air conditioning :)
My experience programming in Zig is mixed hard and easy too.
Writing application logic is relatively easy, as the primitives in the language are a short easy learning curve.
However, I also found learning how to correctly setup a build.zig file though, isn’t intuitive. Even after doing it a few times there’s no way I could do it from memory, and I end up copy-pasting a lot of the time there.
Comptime had a smaller learning curve for me than Rust’s macro does.
However, using comptime to write multiple types that satisfy an interface are non-trivial, and so this is a case where I frequently forget how to do it, and end up copy-pasting from a past project.
And lastly memory. The article talks about the difficulty in choosing an allocator, but I found that to be the easy bit. The APIs of most types make it pretty easy to know when you need an allocator, and you just pass it in.
However, remembering who “owns” some heap memory and is responsible for deallocating it, is just as hard as it is in C.