Someone needs to figure out medium range charging and sell a unit to every home, coffee shop, airport, airplane, etc. Let us never be powerless or tethered or docked again!
You’re limiting your view of feature flags to a subset of their potential. Also, authorization schemes like attribute based access control (ABAC) can use any arbitrarily dynamic values from the current context. The two concepts overlap immensely.
I’m curious about why people dislike this question. This is a specialized library; it should be testing everything including crazy edge cases that most of us haven’t even considered. Also, someone stated that there have been several URL-related security vulnerabilities in curl.
I disagree. I think this isn’t a good text. Some examples:
- The text claims to be geared towards beginners, but doesn’t explain what a register is.
- “you are left with an Executable and Linkable Format file (Elf) which is the Linux equivalent of a .exe file” indicates the text is geared towards people who know about execution formats, possibly even Windows users who are.
- “.section .text is where our code will live”, for beginners, needs to explain what sections are and needs a remark that it’s weird that the section named “text” doesn’t contain text, but code. At a very minimum, it should say the reader will have to accept that that magic incantation is needed for now, and that more info will follow.
- the text doesn’t say why you need both ”global _start” and ”_start:”. It does introduce labels, but that’s many lines after using the first one.
Hi author here,
I appreciate the feedback. My goal for this blog is to produce one written article every week, and this one was down to the wire. My view of a beginner is someone that has learned the basics of Python. I struggled a lot with how detailed I wanted the exposition to be and did end up cutting somethings like you mentioned. This won't be the last article I write so I'll keep this in mind in the future
It’s not only about being able to operate disconnected for long periods it’s also about handling network partitions and being able to achieve consensus without a single source node.
I was a Rails, Sinatra, Ruby dev for years and I’ve been work with Go for years too. I’m struggling to understand your perspective because I’m no less happy coding in Go.
I've only done a bit of Go. I liked some of the ideas that were present, but ultimately (and I believe explicitly) Go has computer-sciencey-correctness goals (hence all the kerfluffle over generics) that, now and again, trip things up.
Sometimes that's really nice - we had a handful of tiny utilities written in Go, like a format converter for use in a datastream - other times it gets in the way. I don't think I'd want to code up something large in Go, although it's not something I've had the opportunity to try.
AFAICT, Go believes in preventing you from making certain mistakes. And usually, within it's context and paradigm, it's correct to do so. The problems arise when your problem domain doesn't line up well with that context and/or paradigm, which sometimes just comes down to the time you can spend on the issue.
Another example: IMHO, all the weird issues Go was having working out how to do package management stems from some (admittedly very cool) ideas about Correct And Proper Package Management. I can't remember the last time I had an issue with gem management / bundler (except for the perennially awkward PG gem issue).
It's a 85% vs 95% thing, and IMO that straight-up comes from having other priorities. There's a lot of overlap between "developer happiness" and "computational correctness", but it's not exact, and that comes up in few, but enough, places.
Maybe another good example is Ruby array arithmetic. It makes no bloody sense from a math/CS perspective, but goddamn it is handy in applications. So if your language is aiming for computational correctness, you're not going to get that tiny bit of joy.
> Go has computer-sciencey-correctness goals (hence all the kerfluffle over generics)
I really don't understand this. The debate over generics had nothing to do with "computer sciencey correctness" goals, they had to do with ergonomics. Of course, from Ruby, the idea of typing your code is completely foreign, but imagine if a function only allowed one type of parameter, and if you wanted another you had to define it again with a different name.
Basically like allowing flexible parameters makes function definitions more flexible, a lot like all the metaprogramming business in Ruby
> the idea of typing your code is completely foreign
I don't understand this?
> I really don't understand [Go has computer-sciencey-correctness goals]
My impression (way back when, TBH when Go was first announced and discussed) was that the language creators had some Very Strong Ideas about how to do various things 'much more correctly', and/or to avoid specific pain-points they'd had in other languages, and that those things informed a lot of the decisions about Golang; in particular the module system, generics, and error handling.
I'm calling that "computer-sciencey-correctness goals", perhaps incorrectly, as I also got the impression their goals and methods were heavily informed by CS research into computer languages.
You will end up sacrificing other things in favor of your principles. Other languages sacrifice developer happiness for theirs. Ruby sacrifices other things in favor of developer happiness.
That's it. Everything else is [my] speculation about why people chose their particular principles.
Citation note: I've always heard that "Developer Happiness" is a thing from Matz (Ruby's language creator), but the only place I'm finding it explicitly stated is in the Rails doctrine.
