In this version off the game its not possible to pick up certain stuff (wooden beams / modern lamps etc..), while other stuff can be picked up easly (scaffoldings...)
Right now construction elements (i.e. planks, beams) can't be deconstructed, this will be added in the future 
Apart from that, you can't remove certain objects, like lamps, although that's actually intended behaviour: Once electricity is implemented, lamps are going to require proper wiring and a power source, so in other words, it's going to require much more effort to use lamps. So since it's quite easy to use lamps now, we wanted to have at least a small limitation by preventing players from picking them up^^
also in the future is the gui going to be remade?
Probably there won't be a full rework of the gui, but I guess we're going to enable people to customize it (especially when it comes to the position of certain gui elements)
Also a realy small question: why did u (@red) programmed this game in java and not c++?
Basically @Miwarre hit the nail on the head: Java offers great portability.
Although Java has a bad reputation, it is unfounded. It had some serious flaws in the 90s, but since then, things have changed dramatically. In terms of performance, there wouldn't be a big difference between Java and C++ (although first we have to be clear about the term "performance": if we are talking about the speed of computations, there is no difference between the various high level languages, your CPU can calculate "1+1" always at the same speed^^). Although Java is a little bit more "limited" when it comes to memory management, due to its automated garbage collection process, one have to say it actually does a good job. Having full control of these things *might* result in a better performance (or better memory management) though, but this only applies if you know what you're doing. Many big C++ projects use garbage collectors as well, and I doubt they're doing a better job at all^^
The formula "higher abstraction == less control == worse performance" might be true in certain cases theoretically, but then we could also decide to write our applications in Assembly, for example
Speaking about memory, there is indeed a minor "disadvantage" in Java: The overhead of the VM, which is unavoidable. But this is nothing to worry about, it's maybe 50 mb or something like that, which shouldn't be a big deal nowadays. You have to keep in mind that every language has advantages and disadvantages.
I dont think this game is limited at the graphics output atm, my system is literly doing almost nothing and i still get low fps
Your framerate depends on various factors. On the one hand, the performance of your CPU of course (not only the number of cores matter [and the "type" of a core, there is a difference between AMD and Intel, for example], also the clock speed, and especially the amount of work that is done per clock cycle), but also your graphics card, your RAM, your VRAM and your harddrive (and - of course - the state of your system, installed software etc).
java is also know for not alowing 100% system usage thanks to its virtual machine.
This isn't true. Where do you get these information?
not to mention vulkan for taking things the next level
Vulkan is still in an early state. Besides the fact that the Vulkan API wasn't available when we started developing RW, even now it wouldn't make much sense if a game fully relies on Vulkan. I'm confident that Vulkan is going to be great, but right now it's too early to concentrate on it. Furthermore, many old graphics cards don't even support Vulkan (Radeon 7000, 6000, 5000 series etc, Geforce 500, 400, 300, 200 series etc), and apparently there are several people out there who have even older hardware 
Thanks for letting us know, it will be fixed with the next update 
I tested all scenarios, i.e. setting position/rotation before adding the model, setting position/rotation after adding the model, calling moveTo() before/after adding the model etc.
