In the short term, yes.
Over the long run, I think it's good that we move away from the "seeying is believing" model, since that was already abused by bad actors/propaganda
Hopefully, not too much chaos until we find another solution.
I would classify ITER as basic research instead of a commercial nuclear power plant.
I didn't know that Enel operates nuclear power plants, that's interesting, but they seem to come from an acquisition of Endesa and have been constructed way before that acquisition, and from designs of foreign places. So they aren't modern generation reactors that one would want to build from scratch.
As for the Slovakian nuclear power plant, it's a russian design as well.
I don't doubt that Enel could operate nuclear reactors of foreign design, where Canada, Russia and France have strong capabilities, but if the design comes from a different country, do you really achieve the independence goal?
> I would classify ITER as basic research instead of a commercial nuclear power plant.
Absolutely correct. It will never serve as a power plant. It's a giant experiment, that's what the E stands for. We should be so lucky that one day it will generate a few minutes of power :)
yea same here. I wrote nodejs programs for years. the focus on the eventloop and everything being asynchronous is great for servers and network IO but does NOT make it the perfect choice for scripts. Its a different use case entirely.
scripts are supposed to be small simple programs that run in sequence and terminate. I shouldn't need to deal with concurrency primitives at all in that particular situation.
async/await are dead simple. And many Node libs have synchronous versions. It's pretty straightforward if you are familiar with the language. If you aren't, well that isn't really the fault of JS nor any different from bash or python, which can both be just as painful for those unfamiliar.
> scripts are supposed to be small simple programs that run in sequence and terminate. I shouldn't need to deal with concurrency primitives at all in that particular situation.
I suppose bash pipes are a concurrency primitive, but I don't object to them. I think it's more about appropriate primitives.
> And it's sooooo much faster that python and Ruby.
That advantage becomes vanishingly small when the language task is to glue together a bunch of spawn/fork/exec to external processes.
If the glue code somehow needs actual heavy processing, that processing can be factored out into another program dedicated to that, leaving only glue code. Side effect: the heavy processing code immediately becomes composable!
Especially because these languages are only one package/install away and not two. I don‘t really get for which audience is targeted here. Usage in JS projects maybe, but then why not write it as npm tasks. ..
I‘m playing around with dotnet-scripts [1] at the moment (C# shop mainly) and this has the same issue imho. The reason why I looked into it was because we have developers not accustomed to bash etc. I still find it silly and would rather use ruby so…
Do you mean writing the entire script in a single line in a string in a JSON file (package.json)? Of do you mean that string just calling out to a non-inline script? Because the use case for this is very much that latter script - it will often still be started via `npm run`.
That’s a completely arbitrary limitation which should not exist. When my scripts contain independent non-instant subprocesses, I run them in parallel. I’m also using js/ts to write all my scripts, because why wouldn’t I use a proper programming language instead of that “bash” thing that can’t even handle its single datatype well and resorts to all sorts of gibberish to perform trivial operations on it.
PHP is a surprisingly capable scripting language. Some relatively recent version is installed by default on a lot of Linux distros and its standard library has tons of functions for dealing with strings, files, and the network.
Because the whole point of the startup economy is not "find profitable companies" but "find unicorn companies that will pay back 1000 times what you invested". With this goal in mind, you can afford to lose your investment on 999 shit companies and find 1 successful startup and still break even.
Hence, you're looking for quantity over quality. Ideally, you'd have both, but the talent pool is only so deep.
> Ideally, you'd have both, but the talent pool is only so deep.
I was going to disagree with this, but instead I'll combine it with some of the other comments here.
I think you're right that the talent pool that they recognize is only so deep, and as some of the other commenters pointed out, the way talent is recognized is flawed. For example:
> The problem is 'due diligence' on a startup's prospects cannot be reasonably made and so investors end up making gut decisions ...
> ... chose any combination of name recognition, form fitting for preferred narrative of the day, social proof, in-group bias and proximity bias
> Same as lots of incompetent people are in senior positions, it's a complicated social construction, it's not just a skills ranking.
> 1. They're good salesman.
> 2. They convinced people/VCs who are also "talentless".
> It is about who you know, not what you know.
As most of us know, there is a lot of talent out there, but it's not pattern-matching with what the investors are looking for. There are other problems too of course, but that's one of them. Another might be that the talent doesn't have access to sufficient capital or connections to build up a business to the point that it's worthy of investor attention.
Speaking about myself, I still have reasonable confidence I'll end up in a good place, but it seems like it'll be a longer road than I had thought, and involve a path more like bootstrapping for 5-10 years.
