71–80 of 118 posts
Earlier quoted context omitted.
What's the situation with the TODOs mentioned in the presentation? Primarily, the missing standard library support cleanup ("Currently no real-world project can be built with HCR")?
those issues will hopefully be addressed in the coming months - when I get the time
Earlier quoted context omitted.
Not sure what that would buy over Object Pascal and the plethora of libraries develop since Turbo Pascal/Apple Pascal days.
Admittedly not much on the technical side beyond new languages constructs etc, but the main benefit would be ending for good the wrong argument "Pascal is old therefore Lazarus sucks". Like 20 years ago I've written network code in Delphi that would send and receive binary data between different endianess and word size machines, so I had to align them and manage data down to bitfields in the Pascal equivalent of C un…
And their beloved C is reaching 50 years old.
Earlier quoted context omitted.
One can use compilers for interactive development, too. That's not a feature of being 'interpreted'.
Interpreters tend to have repls, which tends to influence how development happens. I'm not stating an absolute law though. I think you may be misinterpreting my original question. It was asked out of ignorance, it wasn't a challenge. I was hypothesising some kind of self modifying code, or realtime adaptive optimising or something. I was attempting to show you my current level of knowledge so you could ELI7 instead o…
Earlier quoted context omitted.
> For HNers, it's an opportunity to still make a huge difference by contributing to a relatively young language It would be better for someone to work on an alternate, Python-like input syntax (focusing on readability and good intuition, and perhaps more attractive to novice programmers) for some established language, like Rust. Working on a "young" language, you just miss the chance of contributing to an ecosystem t…
There are things about Nim, like the thread local garbage collected heaps, that you can't really replicate in Rust. Sometimes you want garbage collected language because it makes your life easier. Sometimes you don't because you're a library or realtime or you want to optimize the hell out of your code.
It's just a bit silly to couple one's choice of language/ecosystem/etc. to a single memory-management strategy, and the Python/Nim-like choice of obligate GC as an extension to obligate reference counting also seems a bit puzzling. That's basically taking every sort of automated memory management under the sun and compounding their disadvantages - I'd think one can do better than that, in fact even Go or Ocaml do better than that!
I only skimmed the video, but I couldn't see him describing it doing type reloading. Perhaps that is what he is planning on implementing. It is very hard to implement (especially if you can't control the compiler) but very useful for general code reloading. Of course everything is relative, and even if I think it is "very hard" it might be a weekend project for someone else. Generally though, code reloading is one of…
> The holy grail of code reloading is to upgrade the code of a HTTP server while it is running and without disturbing any requests being processed. Very few languages except for Erlang are able to do that correctly. Some languages claim to support that, but when you experiment with them you discover "quirks" making it impossible in practice. You can kind of do it with node.js, but man do things get ugly fast when you…
Earlier quoted context omitted.
One can use compilers for interactive development, too. That's not a feature of being 'interpreted'.
Interpreters tend to have repls, which tends to influence how development happens. I'm not stating an absolute law though. I think you may be misinterpreting my original question. It was asked out of ignorance, it wasn't a challenge. I was hypothesising some kind of self modifying code, or realtime adaptive optimising or something. I was attempting to show you my current level of knowledge so you could ELI7 instead o…
In fact, "compiled" programs on many platforms require an interpreter to set them up by dynamic code loading (including modifications if needed).
In ELF header, it's called "program interpreter", which gives a path to a program that understands this particular file and can assembly a running image in memory
I see that at this point in time Smalltalk and Lisp machines have become completely memory-holed (oh wait, Smalltalk & Lisp are interactive, thus "interpreted", thus obviously not compiled! I'll show myself out)
Earlier quoted context omitted.
Are there any Nim benchmarks vs. Go, Crystal, Python, Rust, etc.?
You can find them although they tend to be out of date and/or piecemeal. I think they're still useful. For example: https://github.com/drujensen/fib https://gist.github.com/sdwfrost/7c660322c6c33961297a826df4c... https://github.com/kostya/benchmarks My general sense is that Nim is most competitive as an alternative to Python and/or things like Julia, in that it's as expressive and easy to understand as those, but has…
- Type system: Strong and static typings.
- Support Generics (Unlike Go)
- Support Modules (Unlink C++)
- Multiple and optional GC.
- Metaprogramming support.
- Executed binary.
What excites me most is the efficiency as C.
I hope it'll get mature more this year. At least for the Javascript backend, so that i could write Nim for frontend (with bindings for popular JS frameworks like React, Vue,..) , too.