HN user
Unironically, yes. That's exactly how anarcho-capitalists see it. To them, Anarchy just means "no coercion/state", it doesn't mean a lack of structure, delegation or coordination.
This is quite cool.
Created this short visual narrative with Dall-E in the style of H.R. Giger.
Human figures live their lives in a surreal dystopian world, until they find a hole leading to an even stranger one.
Video was made with React Remotion which was pretty cool. If anything, check that out.
All you've done is push the burden of constructing the dependency to whomever is calling an passing that dependency to __init__
Consistently applied, all construction gets pushed to the entry-point of the program. Congratulations, you've just discovered the so-called "composition root".
Now that all construction is taking place at once, the order matters as you can't pass a dependency to its dependent until the dependency has been constructed. But it may have its own dependencies. So now there is a topological sorting problem.
Turns out computers are really good at topological sorting. So, someone made the computer do it, and we call that a dependency injection container. Tada.
When this was first being presented at the Hackathon where it was created, I joined a few seconds late due to some camera trouble. My first thoughts where "Wow, they really went above and beyond, so tightly choreographing their presentation to their slides." Then it slowly dawned on me what was happening. Funny stuff.
I'm still having this issue.
If the code is implementing against interfaces, why would late binding mess up your IDE experience at all?
In my opinion, you probably don't have good reasons.
I have a hard time seeing anything new here. Just .. [a] new perspective...
okie dokie
I have recently started looking into Nix to solve the problem of dotfile deployment to new OSX workstations. When you get a new laptop, you clone your dotfiles, maybe symlink them to your home directory -- and then what? Nix solves this problem for me by coupling my dotfile deployment with the installation of the related software.
The learning curve has been absolutely tremendous, however. That said, the support on Freenode has been some of the best I've encountered in more than a decade.
https://nixos.org/nix/manual/#chap-package-management https://rycee.net/posts/2017-07-02-manage-your-home-with-nix...
ITM
This is by far the best podcast Ive personally enjoyed besides maybe Waking Up with Sam Harris. The "old friends" chemistry the hosts have cannot be understated. In the morning!
...and user type-classes, compile-time AST macros, and GC-as-an-API
Would really appreciate some kind of link to the discussion you mentioned..
Oh sure. I'm asking specifically, given that I'm writing software happily in Nim, what potential pitfalls am I blind to? My software is compiling to C and it shouldn't be so I'm wondering what can I expect to actually experience using Nim, outside of Hacker News posts about Nim.
Oh, I've been writing software in Nim pretty happily for a months now. What problems am I blind to?
Huh, I keep hearing more and more about it in places I'd never suspect.
I'll go ahead and plug my own introduction video which gives a light introduction to the core grammar concepts in lojban: https://www.youtube.com/watch?v=yZjSTUK3hFI
If you can absorb what's in this video, you could probably pick up lojban with little effort on the grammar side. Alas, vocabulary is just something you have to get through.
You were down-voted but I actually agree. I did conclude the article by saying that templates seem really nice for closing the gap on refactoring code that not even generics could wrap up. So the intention was to convey that templates are really a last resort secret weapon. They just also seem to be pretty easy to understand :)
You were down-voted but I secretly agree.
wait - oops. :)
These are definitely exciting times for container networking!
Thank you. My mouth was literally agape.
Hey I am just curious as to what you see as the dark corners of Nim?
I certainly agree.
Hey I come from Python too and I just want to put out there both that Nim is a normal language - you can use it without templates or macros (you might end up using someone else's macro because some stdlib or library is implemented as one, but you don't have to write them yourself) - but also that Nim's macros are quite easy to understand!
They are just functions that take an AST tree, modify that AST or produce a new AST and return it. Its just normal Nim code working on an AST object. That's it! I wrote a small blog article about them when I first learned about them: http://blog.ldlework.com/a-cursory-look-at-meta-programming-...
I encourage you to conquer your fears!
While I'm not super familiar with the scientific computing field, I can say that Nim needs everyone's help in building the library ecology. Right now, Nim seems to be in the wrap-all-the-things! mode. You can see that most of the available packages are bindings to existing libraries. I'm not sure this is a bad thing. And I don't think it has anything to do with anything other than Nim's currently small community.
Thanks for that explanation
As a long time Python programmer who has struggled to cross the gap from dynamic scripting languages to modern statically typed languages Nim is by far the most frictionless language I have tried. Before I found Nim I longed for a language like C# where the generics "just work" and overall the language just feels like it designed at-once rather than piecemeal overtime. Everything just seem really "nice" in C# and I am able to transfer my Python experience over to it. But being locked up to .NET/Mono I never really used it outside of Unity3D.
I tried Golang, because it was sold to me as something I would love since I am a long time Python developer. I strongly dislike Golang. It doesn't have much in the way of letting me model my programs like I am used to. I am told "that's wrong, do it the Go way". This is too much friction. Once I am done thinking how to solve my problem algorithmically, I do not want to then figure out how to rethink my algorithm just for the sake of the maintainer's of Golang.
I tried Rust. I think Rust is beautiful (mostly). However, Rust has a far too fundamentalist view on memory safety. And that's not to downplay the importance of memory safety. But there's just too much friction. I want to sit down an implement my algorithm. I don't want to stop and spend just as much time thinking about the particulars that Rust demands.
When I found Nim I almost couldn't believe it. The core language was simple, clean and immediately absorbable. I was able to start writing basic Nim programs after just perusing the language docs for a few minutes while the compiler compiled. I read that Nim had powerful meta-programming facilities and this started to turn me off. I had heard that macros were generally a negative force in the world but only knew them from Lisp. Then I learned that Nim's macros are just functions that take and AST tree, perform modifications to that AST and return an AST tree. Wow that's pretty simple. Oh hey the generics "just work" like in C#. Woah, Nim even supports inheritance!
Nim is definitely the next language for me. In thinking about it, I find that I agree with one of Jonathon Blow's sentiments that we have been seeing a number of new up and coming languages but they are all Big Idea languages. Big Idea languages who's ideas have yet to be vetted and proved out over the course of a decade or two. They all incur too much friction.
Nim seems like a competent, low-level systems language with a helpful repertoire of well-implemented modern tunings to features that are all mostly established in the field. It doesn't try to revolutionize systems languages. It tries to bring us a modern refinement by bringing us a highly performant yet relentlessly productive take on what has already been shown to work.
Please don't be offended if you see me around evangelizing its existence.
You mean like the conferences they held before they even had a viable product?
The conference was awesome and there was plenty to announce at that point. It certainly helped drive home the conceptualization of containerization for many.
we should take a good minute and consider
You're right we should consider - except what you're doing is making charges like;
"we are head-first rushing", "perpetuated by a for-profit company", "my company will be at the whims of Docker"
And other fear in this thread without providing your audience with the context of: - for profit companies backing an innumerable number of major technologies in a variety of fields since technology was a thing - most of the development of Docker happens outside of Docker Inc - the project has an independent governance board - the project has been nothing but the epitome of successful transparent open source
If Docker ends up achieving a cohesive ecosystem of holistically designed pieces solving one of the most difficult unsolved problems (a class of problems, really) in modern computing benefiting so many then is it really a problem paying Docker Inc for first class support to all of that? I imagine there are already companies selling support for Docker other than Docker Inc
It seems like you're the one imagining there is going to be no competition, honestly.