I have many years of C (Linux IO) and Nodejs (IO, Interaction) experience. And my job now is about developing visualization software based on Electron. I writed some Nim codes stealthily in my projects (IPC with Nodejs codes).
I'm not good at English, but I want to say "Hi, Nim! Hurry up!"
I heard about Rust OS some months ago (Is there one more than Redox). I think that is very interesting, indeed that would be my main motivation to learn Rust language deeply.
But it is very hard for new operating systems to become popular. For Linux it was a bit different, because it was only a Unix clone, so it was not necessary to develop new ideas, and some people where already familiar with Unix.
Most other new OS failed. Most critical are device drivers, for which often only closed source drivers exist. Using these may be difficult, and may destroy the benefits of a new, secure OS. And developing other state of the art core components is much work, as Wayland display system, GUI toolkit, OpenGL/Vulkan support or a file system like BtrFs. And all the other Tools -- for Linux we still have no real good CAD or Photoshop, just to name 2. Of course with a good language it is a lot easier and faster, but still take much man power.
But maybe Rust OS will get strong support from a very big company or government?
Redox: I like the idea that people want to build an operating system in Rust. I think it is a great way to show how powerful and productive that language is. As a real operating system that people want to use, I dont really want it. I am using Linux, and I have already not all software. Adding another operating system on the pile of operating systems does not help here. Maybe some binary operating system independent package that will run on operating systems that did not even exist at the time of package creation would help here. I think maybe webassembly could provide a nice base for the future.
Electron: sort version: meh. long version: I don't use web development tools. I like the original idea of the web as a global hyper text. So it is natural that a markup language was developed for it. That is what HTML was designed for. But application development? That is not what that technology was designed for. Desktop applications that use web technology always seem so bloated. You start a text editor and first it does is allocating a gigabyte of RAM before the first text file is opened. I think more people should put energy on better cross platform application development, there is definitively still a lot open to develop, but instead everybody puts so much energy in this big workaround that web development is, that they simply forget that it is not necessary to have that html/css fuss in the middle, and still write good cross platform applications.
Redox looks impressive and while it would be nice for us if it were written in Nim, it's high time people stop writing C code. :-) It's a nice project.
<rant>Too bad it implements a Unix which means a stringly typed programming environment, defective shell scripting languages, tons of red tape, cryptic 2 letter commands that pretend vowels have yet to be invented, unusable directory layouts and all the known security problems. My new favorite example is: "Maybe /dev/urandom is symlinked to /dev/zero?" taken from http://insanecoding.blogspot.de/2014/05/a-good-idea-with-bad-usage-devurandom.html </rant>
Rant aside, as a user I welcome every effort in creating more stable software.
@Krux02
You should really look at Zephry JavaScript --- "JavaScript* is one of the most widely used programming languages today, and in recent years has jumped from its origins on desktop web browsers to servers with Node.js*. But it can also be useful in the smallest devices for the Internet of Things (IoT) with the JavaScript Runtime for Zephyr™ OS (ZJS) environment."
applications are written in C, and the programming model requires a fair amount of expertise. A JavaScript interface hides a lot of this complexity.
Hiding complexity does not remove complexity. It just gives you the illusion that things are simpler, when they are not. That is one of the worst things you can do, it just creates you the illusion to understand a system when in reality you just don't. Maybe it will help you to finish your hello world, or hello sensor application faster, but when you really want to get into details and understand the system, hiding the details and complexity just gets in your way of accomplishing this goal.
Hiding complexity does not remove complexity. It just gives you the illusion that things are simpler, when they are not.
Do you really understand the (gtk, winform) system when you develop an application using GTK or winform? No, you don't unless you are a core member of GTK / winform.
It is the same with Electron.
Complexities are not valuable. Programers should focus on logic algorithms rather than complexities.
Electron is not a simple adhesive, but a careful design
Electron enables you to create desktop applications with pure JavaScript by providing a runtime with rich native (operating system) APIs. This doesn’t mean Electron is a JavaScript binding to graphical user interface (GUI) libraries. Instead, Electron uses web pages as its GUI, so you could also see it as a minimal Chromium browser, controlled by JavaScript. In Electron, the process that runs package.json’s main script is called the main process. Since Electron uses Chromium for displaying web pages, Chromium’s multi-process architecture is also used. Each web page in Electron runs in its own process, which is called the renderer process. In order to keep Electron small (file size) and sustainable (the spread of dependencies and APIs) the project limits the scope of the core project. Electron uses just the rendering library from Chromium rather than all of Chromium.
As for JavaScript, Douglas Crockford said: "JavaScript is the world's most misunderstood programming language. JavaScript is becoming better than ever. I mean such as ECMAScript6 (Module, Class, generator, Promise) ECMAScript7 (async await)."
Heh, that JS hype reminds me of ol-time tobacco ads: buzzwords, distractions, excuses for bad habits...
It doesn't negate the central points of the criticism, that NodeJS and especially Electron take badly structured, unreliable, syntactically ugly, and slow Web UI/UX technologies that everyone uses mainly because they have to, and needlessly spreads that cancer to a new domain where better technologies already exist.
JS is popular because it was the only choice for client-side scripting on a platform supported by pretty much every computer / smartphone user in the world. Better programmers than I have enumerated its many shortcomings.
And ES.zomg.next is "not a safe cigarette" - it's still a terrible programming language built on a terrible foundation, and throwing more layers over it doesn't make it good.
Most colleges don't mind teaching bad technologies if that's what they think the marketplace demands; most software businesses don't mind using bad technologies if that's what they think the marketplace provides (thus making coders easier to replace); and most people just don't know better.
I've done some informal automated analysis of language package ecosystems recently: NodeJS came on the bottom (and Haskell was on top) in package and meta-data coherence. Scriptkiddie NPM packages breed like rabbits, with little regard to quality. There will always be fewer Osteria Francescanas than Taco Bells...
Electron is like a formerly-homeless guy who comes into money and now lives in a mansion, but still insists on making all furniture from milk crates and cardboard. Just because you can do something doesn't make it a good idea.
And Electron not the first effort to do this (ex: XUL in 2006). You've previously made arguments from popularity, so compare the desktop market share of HTML/JS-pushers like XUL and Electron compared to real UI toolkits like GTK & Qt.
Another reason to dislike Electron is it's only really good for Windows / Mac / Linux workstations with resources to burn. The only things that crashed on my Ubuntu laptop over the past year are Atom and VS Code (which I've only used for its top-notch Nim support). On lower-end / older / mobile devices you get terrible speed, wasted battery life, and there's no portability to other OS'es. I'm actually a BSD nerd, but these days mostly on the server, and I now use Android 2-in-1 client tablets for more battery life off-the-grid - Electron doesn't run on any of that...
In addition, you can also choose excellent TypeScript [...]
TypeScript is more verbose than Nim, is more restrictively licensed, and has far fewer features. It is generally slower than Dart and untyped JS, and thus for binary targets it would be A LOT slower than Nim.
Compiled is always better than interpreted, because no code format will ever be simultaneously ideal for both human programmers and computers. The ideal programming language / compiler is the longest possible bridge between the human devs' coding comfort and the efficiency / correctness of the resulting binary.
<!-- START of the part you've quoted without context. -->
Computers becoming faster (including latency to a compile service in the cloud) should have encouraged smarter compilers instead of more interpreter / VM bloat.
<!-- END of the part you've quoted without context. -->
Most of the time we care little about execution efficiency (unless a piece of code is executed zillions of times), but it will become important again with IoT and beyond, as programmable nanotech robots become a reality.
Today, distributed technology and big data processing technology has made great progress. People can use thousands of machines to compute parellelly. People are more concerned about logic algorithms, intelligent analysis and visualization result. Who care it is a compiler or interpreter???
Your selective quoting has made it look like I was against VMs and run-time optimization of any kind (for which you can have libraries for almost any language), which isn't true. My main point was about the importance of smart compilers building a bridge from greater dev productivity to more correct and efficient executable code, the latter being particularly important for IoT / nanotech devices.
Your response ignores my arguments and throws yet another distraction. Squirrel! [No pun intended.] Now we jump from talking about IoT to distributed Big Data (even though like >99.9% of code is written to run on one device) - how does that negate my criticism of JS? Taking an uglier, slower, unsound programming language into distributed context doesn't change any of those shortcomings.
I listed some popular excellence systems currently. Microsoft, Linux foundation, Google Cloud, Intel and etc are all working for them. Then, somebody thought HTML, JS, and ... are so crap, and complexity is so important. OK. We can discuss these. Don't we?
Did you given any valuable evidence yet? No, you didn't. All that you talked about are your c++ and your GUI. Do I guess right? You have never developed a project outside of your C++ language. How did Linus talk about the C++ language ever? I don't want to repeat it at all.
And you don't understand WebAssembly at all. Do you think WebAssembly will make things less complex and easier to understand? It's so wrong. WebAssembly is just a standard of intermediate code. You still have to face your bloated ugly grammar and user interface. WebAssembly just make you using c++ to generate browser assembly code to run in web containers. We all know how poor C++ UI is. WebAssembly won't hiding complexity, nor removing complexity.
Electron, developed from Github. Visual Studio Code is written by Electron. Nylas Mail is written by Electron. You must have seen the mail If you have a mac. Many projects have proved a great success.
The claim that you seem to be making is that Electron.JS is a better desktop app development framework than native applications - a category that includes all software in C, C++, Objective-C, Swift, Delphi, Ada, D, etc. You can think of Nim as being comparable to those languages, or as being for C/C++ what CoffeeScript and NPM are for JS.
By what criteria is ElectronJS better?
It is rather indisputable that ElectronJS results in much slower apps. The only fully baked examples of Electron-based apps are all text editors that heavily target Web developers. I've tried a number of other work-in-progress projects, and they were all pre-alpha - nothing but crash-and-burn. (I would really hate to see it being used to replace something like Blender...)
You make a lot of appeals to popularity. Indeed, according to the 2016 StackOverflow survey, Electron-based editors add up to a respectable 20.8% market share. But the most popular four options (Notepad++, the real Visual Studio, Sublime, and Vim) are native code. A lot of other native editors / IDEs (Kdevelop, CodeBlocks, Code::Lite, Anjuta, etc) are lost in the "Other" category.
C++ is the basis of the vast majority of high-end games and the most popular desktop applications in the world, including MS Office (yes, with some .NET thrown on top, which doesn't help your argument for Electron), Apple Xcode and pretty much all Apple iOS / Cocoa stuff, VLC Media Player, BitTorrent, Skype, Bitcoin Core, VirtualBox, Pidgin, etc.
And Linus criticism of C++ in favor of C in the Linux kernel (which I agree with) has nothing to do with using Nim vs ElectronJS for desktop applications.
@Araq
I'm having enough of this now. Disagreeing is not "not understanding".
One should always base one's opinion on facts rather than write hundreds of lines of code. You said you know the JS language well. Have you ever used one of the following tools: TypeScript or Babel, Webpack, Browserify, Gulp, Grunt, React-Native, Electron, NodeJS? If you don't use anyone, could I say "you don't understand JS"? You know, these are tough requirements for a JavaScript engineer.
@Libman
There is no point in what you say. You never volunteer your time to do anything.
@Araq
Now, waste your rights! I've seen a narrow minded team living in a Utopia.
Bye bye! Hope you never use the JavaScript language and libuv.
Why don't Nimers develop an os system?
Mozilla Foundation gets tens to hundreds of millions of dollars a year. Nim is getting started with a lot less, for now.
Why there is no a good GUI facilities? (Fortunately, we had nimx. Wish nimx have a better future)
GTK and Qt are not good GUI facilities? I'm not a fan of them myself, but they seem to be behind the best desktop apps (which don't crash if you open too big a file).
Why don't Nim care about IoT, big data processing (such as hadoop), intelligent robot (such as ros), cloud facilities (such as docker, openstack), ... ?
Because we're wasting too much time debunking trolls on the message forum?
When I recommended Nim language to other people, they say they hate indentation.
There's a pretty strong consensus that indenting code improves readability. What those other people mean to say is that they need useless syntax / streams of "end end end" lines which waste horizontal screen space and add nothing of value. There are many code editor features that can help them with that without annoying better programmers who don't need such inept crutches. If all else fails, use #{ and #} ;)
For non-blocking io, language is not a performance bottleneck
That's not what every NodeJS vs Native Code benchmark evidence indicates. You should actually read what I say, including the links - you might learn something. There's a reason why so many NodeJS users are switching to Go, etc.
Furthermore, with Electron we're talking about desktop apps, which in today's world also includes laptops, tablets, and other mobile devices - where performance is measured not just in seconds but in mAh.
There is no point in what you say.
Typical evasion of the fact that you've made unsubstantiated claims that were thoroughly refuted.
You never volunteer your time to do anything.
You know all about me, now do ya? That's a particularly ignorant thing to say to someone who has pretty much devoted his whole life to unpaid projects...
You said you know the JS language well. Have you ever used one of the following tools: TypeScript or Babel, Webpack, Browserify, Gulp, Grunt, React-Native, Electron, NodeJS? If you don't use anyone, could I say "you don't understand JS"? You know, these are tough requirements for a JavaScript engineer.
TypeScript is not JavaScript and the other packages cannot fix foo.typo > 5 because libraries cannot fix core language design problems. For a decent "JavaScript engineer" you surely know very little about how JavaScript actually works.
Bye bye! Hope you never use the JavaScript language and libuv.
Don't take people not liking JS personally, it's no knock on you. JS is an important technology right now, even if there's disagreements on it being the best technology. JS and Nim are pretty much at opposite ends of the spectrum in language design, so it's not hugely surprising some on the Nim forum aren't fans of JS. Isn't that half the point of Nim having JS as a target - so you can output JS in Nim with all it's strong typing and metaprogramming, rather than having to use plain JS?
Back on topic.
Regarding IoT, I see a lot of embedded stuff using tiny JS engines. I know people have used Nim for embedded stuff but I would imagine Nim could get better performance to memory overhead than a JS interpretter running on an embedded platform. I'd like to see any projects related to that. One query I have is the memory overhead required with GC. I don't expect it's much, but can you fit a Nim program on an Arduino using the GC?
For reference for those who haven't seen it here's a simple project with GC turned off on Arduino: http://disconnected.systems/posts/nim-on-adruino/
I think Arduino has between 2-30kb of memory.
This also interests me because I do some embedded work in C and, well... C can be trying sometimes, however it doesn't get much leaner in terms of memory usage. I often look at 1000 lines of C code and think that it could probably be done in about 2-300 lines of Nim and be far less error prone. So how does Nim stand up with 256/512kb ram (which is what I get to play with)? Pretty fat for embedded, right?! Thinking Nim should be able to run on that without any problems, but not certain.
In terms of Electron as x-platform framework. Personally I too am not a fan of web tech on desktops but it does serve the cross-platform goal. I used to think it was slow and bloated but VSCode has changed my opinion of that, it's become one of my favourite editors and has awesome Nim support. However can't see me using Electron in personal projects. I'm quite tempted by nimx though.
The Rust OS, well that's a great way of testing the metal of low level access and performance. It'd be nice to see an expansion of dom96's Nim OS just to see if it brings to light any weak areas in very low level code, but to my mind what we really need is some big useful technology stuff that people can say "here's an example of Nim tech", and OS are generally proof of concepts rather than usable tech, unless backed by truly massive companies (some counter examples to this?)
I really tried to not reply on this thread, because ... it's a subject of endless discussion. :) I work currently in Electron, our Workbench at Evothings is written in Electron and ... well, there is nothing inherently wrong with Electron itself (making it possible to write desktop apps in web tech), but I do find the whole javascript ecosystem and the language itself to be a "swamp". Unfortunately its eating the World right now.
I am not the typical Nim guy, since I actually love Smalltalk (dynamically typed etc, but of course much, much nicer than js), but I also find Nim to be the first statically typed language in a loooong time that I can actually like working in. So my distaste for js is not based on the classic "I hate dynamic typing"-stance, it's more based on the fact that the language is such an awful mess. ;)
But enough on that, I wanted to mention Ardunimo , a little thing I did to get Nim running on the LinkIt ONE and to use the Arduino framework. The LinkIt is a fairly strong little machine, but my experiments indicates that Nim works superbly on these little things. Also, I am quite interested in espruino, micropython etc, and they should definitely be taken seriously - espruino for example does clever things to save battery all automatically I think, stuff that you would need to handle manually in C++. But the thing is, Nim would still truly outclass js or any other interpreted language on these machines and still be clean and easy enough to actually compete with Python/Javascript in the "easy to use"-department.
yes it is endless discussion, maybe that is the reason this thread should be closed. It is not constructive and very opinion based. Stace Overflow likes to close those questions very fast.
@gokr Thank you, I think it was wise not to join this thread. But now I really liked to read your contribution. I am just not replying because I don't really want to encourage anybody anymore to write in this thread. It is mostly pointless to argue about opinions about technology.