I Quit My Job to Live on Donations to Zig
andrewkelley.me
andrewkelley.me
Never received even one donation/rating/comment/etc.? Be prepared to wait approximately forever.
Got a few, especially publicly-visible? Suddenly things trickle in faster.
Well-known project with 5000 stars? Here, have more stars. Here, have more donations. Success breeds success.
Meanwhile, wasn’t it shown that crucial infrastructure like SSL had between 1-2 unknown developers? How many other projects are there? How many developers can you name? How many different projects have you donated to? How many “not well known” apps have you balked at paying even $0.99 for?
It’s a problem. There needs to be better ways to vault critical “boring” projects into the well-known category. And, there has to be a way to keep positive feedback loops from ballooning ratings and income for projects simply because they sorted to the top and stayed there.
> Never received even one donation/rating/comment/etc.? Be prepared to wait approximately forever.
> Got a few, especially publicly-visible? Suddenly things trickle in faster.
That's not tech specific; there's a reason that places with tip jars preseed them with an initial stash of visible tips, and advertising (for consumer products, charity, and even B2B productos) features endorsers known to the target audience. Human social behavior is strongly based in imitation.
- Compared to setting up a coffee stand, it can take years to build really good technical solutions. (Longer, if you actually care and put in “invisible” effort like making it not crash or delete data regularly.) Yet, that app can still be lumped in with all the rest in the begging-for-scraps models of many monetization schemes.
- Unlike a coffee shop, where you can probably assume some amount of traffic and tips on a regular basis, software is often firmly set at ZERO. Or negative, if you consider any other cost. There isn’t a “software neighborhood” where people might walk by and see your project alongside only a couple others in the area.
- Unlike any “natural” recognition in the real world, tech projects are recognized in entirely unnatural ways. No one may know about an app for months; yet if/when knowledge finally spreads, the message is generally LOUD and everywhere. Say, being featured in the App Store: you go from “never heard of it” to “almost everyone in the world with an iPhone who checked top-10 lists this week”. That is far, far beyond the reach of normal ads, and also insane: it pretty much guarantees over-rewarding and under-rewarding developers across the board.
It's called social proof. It is a handy metric if you aren't that knowledgeable and can't judge quality directly for yourself. You look for evidence that other people judge it to be valuable.
Yes, it's manipulable. It isn't perfect by any stretch of the imagination. But in the absence of better ways to make such decisions, it beats having nothing to base it on.
That's not to be argumentative per se. Just elaborating on why it gets done that way.
With software donations there's also the initial hump to get over. When you're at a coffee shop and you've just paid $5, it's not much of a stretch to toss another dollar into the jar. You already have your wallet out, and you've already spent money.
When you come across a donation link for some free software you've started using, you don't have any of that.
I even balk at $0.99 for a mobile app, even though I know that a dollar is inconsequential to me (and I believe I can even "return" it within 24 hours if I don't like it!), even though paying for it is only a single confirmation tap beyond what installing a free alternative would be.
It's astounding how much psychology and emotion governs what we do in this space. Very little has to do with logic or rational evaluation.
Does something like this already exist?
The first phenomenon leads to many natural things being interpreted as Gaussian when that's just an artifact of measurement (as an example, see the BMI scale). The second is very similar to the way you can reliably hear people use the term "exponential" to describe a large absolute increase, even if that increase isn't even quadratic.
It's still based on the same social feedback loops and marketing that causes the problem you describe, but it makes it easier for unknown projects to get seen and evaluated by a knowledgable, generally objective audience
You have just written a simple and alternative specification for "government" :)
As others have said in this thread, it is not specific to technology.
Other words to describe it: Hipsters, teenager-(like)-wannabe-with-the-"in"-crowd-mentality (I see that a lot in adults), winner-take-all, network effects, (going back) "no one ever got fired for buying IBM" (or insert other popular bigco name here), ... , all the way back to the fundamental point - human nature.
Not very many people are discerning and try to make independent judgments/decisions. Much easier to follow the crowd or herd.
There are public funds out there, in France and in EU, at least. Getting them require a bit of networking (you usually need to be back up by a partner either a lab, a company or an institution) a lot of paperwork but it allows to get financed in a way that charity or donations will have a hard time achieving.
agree with getting more stars, but donation? not yet :-/ :( https://github.com/learnbyexample/Command-line-text-processi...
It's easy to forget to self-promote when you're busy doing actual work though.
That was my problem as well because I created a popular open source project and I was focused on driving all the attention towards the project and none to myself. I created a Twitter account for the project, the GitHub repo was under an organization instead of my own personal profile, the blog I made was also named after the project.
The lesson I learned is that people don't care that much about projects and concepts, they need to see faces and names. Even among highly technical developer communities... So imagine how bad it must be in mainstream communities.
> Both King and Rowling’s foray into undercover writing reveals a harsh truth about success and social status — winners keep winning. This idea is formally known as cumulative advantage, or the Matthew effect, and explains how those who start with an advantage relative to others can retain that advantage over long periods of time. This effect has also been shown to describe how music gets popular, but applies to any domain that can result in fame or social status. I discovered this concept by reading Michael Mauboussin’s The Success Equation where he writes:
>> The Matthew effect explains how two people can start in nearly the same place and end up worlds apart. In these kinds of systems, initial conditions matter. And as time goes on, they matter more and more.
Two years ago, I was writing a modest Lisp interpreter in C. The evaluator was more or less working, but I was totally stuck on parsing user input (in other words, I had the E in REPL, but not the R). After spending an entire night banging my head against the parsing logic without making any progress, I began to despair that it would never work and I would have to throw the whole thing in the trash.
Well, that morning I met Andy. Groggy and frustrated, I told him about my problem. He said "Why don't you try tokenizing the input before parsing it?" This was a revelation to me. Yes, it turns out that reading a string character by character and trying to recursively convert it into a Lisp object all at once isn't the best way to do it. Who knew (aside from anyone who had ever learned anything about parsing)?
The resulting parser code: https://github.com/nickdrozd/lispinc/blob/master/parse.c
Anyway, I don't know anything about Zig, but Andy sure helped me out of that jam.
Methinks you don't understand how Patreon works.
If people are willing to give him more than that without him offering additional incentives, there is a downside to providing other levels in that there is administrative overhead on the back end to make sure people get the incentives they paid for and distinguish those who gave $5 without wanting other incentives from those who gave $5 because they did want those incentives.
Etc
If the point is to free up his time to focus on Zig, more pledge levels potentially distracts from that without necessarily increasing his take, given that the developer community is already willing to give him more than a dollar just to support letting him work on Zig, without anymore incentive to them than that.
When you set your default, you are implicitly saying "this is what I think my software is worth to you". That's an anchoring point. Most people who decide to donate less than the default will probably feel slightly bad for doing so. Some of those people who would just stick with the default at $1 will also stick with the default at $5. Some people will generally always give more than the default, and that "more" might be even more if the default is $5 than if it's $1.
It's probably incredibly rare that someone would click through, see a $5 default (including the possibility to donate less), and say "wow, this person is full of themselves thinking $5 is reasonable; I'm not going to donate at all in protest". So there's little to no downside risk in raising your default by a non-crazy amount. Obviously some defaults are absurd; $1000 would be crazy and probably off-putting. But $1 is certainly a low-ball.
> Most people who decide to donate less than the default will probably feel slightly bad for doing so.
If the default amount is too much for me, then my choices are to donate less and feel slightly bad, or not donate at all. It will be pretty tempting to keep my money, rather than give some up and feel guilty anyway. Paradoxically I might even feel less guilty for not donating, because that's a passive act and I can tell myself I'm only postponing the decision, rather than definitively making an ungenerous choice.
That said, because it's normal for people to pay more than you ask, it's not a bad idea to have a higher level or two if you have lofty goals for it.
I don't think it's really impulse spending though. Most of the people on my Patreon are people I talked to for a year or more on social media before they signed up.
Note, the total number of donations I've received is ~20.
I don't think he is?
If current trends continue... :P
[1] https://www.usenix.org/legacy/events/usenix07/tech/full_pape...
One thing I'm curious about: the current ~$400/month from Patreon (minus fees) isn't close to enough to cover a similarly comfortable standard of living in New York, and I imagine that this would affect your "runway", if you will. Are you able to live and work off of savings, or will you be relocating for a lower cost of living?
Apologies if this comes across as prying into your financial details. I'm more just curious about the process. Again, congrats!
> $3,000 per month Fully sustain full-time work on Zig.
As much as I love NYC, it may be practical to relocate somewhere with a lower cost of living. Alee & I will reevaluate when the lease is up. She's in grad school, so who knows where that will take her? I'll probably just live where she needs to for her career.
I would recommend you put in a couple higher levels on the Patreon and think about what people would want from you. For instance, I ran a popular blog and asked my readers what they would pay monthly for. Turns out one of the biggest requests was just a private webinar (I hate that word, so you could call it something else, like "knowledge brain dump") once a week. I ran them for 60 or 90 minutes and took questions at the end. In fact, I may do this again in the future, since I continue to get requests for it long after the fact.
People here have expressed how articulate you are when describing the language. Setting up a group at say $19/mo or even $49/mo where you deep dive into software dev, practical applications of Zig, and/or programming languages in general "live" once a week might be something people are willing to pay for, and would get you "out of the red" more quickly.
[0] jsoftware.com
[1] http://versor.mat.ucsb.edu/
[2] https://github.com/enkimute/ganja.js
[3] https://extemporelang.github.io/It's rare to see a technical presentation done in a way where the concepts are so clearly understandable. Makes me want to take a peek into Zig and see what it's like in there and consider supporting the author just because. Hope it works out well enough for him to live his dream :).
I would be really interested in using it if I had more Clang support in bare metal systems. I think the consensus among embedded developers is that we would all really, really like a modern language with modern type-safety and type-checking, but we also still want to do crazy crap with memory at times.
It doesn't matter so much that there's a way to do something, but it matters a great deal how you are expected to do it. Keeping it simple matters, and Zig looks pretty simple compared to other compiled systems languages that I've seen, so that's wonderful.
http://tiehuis.github.io/iterative-replacement-of-c-with-zig
That's a bit hard to tell, isn't it? When I checked out the docs after last week's Zig thread, the entire section on memory allocation was a big fat TODO.
It seems that the design goals of this language are exactly what I'm after. Going to have to give it a try later.
@cImport({@cInclude("header.h")})
The language is also evolving rapidly, this may have changed, but if it did, it probably changed for the better.
Trying to do anything non-trivial with ownership/lifetimes/borrowing always ends up in a tangle, fighting with the compiler.
Everything in the stdlib seems to have a giant api with pages and pages of functions. Example: https://doc.rust-lang.org/std/string/struct.String.html Scrolling down through those methods is overwhelming.
The overhead imposed by the goal of maximising safety is big, and not that important to me (as I'm not writing Very Important Crypto code or whatever, I don't find it hard to write good enough code for my purposes in C).
Rust is for people with C-level problems who don't like C's ergonomics. Zig appears to be for people with C-level problems who do like C's ergonomics.
Some of that is from essential complexity that we've been lying to ourselves about (memory safety, mutability, safe parallelism) and rust makes explicit.
C has a simplicity for it, for better _and_ worse.
I do not know enough of Zig to compare the complexity, and Nim is indeed not simple. To borrow from the zen of Python, it is complex but not complicated; and most of its complexity is of a kind you can almost entirely ignore until you need it, and when you need it, you're in trouble if your programming language doesn't provide it. e.g. operational transforms, macros, compile time execution. pragmas.
That may be so, but Zig is still in a very early stage of development. A language may look simple and fresh in the beginning, but the real test comes when 1.0 is right around the corner. Nim is at this stage now, I am one of the Nim core devs and I will even admit that it is by no means simple, there are features that I would like to see removed to reduce the complexities, but how do you do that when a vocal percentage of your user base loves the feature?
Do keep this in mind when trying to compare a language like Zig (which is just starting out) to a language like Nim (which has been around for a while). Perhaps Zig will do a better job than Nim in this regard, but only time can tell.
Regarding that, does Nim allow one to turn off GC, mess with pointers, and twiddle bits like in C? As in, is there an optional set of C's features in there that one can use? Or improve with macros, type-safe wrappers, and so on?
Every company/project uses a subset of C++ for a variety of reasons. The problem is, all those subsets are different, and as a result, if you want to rely on the ecosystem, you eventually have to deal with the entire language. Maybe you avoid exceptions/pointers/new&delete/template-meta-programming/the-coprocessor, but the libraries you need don't.
This is visible already in Nim, where the GC is optional, but most libraries (and most of the standard library) does depend on it.
It works well without GC, but you lose out on most of the existing libraries and many parts of the ecosystem.
> Regarding that, does Nim allow one to turn off GC, mess with pointers, and twiddle bits like in C?
It lets you twiddle bits without having to turn off the GC - it has GC-tracked pointers ("ref"s) and non-GC ones ("ptr"s). the GC is per-thread, with time limits but it can also be turned off.
> Or improve with macros, type-safe wrappers, and so on?
Nim macros are not quite at the Lisp level, but they are extremely powerful.
There are various features for type safety that DON'T require wrappers, e.g. you could define "meters" and "yards" as two distinct 64-bit double types, which means you can't add them or assign one to a variable of the other kind, even though they are still essentially a C-style typedef. This is a much more elegant solution than the C++/Python/SmallTalk/Java/C# crowd, where you have to define a class with a lot of methods, which is still clunky, and hope that the compiler will be able to optimize it back down to a plain old double.
I'm not fully familiar with Lisp macros so I'm curious, what is Nim missing that Lisp has in terms of metaprogramming?
Lisp has reader macros that can alter lexical analysis and parsing; correct me if I am wrong, but I think that’s not possible in Nim. E.g. things like JSX are trivial to implement in Lisp.
Also, lisp macros let you e.g. write new control structures with multiple “body” parts - iirc, in nim only the last untyped macro arg can be a code body (you can put a block in parantheses, but that’s not as elegant)
I’m sure there’s other stuff that fexprs and other [a-z]exprs can do that nim can’t, but i’Ve never seen them in use (or used them myself)
Also, personally I think Nim’s model is more practical; lisp’s power essentially requires lispy or REBOLy syntax to be usable. Nim is pascalythonesque, and though complex is not complicated; much like Python, and unlike C++, you can make use of the ecosystem without being afraid of obscure details biting you - but it has all the capabilities when you need them.
Yep, and in fact I would say that Nim is a perfect "better C" language. You get things like modules, a better type system and metaprogramming. Of course you'll have to forgo a lot of the stdlib, but if you're already using C that won't be a tough pill to swallow.
I'm not sure what advantages that the location brings when working on a programming language (networking?), but I can suggest moving to South Africa where cost of living is low and quality of life is high. Yeah there's "crime" -- but it's not too bad as long as you're a little smart about the way you conduct yourself.
Cape Town is an obvious first choice and is really cosmopolitan with a good dev community, but I can suggest Durban as a good runner up; it was recently voted "Most Livable City in South Africa" [0]
For New York level "hole-in-a-wall" rentals, you can live like a king in South Africa :) If you're willing to share a spot you can really get a palace for yourself, and enjoy some of the best beaches in the world (in Durban).
[0] https://www.iol.co.za/mercury/news/durban-is-most-liveable-c...
From personal experience, I can tell you that Taiwan is a fantastic place as well. Lots of engineers, absurdly low cost of living for the civic amenities (which blow away even the best that San Francisco or New York can offer), and gorgeous nature if you're into that. If you manage to learn Mandarin it'll greatly expand your access to the programming community there, but if not there's plenty of English speakers and just expats.
Very few Taiwanese people would give up the freedoms they have in Taiwan for a move to China, just because they might get paid more. There probably should be a (unbiased) study done, but it does not match my experience.
Taiwan does get shitloads of Chinese people coming in to work, though.
Taiwanese salaries are substantially lower, yes, especially for Taiwanese. Furthermore, they have an unhealthy, ineffective work culture reminiscent of Japan. These issues need to be worked out and it is a long term plan of mine to tackle this head on and very publicly when I start a business there.
For expats, there's no need to participate in this work culture if you don't work at a majority Taiwanese company, and if you do work at such a company, you can simply annoy your coworkers by leaving at 5, you most likely won't be fired over it but will need to withstand peer pressure. Visibly Asian-heritage expats will experience this even more.
The best case scenario is the one we're discussing in the main thread - expat working internationally, but remote.
Then again, some people love the adventure of moving to another country, and I encourage them to pursue that if that's what they want.
That's all moot though because the Zig guy said elsewhere he'll probably be following his girlfriend who's about to graduate.
There are excellent inexpensive places to live in Washington that offer a lot more than Yakima does. Spokane, for example, is still very inexpensive compared to Seattle and offers a lot more in terms of both city life and accessible outdoor activities. It's too bad the dev scene there is pretty limited (Itron and Seven2 are really the only companies that I can think of off the top of my ahead employing devs, and the salaries are nothing to write home about). Of course, if you're doing remote work anyway, this isn't really an issue.
There are a lot of great mid-size cities out there--a hundred of them to choose from--and they're all cheap.
There's this prevailing attitude by city dwellers that living outside of NY, SF, Seattle, or <insert your tech hub here> is death, but that is an attitude borne from a lack of experience about life.
Life is sometimes great in midsize cities, and in many ways they offer more for less.
For example, I lived a spartan but comfortable life in Rochester, NY for well under $20k/year. That was renting an expensive-for-the-area apt in a nice neighborhood. When I had roommates my rent was <$250/m. You can buy a house in Rochester for under $20k.
I lived in Budapest and Chiang Mai, Thailand before and the advantage of these cities is that you can pretty much walk anywhere or pay little for private/public transportation. Food is everywhere and you're not stuck in the middle of nowhere.
The cost of owning a car is part of the living expense... so it's not just rent.
And FYI, I had a nice studio in Chiang Mai for less than $250 a month. It was professionally cleaned every week and the place was just steps away from cafes and grocery stores. No cars required.
If he is confident that he can manage to quit his job while making less than 1k a month for now, then even $10/hr part time job of less than 25 hours a week would be a great boost
> Uruguay is ranked first in Latin America in democracy, peace, low perception of corruption, e-government, and is first in South America when it comes to press freedom, size of the middle class and prosperity... Nearly 95% of Uruguay's electricity comes from renewable energy, mostly hydroelectric facilities and wind parks...
https://news.nationalgeographic.com/2018/02/cape-town-runnin...
> 100% of donations I receive go towards paying rent, buying food, and generally attempting to live a modest, but healthy life.
He doesn't expect to get rich from this.
Kinda awesome actually he's doing what his passion is.
Programming languages are more of an open-source thing. You can't make much money from them.
But GP forgot that the $1M was in 1997, before Google and Facebook and friends made non-founder engineers rich.
So does TypeScript.
While it's admirable, I can't really say it's risky. Risky is quitting in a field where people stay laid off for like a year.
At $1000/month, a broken or stolen laptop or bicycle is ~two months. In the US (which he is) Any medical issue, or a baby, is somewhere between three months and bankruptcy.
However good Zig looks, there's also Nim, ATS, Rust, and a dozen more. Seems like a good time for programming languages -- which means a dangerous time to quit your day job for one.
His problem was, instead, "I took a year off work to produce a VCS and then saw the throne taken by git. My work has been forgotten and nobody uses it--not even me."
There are riches besides money.
For example vue.js has 100k github stars and the creator is still only getting 15k a month on patreon and a good chunk of that comes from only a small handful of $2000 tier company sponsors: https://graphtreon.com/creator/evanyou. So that's probably a rough upperbound on how much the donation model can support.
Aside, have you seen the language Jonathan Blow's working on (jai)? Curious how you'd compare the two, goals or implementation-wise. (Given he hasn't released anything yet, no worries if this is unanswerable :))
> Zig is taking cues from Jai's stance on allocators, since that language is being developed by a high-performance game designer for the usecase of high-performance games."
https://github.com/ziglang/zig/wiki/Why-Zig-When-There-is-Al...
Not trying to be dismissive, genuinely curious what your thinking is.
For ruby it was rails. Python profited from data science. Etc.
Edit: I see there already questions about Rust in this thread. There's an audience question on Rust in the talk [1] and the creator states that Rust is Zig's biggest competitor.
[0] https://www.youtube.com/watch?v=Z4oYSByyRak
[1] https://www.youtube.com/watch?v=Z4oYSByyRak&feature=youtu.be...
That embedded world needs a simple, performant, low-level language that isn't C. If Zig focuses on providing that for the robotics domain, I could see it becoming popular.
I know of another example: the guy who draws and writes the web- (and now print too) comic "Kill Six Billion Demons". I believe he's currently living off of direct fan support (through Patreon too, as it happens) although he has published a physical book collecting the first arc of the story. (I guess that is also fan support..?)
Check
- https://www.wuxiaworld.com/ (note that this is a very large community)
- Earnings of Tang Jia San Shao and I Eat Tomatoes
- Article on New York Times: https://www.nytimes.com/2016/11/01/world/asia/china-online-literature-zhang-wei.htmlThere’s a lot of artists living off of Patreon. I got close near the end of my last graphic novel, but the Kickstarter was a big learning experience that took a while, the new one takes longer to draw and rent always goes up, not down.
(And this is why there was so much screaming when Patreon tried to change their fee structure late last year.)
(To be clear, there's a lot of cases when this precision isn't so useful, but the contention here is how fine grained they can be.)
Is one better than the other? I doubt that question has an objective, one-size-fits-all answer. I'm happy to see experimentation in this domain! My point really is just that Zig is different from Rust in how it handles errors, even if there are some superficial similarities.
My understanding is that something like `fn f() -> %T` returns a T or an `error`, and the latter can be literally any error value that exists anywhere in the program. It isn't restricted to the actual possible errors that might occur inside f, and thus has the same failings of Rust that you point out (don't know which subset of errors might be returned), except the unknown set of possible errors is likely to be larger.
(And, you can still get all the niceties of Rust's error handling infrastructure like the ? operator if you manually define an error type that is restricted to the exact set of possible errors: there's not a privileged type for how to represent errors.)
My reading of the release notes:
https://ziglang.org/download/0.2.0/release-notes.html
...is that error sets can be inferred (at both call-site and in the function declaration); and that inferred error-sets on return types are exact, in the sense that an inferred set will only include the actually-possible errors encountered in the call-tree.
To be fair, I don't know whether a function can declare that it may fail with a given, explicitly-declared error-set, where that error-set includes errors that the function actually cannot produce. (E.g., I say I can throw a network-error code, but I perform no network calls.) If this is permissible (i.e, the compiler doesn't complain), then that undercuts my argument a bit. :) On the other hand (again from the release notes), most functions are encouraged to simply declare their return type as !T, where the ! represents "the inferred error-set for the function," and this seems to support my claim.
For example, the following code
fn errorOrAdd(a: u8, b: u8) !u8 {
if (a == 2) return error.FirstArgumentIsTwo;
if (b == 2) return error.SecondArgumentIsTwo;
return a + b;
}
pub fn main() void {
if (errorOrAdd(0, 0)) |ok| {
} else |err| switch (err) {
// will force a compile-error to see what errors we haven't handled
}
}
/tmp/t.zig:13:18: error: error.SecondArgumentIsTwo not handled in switch
} else |err| switch (err) {
^
/tmp/t.zig:13:18: error: error.FirstArgumentIsTwo not handled in switch
} else |err| switch (err) {
^
fn anyError() error!u8 {}
/tmp/t.zig:13:18: error: else prong required when switching on type 'error'
} else |err| switch (err) {
^
Do remember that Rust allows passing information in the Err variant of a Result while Zig's error codes are just that, codes with no accompanying state.
[1] https://github.com/tiehuis/zig-bn/blob/3d374cffb2536bce80453...
[2] https://github.com/tiehuis/zig-deflate/blob/bb10ee1baacae83d...
Yep, as a sibling points out, I was working with a long-ago version of Zig's error handling.
https://ziglang.org/documentation/master/#Errors
edit: when I say "full union of all possible errors", I just want to be clear that this means "all the possible errors that could occur at this call point, and no others." It's not just a bag of "all possible errors that the language/library declares to exist."
edit #2: On second thought, I guess it might be possible for a Rust tool to build these types, although I think it would require changes to the language implementation. Variadic type constructors aren't necessarily needed. Another approach would be that every (type-specialized) function returns a Result<T, ES> type, where ES is some type that implements an "ErrorSet" kind, and where ES is very possibly unique to the function (that is, no other function might return Result<ES>). For example function A() might fail due only to two cases (say, out-of-memory or disk-full, but never network-error), and function B() might fail only on disk-full. Then the ErrorSet type for A has two constructors (OOM and DiskFull), where the ErrorSet type for B has only one (DiskFull). You could then use Rust's (excellent) pattern matching to exhaustively handle all cases (i.e., the specific constructors of that ErrorSet type) at the call site.
So the tricks would be:
1. Instrument the language to tag each specialized function with its error-set; this is computed recursively by examining the failure modes in the function body, as well as the error-sets of every function it might itself call, and taking the union of those sets. (Side note: I believe that, in Zig, a type-specialized function maps to a single error-set -- i.e., the error-set doesn't depend on runtime arguments in any way. But I could be wrong about this.)
2. Generate a potentially new ErrorSet-ish type for each function, or more spefically, for each error-set that is generated using the process in step #1. (I suppose you would have to give the type a name, but maybe it could be an anonymous internal type if there is language support for that.)
3. Then you could naturally "match" on the function's return value, and know that you've covered (exactly) the possible failure modes.
But this is just armchair-quarterbacking on my part. I don't know the internals of the Zig error system, nor what changes Rust would actually need.
There is also the "failure" crate which has patterns for the kind of thing you mentioned:
https://boats.gitlab.io/failure/error-errorkind.html https://boats.gitlab.io/failure/custom-fail.html
https://ziglang.org/documentation/master/#Errors
https://ziglang.org/download/0.2.0/release-notes.html (see "Error Sets")
enum MyErrorSet {
NotFound(ErrorKind),
SomethingElse(ErrorKind),
}
enum MyErrorSet {
NotFound,
SomethingElse
}I don't think the distinction is super important in application work (for example). But for systems code I can see the benefit of having the compiler tell you, with certainty, why a given function can fail (and why it can't). E.g., a good device driver should handle all its failure modes with care, rather than with a shotgun approach.
I haven't tried Rust, but I've seen enough of it to know I'd hate it. Where Zig has a clear advantage is that it is vastly smaller and simpler and does not enforce a memory management paradigm on you. There isn't even a default allocator.
Definitely a language to keep an eye out on.
"So and so helped me fix a hard problem"
"Isn't that just [problem category] 101?"
The difference between people who get regular languages, pretty much everyone who codes, and the people who get context free grammars is more than $100k a year.
What makes it so special compared to other tasks of similar difficulty?
If you can't do it you might use computers but you're not programming.
Tuning DE solvers might take as much skill, or more, than getting context free string parsed, but it's not a skill that is used outside of numerical computing. DBAs aren't called programmers for a reason, but they are no less valuable for it.
The same applies for every niche skill that takes years to develop.
so you just defeated your own argument, instead of hyper-focusing on writing parser why not just say "years of experience" if that is what really matters?
no wonder you got shit on.
Parsing, databases, concurrency, floating point numbers, optimization, common data structures, regular expressions, networking, operating systems, recursion, complexity theory, etc., are all things you should understand to be considered a competent programmer.
It's pretty funny that next to no one here will even understand what I'm saying.
I have written programs with thousands of lines that do nothing with strings at all, as have a great many other people. Parsing is simply not the universal requirement you claim it to be, and declaring that only real programmers can do it just makes you look arrogant and ignorant.
Not all programs need to take external input to be useful, and many or most of those that do can just use an existing library to read it, with no need to write a new parser. Writing parsers is simply not the universal programming requirement you people are trying to claim it to be.
Yes, all "data" is right there in the source code for the programs I'm talking about. (I do also write a lot of code that deals with external data, for which I write parsers or use existing ones.)
For example, I did some consulting for a company where I made a mathematical model of their physical product and simulated the static and dynamic behaviour of it in various situations. The model and situations are completely defined by a few parameters in the source code. There's no need for external input and definitely no need for any kind of parsing. Thousands of lines of code.
As a simpler example, the other day I helped a high school student write a program to do basic numerical integration. No external input needed.
I have university students who do an entire course on numerical methods without external input (partly because we're stuck in Matlab where IO and string processing are horrible). The few times they need to process a small amount of data it's just pasted into the code.
For part of my PhD I wrote programs over a thousand lines long to derive mathematical functions. No external input, and nothing that can even be called data.
Generative programs in general, for art, sound, video, etc. often have no external input. I have written many of these.
For another part of my PhD I wrote thousands of lines of code to reconstruct surfaces from point clouds. For real purposes it uses external data, but for testing and development it can simulate its own (so that the true answer is known).
You are simply incorrect.
Compound data types, and procedure argument lists, describe the grammar of the data that your programs operate on. That this data is in the source code and the parsing from text to intermediate representation is done by the compiler only offloads the first steps of the parsing. Obviously if you deal with simple data types like vectors and matrices there will not be a lot of grammar there. If you think about typing your program and more intricately structured data into a REPL, this becomes apparent (just because your compiler accepts something as valid input, may not give many guarantees about how your program will behave - this is the crux of type theory).
I am not sure how you can claim generative programming as a counter-example to needing to learn parsing theory. The entire field started out from formal language theory.
I agree that the programs are doing work to assign meaning to the numbers and data structures etc. in the code and put them to use in context, though I wouldn't have called that part of the parsing myself. I think the grammar of my "input" data structures is usually pretty simple, as you suggest, and that more complicated source structures are likely to be kind of self-organised, e.g. involving dictionaries with meaningful keys or calls to class constructors. Complex data structures can then be built from the simpler source ones if needed.
So how are the functions fed into the integrator? The second you want your program to integrate more than the one function you hard coded it with you need a parser to understand what the function is and then translate it into the internal language representation. Something that is very far from trivial.
Besides, even if you want to take in a general function in this case, there's almost certainly no need to write a bespoke parser by hand. In fact, this student was able to handle that requirement just fine (he had this in there first, and we made the program more useful by taking it out):
exec('f = lambda x: ' + input('Enter function: f(x) = '))
This will be my last reply in this thread.
If you can't parse reverse polish notation to infix notation you're going to be writing monstrosities like the mediawiki markup parser.
It doesn't help that 80%+ of developers these days are script kiddies.
Even if it comes a fad getting more people to learn something as basic as that would make the code I have to read so much better.
Gatekeeping: when someone takes it upon themselves to decide who does or does not have access or rights to a community or identity.
Regular Expressions are used to solve problems, but almost no one makes a career of programs written exclusively in Regular Expressions.
I didn't magically get a $100k raise after I wrote my first parser, either. Companies care about how you can make money for them, not that you aced "CS405: Compilers and Interpreters" in college. And that latter bit isn't at all correlated with the former... unless you're applying to work at a company that makes compilers.
Take off from OkCupid, start every zig?
His "apology" video is worth watching [2] ... his office is literally dripping with gold; the Eggs on his desk are $4,000 per piece. Given recent price of pound of rice, one of those eggs will get you 12,000 pounds (!!!) of raw rice. It takes approx 0.8 pound of rice to feed one person per day. 12,000 / 0.8 gives you 15,000 days worth of rice for one person, or 41 years. One Egg! [2]
Anyways the point of my story is that if in first world country like USA you can find people gullible enough to buy stories like this one and keep on living in literally liquid luxury for 40 years (like that minister does), then it doesn't surprised me someone quit job, begs people for donation and actually makes a solid living.
[1] https://www.cnn.com/2018/05/30/us/jesse-duplantis-plane-falc...
[2] http://www.jdm.org/xw-partnerupdate.aspx?source=TWITTER
PS. Oh and while you on your donations spree, you don't have to be transparent; here Jesse Jets beacon is off; not only he doesn't fly with peasants like you and me, he doesn't want you to know where he is "burning the Jet for Lord Jesus": https://flightaware.com/live/flight/N770JD