Nope. Electron is a whole browser under your seat, QML is a declarative language to instantiate C++ UI objects. The core logic of your application is written in C++/Qt instead of Javascript.
> QML still has only rudimentary support for AOT compilation
Fair point. But it shouldn't really matter in any application today, as your logic must reside in C++ models if you want to have real performance.
Develer is a not so small company that develops software for third parties; our team is composed of passionate people who enjoy coding and learn new technologies. We are looking for software engineers to grow our web-oriented team. Here are some things you will work on:
* full-stack development of performance critical web applications;
* development of HTTP APIs for mobile and web applications;
* full-stack development of real time monitoring dashboards;
* UIs based on web technologies to control industrial appliances;
* mobile application development using React Native.
Our preferred technologies are Python (Django and Flask), Go, React, React Native and frameworks for single page web applications, but we welcome any passionate developer.
If you also know any of AngularJs, Ruby, version control systems or other programming languages (eg. C or C++) you have our attention!
We require at least 2 weeks per month onsite and proficiency in Italian language.
Develer is a not so small company that develops software for third parties; our team is composed of passionate people who enjoy coding and learn new technologies. We are looking for software engineers to grow one of our teams working on embedded products. Here are some projects you will work on:
* Creation of dynamic UIs on systems with limited resources (even without GPU);
* Development of multi platform desktop applications with Qt libraries;
* Creation of system daemons for embedded Linux systems;
* Kernel level programming;
* Firmware for ARM-based devices.
We offer a developer-centric environment with the following benefits:
* 24/7 office access: work any time of the day you are more productive.
* Large desks in quiet offices, with large or multi monitors and powerful PCs
* Informal environment: free coffee, drinks and snacks, relax room with fussball, table tennis, retrogaming, consoles, music instruments...
We require at least 2 weeks per month onsite and proficiency in Italian language.
Send us your CV and some code examples at https://www.develer.com/jobs/
Develer is a not so small company that develops software for third parties; our team is composed of passionate people who enjoy coding and learn new technologies. We are looking for software engineers to grow one of our teams working on embedded products. Here are some projects you will work on:
* Creation of dynamic UIs on systems with limited resources (even without GPU);
* Development of multi platform desktop applications with Qt libraries;
* Creation of system daemons for embedded Linux systems;
* Kernel level programming;
* Firmware for ARM-based devices.
We offer a developer-centric environment with the following benefits:
* 24/7 office access: work any time of the day you are more productive.
* Large desks in quiet offices, with large or multi monitors and powerful PCs
* Symmetric 100Mb internet
* Informal environment: free coffee, drinks and snacks, relax room with fussball, table tennis, retrogaming, consoles, music instruments...
We require at least 2 weeks per month onsite and proficiency in Italian language.
'use' statements are relative to the root of the crate, not the current module. To work around this, you can write 'use self::name' or 'use super::name' for relative imports. Annoying but no big deal.
I'm writing an application. Inside main.rs I can write
extern crate foo;
use foo::Bar;
If I create a module and use the same crate, I need to write:
extern crate foo;
use self::foo::Bar;
This always surprises me and I never found anything explicit written on the Book. To me, it looks like a nice papercut to fix.
Why do you have an `extern crate foo` line inside a module that I'm assuming (because of the `self`) is part of crate foo? You shouldn't need to `extern crate` inside that crate itself.
One thing that might be confusing is that `main.rs` is the entry file of binary crates, while `lib.rs` is the entry file of library crates, and a project can contain both a binary and a library crate. The binary crate then does need to `extern crate` the library crate.
We've been working on a new version of the book, if you have time, I'd love if you would take a look at the new chapter on modules [1] and file PRs or issues on the repo [2] if it's still confusing or leaving you with unresolved questions!
I keep tripping over that as well. It makes the crate root feel special compared to other modules, and that's annoying because most people learning the language probably spend a lot of time in the crate root, writing simple toy programs.
Sorry, I don't really grasp your comment. Maybe I can clarify what I'm trying to do.
My typical use case is importing definitions, for example an error type or enum from the crate, let's say something from tokio_core.
I'd like to use this enum both in main and in my module; from my (limited) experience, you need to extern crate tokio_core both in main and the module, then use the definition. In this case the syntax is different for somewhat obscure reasons.
Hmmmm, do you mean that you don't want to put all your `extern crate` statements in the root of your library? If you do that, you don't have to have the `self` when you use items from the crate within your modules. I've never wanted to put my `extern crate` statements within a module rather than the library crate root; can you elaborate on why you want to do that?
Hm, I'm still confused about what you're trying to do :-/ If you're trying to use something from tokio_core in your own crate, in neither place will `use self` do that, like you had in your first example... it would be `use tokio_core::foo::Bar`... and the `self` was the only difference between the binary and library, so I'm not sure what the paper cut is exactly.
Basically I start hacking on a project, then when finally something is working, I want to split it into a separate "something". Coming from the C++ world, I'd create a new cpp/h couple, maybe in its own subdir. I understand that the equivalent in Rust is creating a module.
Let's say that after my refactor, I've "moved" the crate import into the module since "logically" it belongs there. In this case the compilation fails if I don't use self::. But previously it was working in main.rs! And I have no idea why...
This is the "use starts at the crate root" thing. If you move the "extern crate", then the place it ends up in the module hierarchy is different, and so it breaks.
I always leave "extern crate" in the crate root; then it all Just Works.
The convention is to always keep `extern crate`s in the crate root. `use`s get moved around, but `extern crate`s stay put. Think of `extern crate` as if it were a crate-internal `pub use` (because that's kind of what it is!).
Florence, Italy | ONSITE | Italian language proficiency needed
Develer is a not so small company that develops software for third parties; our team is composed of passionate people who enjoy coding and learn new technologies. We are looking for software engineers to grow our web-oriented team. Here are some things you will work on:
* full-stack development of performance critical web applications;
* development of HTTP APIs for mobile and web applications;
* full-stack development of real time monitoring dashboards;
* UIs based on web technologies to control industrial appliances;
* mobile application development using React Native.
Our preferred technologies are Python (Django and Flask), Go, React, React Native and frameworks for single page web applications, but we welcome any passionate developer.
If you also know any of AngularJs, Ruby, version control systems or other programming languages (eg. C or C++) you have our attention!
We require at least 2 weeks per month onsite and proficiency in Italian language.
3D CAD developer | Florence, Italy | ONSITE | Italian language proficiency needed
Develer is a not so small company that develops software for third parties; our team is composed of passionate people who enjoy coding and learn new technologies. We are looking for a software engineer with solid experience in building 3D modelling software, with particular experience in the following areas:
* real time mesh visualization using OpenGL or Direct3D;
* development of mesh manipulation algorithms, for example local or geometric transformations in real time;
* interaction with a 3D model, for example free drawing on a 3D surface.
Our tech stack is composed mainly of C++, Qt, Python and OpenGL.
We offer a developer-centric environment with the following benefits:
* 24/7 office access: work any time of the day you are more productive.
* Large desks in quiet offices, with large or multi monitors and powerful PCs
* Symmetric 100Mb internet
* Informal environment: free coffee, drinks and snacks, relax room with fussball, tennis table, retrogaming, consoles, music instruments...
We require at least 2 weeks per month onsite and proficiency in Italian language.
3D CAD developer | Florence, Italy ONSITE | Italian language proficiency needed
Develer is a not so small company that develops software for third parties; our team is composed of passionate people who enjoy coding and learn new technologies. We are looking for a software engineer with solid experience in building 3D modelling software, with particular experience in the following areas:
* real time mesh visualization using OpenGL or Direct3D;
* development of mesh manipulation algorithms, for example local or geometric transformations in real time;
* interaction with a 3D model, for example free drawing on a 3D surface.
Our tech stack is composed mainly of C++, Qt, Python and OpenGL.
We offer a developer-centric environment with the following benefits:
* 24/7 office access: work any time of the day you are more productive.
* Large desks in quiet offices, with large or multi monitors and powerful PCs
* Symmetric 100Mb internet
* Informal environment: free coffee, drinks and snacks, relax room with fussball, retrogaming, consoles, music instruments...
We require at least 2 weeks per month onsite and proficiency in Italian language.
Frontend and backend developers | Florence, Italy ONSITE | Italian language proficiency needed
Develer is a not so small company that develops software for third parties; our team is composed of passionate people who enjoy coding and learn new technologies. We are looking for software engineers to grow our web-oriented team. Here are some things you will work on:
* full-stack development of performance critical web applications;
* development of HTTP APIs for mobile and web applications;
* full-stack development of real time monitoring dashboards;
* UIs based on web technologies to control industrial appliances;
* mobile application development using React Native.
Our preferred technologies are Python (Django and Flask), Go, React, React Native and frameworks for single page web applications, but we welcome any passionate developer.
If you also know any of AngularJs, Ruby, version control systems or other programming languages (eg. C or C++) you have our attention!
We require at least 2 weeks per month onsite and proficiency in Italian language.
Eclectic software developers | Florence, Italy ONSITE | Italian language proficiency needed
Develer is a not so small company that develops software for third parties; our team is composed of passionate people who enjoy coding and learn new technologies. We are looking for software engineers to grow one of our teams working on embedded products.
The technologies we use are very varied, ranging from C++/Qt to React Native, from Go to Python because we work on very different projects: home automation software, medical equipment, mobile apps to control industrial machines.
We offer a developer-centric environment with the following benefits:
* 24/7 office access: work any time of the day you are more productive.
* Large desks in quiet offices, with large or multi monitors and powerful PCs
* Symmetric 100Mb internet
* Informal environment: free coffee, drinks and snacks, relax room with fussball, retrogaming, consoles, music instruments...
We require at least 2 weeks per month onsite and proficiency in Italian language.
Nope. Electron is a whole browser under your seat, QML is a declarative language to instantiate C++ UI objects. The core logic of your application is written in C++/Qt instead of Javascript.
> QML still has only rudimentary support for AOT compilation
Fair point. But it shouldn't really matter in any application today, as your logic must reside in C++ models if you want to have real performance.