Nim 1.0
301–308 of 308 posts
Re: Nim 1.0
#302Earlier quoted context omitted.
Note that deciphering type tag info in a Lisp value can be called "parsing". Cases occur: for some values we have to chase a pointer into a heap to get more type info. A Lisp function call does "parsing". (foo 1 2 3) has to figure out dynamically whether a (lambda (&rest args)) is being called or (lambda (a b c)) or (lambda (a b &optional c (d 42)) or whatever. The #S(employee id 1 salary 95000) object also isn't an…
> Note that deciphering type tag info in a Lisp value can be called "parsing". No. You are still operating on the level of s-expressions, a data format. The type-tag of LET is SYMBOL. Here we have some Lisp code in the form of an s-expression: (let ((let 'let)) ((lambda (let) (let ((let let)) let)) let)) All above LET have the same type tag, but in terms of syntax they have a different purpose in the form above: we h…
Re: Nim 1.0
#303Earlier quoted context omitted.
> Basically you only use GC if you declare something using a GC type. So similar to C# (2000)? A useful feature to be sure, but not a major innovation. > The standard library uses seqs in various places so if you fully turn the GC off using the compiler switch --gc:none you'll get warnings for things you use that will leak. There's no GC 'runtime' stuff that you need though. Running with the GC off (and accepting the…
So, the full gist is: Nim uses automatic reference counting with cycle detection. If you want to, you can disable the cycle detection, perhaps only temporarily. The compiler flag for turning GC off doesn't actually turn off all GC, IIRC. It still does automatic reference counting, and it can still do cycle detection, it's just that you need to initiate it manually. The language does have pointers, and will let you do…
Re: Nim 1.0
#304Earlier quoted context omitted.
Doesn't .NET (and C# with it) have stop-the-world GC, very similar to Java? Or do you mean something else?
CLR was designed for multiple languages execution models, including C++. In what concerns C#, besides GC, you get access to off heap unamaged allocations, low level byte manipulations, value types, inlined vector allocations, stack allocation, struct aligments, spans. All GCs have eventually to stop the world, but they aren't all made alike, and it is up to developers to actually take use of the language features for…
Not at all. Nim is an example.
Re: Nim 1.0
#305Earlier quoted context omitted.
I'm curious why did your progress with Rust stalled and at which point? I’m starting to learn it and so far I haven’t noticed any productivity blockers.
I heartily wish that you continue learning Rust, another significant contribution to open source languages. What has been already commented, things such as borrow/checker are humps you work through and it will work out for you eventually. The other challenges are some of your enterprise 3rd party integrations with the outside world, some of which may again demand your time if they are still in beta, etc. Also, the or…
Re: Nim 1.0
#306Earlier quoted context omitted.
I wouldn't say separating the GC at the type level is a major innovation, but as you say it's useful. I don't think Nim really sells itself on a groundbreaking GC implementation either. However it does give you a fast GC with enough flexibility should you need it. For example, the Boehm GC is not thread-local. GC types are copied over channels with threads, or you can use the usual synchronisation primitives and pass…
That is the gist of the anti-GC crowd doesn't get. Languages like Nim allow for having the productivity of relying on GC's help, with language features for performance freaks available, when they really need to make use of them. Java not offering a Modula-3 like feature set has tainted a whole generation to think that GC == Java GC. EDIT: grammar errors
We can extend this pattern:
> has tainted a whole generation to think that OOP == Java OOP
Re: Nim 1.0
#307Earlier quoted context omitted.
They work only as long as they don't use any garbage collected types (the compiler will warn you of this when you turn the GC off). Unfortunately this means most libraries are out, and you have to do your own thing. Turning the GC off is more meant as a way to use Nim on micro-controllers and for things like kernels and such. In this case many libraries that aren't written for this use-case doesn't really make sense…
> so I'm not sure how big of an issue this is in reality. I have audio programming in mind. Not that you can't do audio programming in GC-enabled languages, it's just that's it's quite frown upon in this circle (for good reasons). I'm sure there are workarounds though.
A related question is whether you can disable GC on a thread by thread basis.
Re: Nim 1.0
#308Shameless plug, but by a nice coincidence, Manning has a discount on all printed books today. Among them is my book, Nim in Action, available for $25. If you're interested in Nim it's a great way to learn :) It was published in 2017 but we've ensured Nim is compatible with it (all book examples are in Nim's test suite), so apart from some minor deprecation warnings all examples should continue to work. Grab a copy he…