j-james

5 ms·

1.
by j-james 2y ago
I think this is all true. Though with regard to your earlier example, it should be noted that Nim, too, has an extraordinarily powerful compile-time programming system: but it takes the form of typed macros and generics (as opposed to Zig&#
2.
by j-james 2y ago
https://github.com/nim-lang/RFCs/issues/548
3.
by j-james 2y ago
It will not emit warnings saying it did that. The static analysis is not very transparent. (If you can get the right incantation of flags working to do so and it works, let me know! The last time I did that it was quite bugged.) Writing an
4.
by j-james 3y ago
That relies upon the benevolence of corporations to much more of an extent than I am comfortable with. 20 years of social media has convinced me that that's a bad idea. And, I think, it removes much of the benefits of federation: if th
5.
by j-james 3y ago
I cannot see how BlueSky's moderation system can ever work. Decoupling moderation and hosting means there's no onus to do the moderation that they describe: which makes me think it will be BlueSky Inc., and only other corporatio
6.
by j-james 3y ago
Ah, I was referring to disruptek. I don't know why you two hated each other's guts, mostly due to being less active back then indeed. For what it's worth I didn't think the banning was undeserved: but the interactions yo
7.
by j-james 3y ago
Some context: dom96 here was the BDFL-in-2nd-command of Nim for quite some time. There is personal beef between dom96 and some of the primary nimskull contributors, which mostly involved a lot of name-calling, personal insults, and critique
8.
by j-james 3y ago
Well, they're not classes, they're interfaces, and so you can implement multiple interfaces for multiple types, and so you have to implement them separately from the type declaration. There's not too much of a way around that
9.
by j-james 3y ago
I'd be a little interested to hear what you like about C++'s syntax! As a non-C++ programmer, I mostly think of the language as a pile of mistakes that kinda had to happen for other languages to learn from them, very much includin
10.
by j-james 3y ago
Nim is particularly C-like. The automatic memory management is optional and exposes destructors, it exposes pointers and is quite usable on embedded systems (see: Futhark, Ratel), there are a wide variety of design decisions made to ease in
11.
by j-james 3y ago
The downsides of this approach are unfortunately that it makes wrapping certain low-level libraries an absolute pain in the ass (especially anything to do with keyboards). But overall it's a non-issue, tooling recognizes both styles
12.
by j-james 3y ago
Heh, neat to see you've got the Perceus paper there too. That is in fact the other part (the "ARC") of Nim's memory management for those unaware - with the only differences being Nim frees memory at the end of scope, rat
13.
by j-james 3y ago
Hmm, a strong type system? Is there any overlap between the Wit IDL and other similar projects like crABI?
14.
by j-james 3y ago
Really, I'm quite hopeful for crabi: https://github.com/rust-lang/rust/pull/105586 An ABI for languages with a proper type system seems fantastic. Swift, Rust, Nim, D all share very similar type systems
15.
by j-james 3y ago
> You can also not really have productive and well-fitting errors-as-values in a language that emphasizes UFCS Eh, https://github.com/arnetheduck/nim-results and associated syntax from https://github.com&
16.
by j-james 3y ago
> It's not so much a competitor (in performance or clarity) to Odin or Zig as it is a competitor to Go or something That seems accurate. Dealing with raw pointers as one does in Odin or Zig is very much de-emphasized in favour of de
17.
by j-james 3y ago
Ones that have not been mentioned so far: - npeg lets you write PEGs inline in almost normal notation: https://github.com/zevv/npeg - owlkettle is a declarative macro-oriented library for GTK: https://github
18.
by j-james 3y ago
I know, I know! I do very much like the "type wrapper" approach more than the "object variant" approach. Perhaps in the future we'll simply have both and have no reason to debate ;-)
19.
by j-james 3y ago
I have a shortlist of pain points: - Tooling is not great. The language server has a tendency to silently crash on occasion, and it's no rust-analyzer to begin with. A tooling rewrite has been delayed behind proper incremental compilat
20.
by j-james 3y ago
Yes, an experiment was run a while back, incorporating community-maintained code in a "fusion" repo shipped with the compiler by default. It didn't work very well. Discoverability and maintainability of stdlib-like things is
21.
by j-james 3y ago
Right, but I'm curious about the calling-Zig-from-C interop, not the other way around.
22.
by j-james 3y ago
Yeah, I read through that: unless I'm missing something I think what I'm curious about is "calling C code from Zig and vice versa" in the to-be-written section. Nim also has support for `ctypes` and compiles to C as its
23.
by j-james 3y ago
Can you use Zig painlessly alongside C? Does `zig cc` or an equivalent provide for writing Zig libraries that then can be called by a main C function?
24.
by j-james 3y ago
Well, maybe not writing. Occasionally low-level C libraries - especially those that deal with keyboard input - decide to provide identifiers differing only in case... There's a WIP RFC for providing a way to deal with identifiers that
25.
by j-james 3y ago
Do note that this was written before Nim's new runtime, ARC/ORC, became stable! The author has been working on a companion guide to the new runtime that goes over how it manages to be efficient with reference counting, but it&#x27
26.
by j-james 3y ago
While I love Nim, another reason for Rust's success (aside from its type system, general good language design, and zero-cost memory safety) is that the tooling is ridiculously good, probably the best of any language I've used, s
27.
by j-james 4y ago
Not unless the function signatures overlap entirely. That's rare enough that I don't think I've ever? encountered it in several years of writing Nim.
28.
by j-james 4y ago
It's alright when it doesn't crash. But it frequently crashes. Tooling is definitely a weakness of Nim (although it's improving). More specifically: right now auto completion is excellent, implicit type annotations are excell
29.
by j-james 4y ago
Reference and pointer types (annotated with `ref` and `ptr` respectively) are nillable. The compiler can provide null safety guarantees by annotating types with `not nil`: https://nim-lang.github.io/Nim/manual_experimen
30.
by j-james 4y ago
Did we read the same book? I find Mastering Nim a pretty excellent reference. (And you have to install the pixels library :-P) The online documentation, certainly, could be better. I sometimes find standard library documentation lacking in

More ›