When searching for info on chronos I came across @zensins (long) essay here (https://forum.nim-lang.org/t/13322#80975) and found my impressions confirmed.
Now, to be fair, I'm not deep into Nim since quite some time.
Here is what I see:
Nim has become a confusing maze, in particular wrt to multi-threading an async. BS like "if using X lib, do not use Y and do use commandline switch Z". That may be acceptable for hardcore Nim fans but is apalling to the average developer. Also, while documentation is quite OK for Nim itself, I've seen plenty modules with poor to utterly crappy/meager or next to no documentation.
With chronos, for example, the documentation is very meager. So I looked at the source code - to find many procs having not even a fu**ing single descriptive line. To make it worse the few examples provided are quite minimalistic. Just one example: how to set a header for a client request?
All in all, I always (mis?-)took Nim to be a language with which simple things were simple and, if one was inclined to do so, one could dive deeper and do more complex things.
Why the hell should I use a language that isn't mainstream yet (read: far, far less code and docu to be found than for say, C or Pascal or ...) and at the end of the day is NOT simpler to work in than C?
I'm more and more under the impression that Nim is not on its way towards a serious widely used language (kindly note that when I say "Nim" I actually mean the whole 'eco-system' incl. tools and libraries).
Recently @Araq told me that 'Nimony' likely is what I want and 'Nim 3.x'. Sorry Araq, no, it highly likely (as in "almost certainly") will not. Because I've lost my trust in your ability to guide your baby well through the woods. Too many experiments, too many cooks in the kitchen. Don't get me wrong, I know that programming languages don't fall from trees, they require repeated attempts and experiments. But NOT in a way that suggests actual usability and lures people into actually using it instead of clearly putting a "Carefu! Experimental!!" label on top.
Well noted, I'm not cynical sarcastic or ill-willed in the least while writing this! I'm sad. I'm sad because a project I once had high hopes for and trust in increasingly looks derailed and out of control.
Angry I'm only at those who provide next to no docu and basically seem to follow the line "FU! I'm doing this only for myself and/or for fun".
I'm back to Ada and C and will only occasionally "play" with Nim. Who knows, maybe in a couple of years it will be actually usable and well documented. Hope one can ...
P.S. and à propos C: The moment the straw broke was when I build a library in C and it was less painful than my bloody cumbersome and unnerving Nim attempt and the overall dev experience was better.
Yes, @Araq,
but with Nim the chance - sadly - is much, much higher to encounter libx with docu between non-existing and poor, including - again, sadly - libs that seem to be important and often mentioned.
Kindly note that I expressly said that Nim itself is decently (albeit far from perfectly) documented, so that "arrow" wasn't targetting you, or only insofar as you seem to welcome pretty much everything as "contribution". Being at that, tools and libs are important for a language to get wide acceptance.
Why such entitlement?
If you can make a better async lib or improve chronos, go ahead. If some libraries you need are missing in nim, wrap a C library or use C if wrapping is more effort than the benefit of using nim in the project. Why the drama?
This guy usually entitled and not interested in "being the change you want to see". See the last thread he created https://forum.nim-lang.org/t/13407#81396
I knew it was him by the tone not the username.
I have a completely different experience with Nim 🤷 Somehow I'm seeing well maintained and documented libs with open-minded and friendly people maintaining and developing them.
If you don't like something, just don't use it. Or, if you care enough, so the actual improvement you want to see.
We have a saying in Russian: a pig will always find dirt. It's a bit rude but the tone set in this thread is rude so I guess it fits.
I don’t understand in what context the “cathedral” model could even work, certainly not in open source. How could someone boss around strangers they don’t know, who each have their own personal agendas, goals, and work schedules? Even in a business context, this approach seems better suited to organizations that continually acquire talent and discard people when they are no longer useful, companies I would rather not work for.
I am not trying to be adversarial. I simply think what you are describing is unrealistic. In my personal experience, people who believe everyone else is stupid and that they are superior do not really succeed. They are often deceptive, and no one likes being deceived.
I don't know, I think I might be misinterprating your points, anyway.
Regarding documentation, I agree that there could be more, but with AI that is a weak argument. Most chatbots can generate plenty of examples for you and even run them. My issue is with people who refuse to use AI, as well as those on the other end of the spectrum who rely only on AI. And, of course, managers who think that AI means we can get more done without any quality control tend to ruin it for everyone.
lax management. That's the only, although sadly important, issue I see linked to @Araq the creator.
I don't get this... do you feel like you want to be ordered on what to do and how to behave? Or do you feel others should be coerced to do and behave like you want?
I fully respect that quite a few people here love to play with Nim and to use it, I can even understand it. Of course I also understand that docu is not at the top of developers priorities. But still, one does share or one does not, but if one does one also should create at least a reasonable minimum of docu for potential users.
My projects have a license that have a THIS WORK COMES WITH NO WARRANTY or equivalent. I guess people misunderstand that no warranty implies no obligations from the part of the dev also. By using the project you agree that you absolve the dev from any obligation, such as "you must provide up to date docs". The upstream dev is not a company, there is no inherent relationship between the two of you; a dev uploads a project, and then you pick it up and use it. The dev doesn't provide you specifically with the project.
I'll close with some final remarks: I freely admit that I'm quite "old-school" and strongly prefer the cathedral model over the bazar model - and I feel strongly confirmed my attitude by quite some responses here (and what I saw and experienced with NIM).
Yes so you do want to (order | be ordered) around. Remember that the bazaar archetype allows you to manage your stall as a cathedral, but doesn't let you enforce your ideas on others.
Sorry, no, that's not the route I'll take, among other reasons, because @Araq making a no matter how good language will not significantly change things or uptake. lib devs who don't create docu will not somehow magically change their attitude, to provide just one (albeit important) example. But frankly, also because I already invested enough time (and efforts).
Upon re-reading your original post, I'm starting to become confused. Are you asking for stronger stdlib cohesion in the world of async and multithreading, or are you asking for Araq to police what people make and make official recommendations? I'm not really sure what the point of your thread is when recontextualized around getting mad at library maintainers.
---
For what it's worth, I found myself pretty frustrated with Chronos' lack of documentation too, but I don't understand how that can be treated as a broad criticism of Nim. I've gone through my own trials and tribulations with Nim async, but I never once considered issues with 3rd party documentation to be a core Nim issue; I've dealt with the same in other ecosystems.
In Rust land, I've been using an async runtime called monoio. It's created by Chinese developers and it has very sparse documentation, and it's a 50/50 chance of being in Mandarin rather than English. It's hard to criticize Rust for this, and I'd say comparing my experience with monoio to my experience with Chronos is pretty fair, considering they're both "alternative" async runtimes.
---
Finally, it would be useful for you to give an example on how you would like to see things.
" Most chatbots can generate plenty of examples for you and even run them. My issue is with people who refuse to use AI, as well as those on the other end of the spectrum who rely only on AI. And, of course, managers who think that AI means we can get more done without any quality control tend to ruin it for everyone. "
1.If chatbots are so great and helpful, it should be easy to build great documentation so others do not have to start from zero (or burn tokens on the same question, wasting electricity and time). In reality, when using one you'll find the generated docs look great on the surface but contain many warts.
Also, when vibe coding, existing documentation, not code (unless you have infinite tokens and context), keeps AI from hallucinating.
I am speaking only for myself. I do not keep track of everything that happens, but I doubt that someone was “made fun of” for using AI. I do not claim that AI always gets things right, but it has definitely improved and does provide some value. It is not what it is advertised to be, but it does offer some.
Personally, I dislike vibe-coding; it is essentially throwaway code.
To express a small disappointment: my library, https://github.com/planetis-m/naylib, has complete documentation on how to update it, yet I have not seen any contributions that follow those guides.
It sometimes feels as though the complainers do not want to do any actual work themselves, but instead expect others to do it for them, which I strongly dislike.
OK, it just do happens I'll be improving the docs for Status's libraries for the next few months.
Since Chronos seems to have a bad rap with regard to documentation, I've decided to start with it.
To my surprise, I found that the docs are actually pretty good. And even if they don't cover some things (and no docs ever will cover everything) the tests are there to help.
For example, I've taken the original question posted by @moerm:
how to set a header for a client request?
First, I've asked DeepWiki and the answer was pretty much there instantly: https://deepwiki.com/search/how-do-i-set-headers-in-an-htt_30eda350-fdf6-4412-ad26-718cee1edeee?mode=fast
Then, I went to the tests and analyzed testhttpclient.nim. There I found a working example of a request with headers.
After that, I've just opened httpclient.nim and looked what else I can do with HttpClientRequestRef mentioned in the tests.
So, finally, I've come up with a working code sample based on the example from the docs:
import chronos/apps/http/httpclient
proc retrievePage*(uri: string): Future[string] {.async.} =
let httpSession = HttpSessionRef.new()
try:
let
headers = {"User-Agent": "MyApp/1.0"}
httpRequest = HttpClientRequestRef.new(httpSession, uri, headers = headers)
resp = await httpRequest.get().fetch()
bytesToString(resp.data)
finally:
await noCancel(httpSession.closeWait())
echo waitFor retrievePage(
"https://raw.githubusercontent.com/status-im/nim-chronos/master/README.md"
)This approach is not perfect but it does the job done and that's what counts at the end of the day.
I think it would be great to add this case to examples though to save future users time.
@moerm, @termer, could you please share some other cases where you faced the lack of documentation in Chronos? I'd appreciate some concrete examples like the one with headers.
Thanks!
"I doubt that someone was “made fun of” for using AI."
I think this person is no longer participating in this forum. Here's one example: https://forum.nim-lang.org/t/10101#67274
Above thread is also interesting because it shows how the same issues pop-up over and over with people offering strong opinions.
"Most chatbots can generate plenty of examples for you and even run them"
Chatbots can be a minefield, as you pointed out in your followup. Each one has it's strengths and weaknesses, Claude is more hands off but has a mind of it's own, likes to change things to fit it's logic. ChatGPT is not as comprehensive, outputting incomplete code buy 'thinks' better and 'listens' to instructions, does not change code as eagerly as Claude. Gemini can be brilliant one time and stubbornly hallucinate other times, getting web references are it's strength, but can also be it's weakness on obscure topics.
Anyway, outsourcing community support to AI is a bad form in a long term. Not just because soon we will see inline ads, perhaps even suggestions to 'why not use Mojo' if Mojo pays them enough. LOL. Pushing people to resort to AI is not building community, networking, and cooperation.
Sorry for resurrecting a dead thread.
I've been working on a detailed HTTP client tutorial for Chronos for the past couple of weeks and it's now ready to merge: https://github.com/status-im/nim-chronos/pull/617
@moerm @termer if you could review it and leave some comments in the PR that would be very valuable. Would such a tutorial have helped you avoid confusion if it was there for you when you approached Chrono? What's still missing? What should be covered that is not?
Thanks!
"I doubt that someone was “made fun of” for using AI."
I think this person is no longer participating in this forum. Here's one example: https://forum.nim-lang.org/t/10101#67274
Above thread is also interesting because it shows how the same issues pop-up over and over with people offering strong opinions.
"Most chatbots can generate plenty of examples for you and even run them"
Chatbots can be a minefield, as you pointed out in your followup. Each one has it's strengths and weaknesses, Claude is more hands off but has a mind of it's own, likes to change things to fit it's logic. ChatGPT is not as comprehensive, outputting incomplete code buy 'thinks' better and 'listens' to instructions, does not change code as eagerly as Claude. Gemini can be brilliant one time and stubbornly hallucinate other times, getting web references are it's strength, but can also be it's weakness on obscure topics.
Anyway, outsourcing community support to AI is a bad form in a long term. Not just because soon we will see inline ads, perhaps even suggestions to 'why not use Mojo' if Mojo pays them enough. LOL. Pushing people to resort to AI is not building community, networking, and cooperation.