91–100 of 106 posts
Earlier quoted context omitted.
No, even small files. You must have issues with your setup. Are you sure your compiler is not built in debug mode?
How would I check that? I installed it through homebrew via https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/... which doesn't seem to mention debug mode anywhere?
Earlier quoted context omitted.
Do you have a Discord or anything? I'm interested in helping, I love Django and I would love to help any way I can.
There's no Discord yet, just GitHub issues. Here's an issue to track this request: https://github.com/jfilby/nexus/issues/14 I'll email you regarding what/how to help.
Earlier quoted context omitted.
> An e-book is going to heavily (and negatively) impact the sales figures for the print book. Well, if the price is the same, that hardly matters? Or are you implying unpaid/illicit downloads will be worse with a legal digital version as opposed to an illicitly scanned copy? After buying an e-reader I can't defend buying print books from an environmental standpoint - it may be a sunk cost/resources fallacy - but with…
You can read a print book without wasting electricity every time you open it and the toxic materials used to produce a e-reader. Reading print is still a much more enjoyable experience (except in the tub -- a waterproof Kindle is still great and lightweight for that!), especially with the slow speed of e-ink screens. I can't defend ebooks compared to the reading, sharing, and the later selling at a used book store my…
This is generally true for ebooks as well, as I only have electric heating. Both probably require more electricity for lighting anyway.
> and the toxic materials used to produce a e-reader.
I assume an ebook reader uses more resources to produce than a book, but 1) I already have a reader, and 2) I have for example e-books I inherited from my dad - that's approximately a thousand books. Even just moving them into my apartment would require non-trivial resources.
> Reading print is still a much more enjoyable experience
I don't really agree. Especially not for technical books.
> I can't defend ebooks compared to the reading, sharing, and the later selling at a used book store my cast-off print books.
Agree that the Kindle/Amazon drm/marketplace is pretty bad. Not all books have draconic drm, though - and in such cases it's much easier to share a book with a friend that has moved over seas for example.
> I've even gotten O'Reilly books from a decade ago at used book stores that are great to read and look great on my shelf,
Sure, but in the event this is a problem - it's also a drm problem, not a problem inherent to ebooks.
As for books about "programing language x version y, with best practices as of year z" - I fully expect them to be mostly outdated after 5 to 10 years - maybe replaced by a new version.
> and I love finding some old novel by some forgotten author instead of whatever the latest Amazon bestseller is.
I've never discovered books from the AZ bestseller lists, but I've bought a few classics.
There are always going to be books that are hard to get - like the excellent:
Howard McCord book: "The Man Who Walked to The Moon" which was self-published if I'm not mistaken. I found it in a thrift store in Berlin. As it happens, it's now available for the Kindle:
https://www.amazon.com/Man-Who-Walked-Moon-Novella/dp/092970...
> And I don't have to worry about the Orwellian deletion of my books from my e-reader
Again - a market/drm problem (and a real one for sure).
I really do hope we will see more diversity in ebook sales, sharing, re-sale and lending.
Earlier quoted context omitted.
How would I check that? I installed it through homebrew via https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/... which doesn't seem to mention debug mode anywhere?
Run `nim -v`, if it's not in debug mode you should see "active boot switches: -d:release".
$ nim -v
Nim Compiler Version 1.6.6 [MacOSX: arm64]
Compiled at 2022-05-05
Copyright (c) 2006-2021 by Andreas Rumpf
active boot switches: -d:release -d:nimUseLinenoiseEarlier quoted context omitted.
Elixir is indeed the most loved web framework according to the latest StackOverflow survey. I'll be looking to Elixir for ideas for Nexus (web framework).
I meant Phoenix, which is built on Elixir.
Beam really is a marvel.
copy one write and immutable data structures mean you ca have garbage collection reserved for the termination of a thread whihc would be a nontrivial task in languages that encourage mutability cough go cough
Beam processes are a blessing
its also extremely tuned for creating threads that are super lightweight. consequently, scaling strategies that are optimal in elixir would be a TERRIBLE idea in other languages. You could make a dynamic cluster of node/go instances that communicate over rabbitmq and have a supervisor process that can keep track of their state and resurrection in case of a crash. Its going to be error prone and take weeks of fiddling to get right. beam gives you that out of the box. Its not perfect but its more than good enough for your first 10000 customers.
This benefit extends all the way up to Phoenix. because threads are trivial to create and the overhead is low, its a viable strategy to generate a stateful process for every user as they interact with the system, this is what allows liveview to be so powerful.
Each channel connection gets its own thread as well. A single machine can handle thousands of threads this way with full isolation. one thread crashing won't affect your other connections. nodejs cannot provide that. if a web-socket connection crashes a node instance, it ends the connection for every customer currently connected to that node.
Every attempt I've seen outside beam to recreate this revolve around OS level process which have a higher overhead and then they still need to create a mesasge passing protcol and supervision system. since OS threads are epensive, it wouldn't be a. good idea to try creating something like liveview as you'll overload your machine.
So you might say, "ok, I'll craete a multicluster virtual machine optimized for immutable data structures with a built in intra process messaging protocol for communication as well as a higher level super vision process. at that point, I'll say "congratulations, you just reinvented the beam, lets see if we can port other languages to it!"
anyways, if you're looking for something a little smaller for now, I highly recommend really understanding ecto and how it has you interact with databases. its easily the best database library I've worked with. precisely because it isn't a orm. It maps sql rows to elixir records which has much less of an impedance mismatch. its achieves almost zero friction between your database and your api.
Earlier quoted context omitted.
Even Rust?
Nim gives you like 85% of the performance of Rust without having to worry about a borrow checker. It also solves concurrency problems via its use of Channels, like Go. So it's just hard to justify using Rust, for me. Unless you're writing a DB or something where a GC is a no go. But Nim's memory management seems pretty good, and many things are stack allocated.
Earlier quoted context omitted.
It's much faster than C++, Rust, Go and many others.
I'm assuming this must be for huge projects? I just compiled my toy project (detecting anomalous parity in integers) in nim 1.6.6 (4.23s), go 1.17.7 (2.43s to create both aarch64 and x86_64 binaries), zig 0.8.0-dev.1140 (2.04s to create aarch64 and x86_64 binaries) and C via clang 13.1.6 (0.14s). nim's compilation is 175% of Go, 207% of zig, and 3021% of clang.
Earlier quoted context omitted.
An e-book is going to heavily (and negatively) impact the sales figures for the print book. So I wouldn't hold out for that. Looking at the price of the book, he wants to make money from it, so no e-book is probably the right strategy.
> An e-book is going to heavily (and negatively) impact the sales figures for the print book What? Do you have a source on that claim? For me, I only get ebooks for programming books because I can have the IDE side by side with the PDF, no need to continuously look at the physical book and then back into my IDE, and I can copy paste code examples.
Earlier quoted context omitted.
script style languages specifically designed with modern concepts and to be highly performant. V8 is likely the fastest interpreter (javascript) for a script style language but these languages should be a step above and beyond v8 in terms of performance.
Nim is not a "script style language". By default it compiles to C, and the generated C sources are then compiled with gcc or clang, etc. As it says on nim-lang.org, "Nim is a statically typed compiled systems programming language".
Earlier quoted context omitted.
Glad to hear you're interested in Nexus. The ORM currently uses db_postgres (from Nim's stdlib) only. I'm going to implement support for db_mysql and db_sqlite as well, it should be easy enough given how similar the API for the stdlib DB drivers are. Actual work on DB drivers is out-of-scope for me though. I noticed there is an async Postgres driver available: https://github.com/treeform/pg . I don't know how well te…
I went with db_postgres as well. Unfortunately, it is not async. I did consider treeform's pg, but unfortunately i did not get any reply from him on my question so decided not to go with it for the TE benchmarks. I think the lowest hanging fruit for db drivers would be to just wrap libpq, the default PG driver. Given Nim's c interop, that should be easy. I was planning to do that, but then life happened and I had to…