Comparing Rust and Java
llogiq.github.io
llogiq.github.io
Nothing in my mind though really beats the ecosystem around Java of these three in terms of IDE support, tooling and just simplicity in getting code out fast when you don't need low level access to things. Netty really brings great things to Java, and the many mature web frameworks for JVM languages are probably better than anything available for Rust right now. I'm not sure a sane person would write backend for a web site in C++. :P
Anyway I love both Rust and Java 8 and it's great to see them thriving.
What issues have you had with which build tool when using it outside the IDE?
open -a /Applications/IntelliJ\ IDEA\ 15\ CE.app build.gradle
There are a few rough edges, especially when one uses custom source sets. IDEA 16 is going to get better support for that [1].
[1]: http://blog.jetbrains.com/idea/2015/12/intellij-idea-16-eap-...
Can't speak for gradle but Netbeans has worked excellent with Maven for years.
Idea seems to work nicely as well (I haven't used it much for the last few years but my coworker across the table seems to like it with Maven as well.)
As for eclipse I haven't used it regularly since 2012 so I don't know.
Another underrated part of the Rust ecosystem is their RFC process, the multiple development streams and the six week dot-release iterations.
SBT is not adequately documented, relies too much on symbol-heavy syntax, and allows arbitrary code in build definitions.
And there is an oft-documented overuse of custom operators among Scala programmers, however I don't have sufficient expertise to gauge the resulting problems in practice.
I did; in fairness I don't think I've ever seen one in a maven pom.xml
I am yet to see Gradle perform as fast as Ant and Maven without fine-tuning and background daemons tricks .
Still, the end result is as you say.
https://dlang.org/spec/interfaceToC.html
D was at one point a C++ compiler but Walter Bright decided to break backward compatibility with C syntactically to allow the language to evolve in ways that C restricts, while still allowing it to interface with C. Sorry if I worded this poorly, but you may want to reconsider D and see for yourself if it feels like a second class citizen or what? There are sample projects interfacing to C projects (LuaD comes to mind).
https://www.youtube.com/watch?v=PJMTQmqxBqg
http://www.asahi-net.or.jp/~cs8k-cyu/windows/tt_e.html
Also, ported to Linux: http://www.emhsoft.com/ttrooper/
The D standard library is very dense (it makes C++14 standard library look ridiculously incomplete), so most things are available out of the box (threads, processes, filesystem, network, random, algorithms) ... in a portable way.
I ended up still writing it in C++ since Rust's support for writing COM objects/servers was not great, but I also ended up having to chase down a bug where I forgot to AddRef before storing a COM pointer in a map.
https://msdn.microsoft.com/en-us/library/ezzw7k98.aspx
https://msdn.microsoft.com/en-us/library/br244983.aspx
My point isn't that there aren't nice idiomatic ways of writing nice windows/c++ code that are not fragile, it's that unless you're well versed in them, you can easily screw things up pretty badly.
[EDIT]: In case it's not clear, I am not a windows C++ developer, I've read a decent amount of windows C++ code, so I sort of know what's going on, but I've written less than 5k lines of windows C/C++ in my life.
I would run into similar issues when coding for Apple platforms, for example.
You obviously haven't dealt runtime dependency injection/etc. in Java.
It happens regularly.
> Java has a lot going for it, and I probably will keep using it for some time.
Me, too. And I will always keep an eye on rust, especially since I also use Scala. ;) However the only downside of rust, is that crates.io doesn't has so powerful things like Java has in maven. However comparing Libraries of a 20 year old language vs a "some" year old language is somewhat unfair. What I would like would be Java <-> Rust FFI.
> crates.io doesn't has so powerful things like Java has in maven
Could you elaborate on this? I'm only using maven in a few projects and have only shallow experience with it.
This. 10x.
And, if Rust's type checker could be integrated with an SMT solver to statically verify array/vector indexing (instead of performing bounds checks at runtime, or using unsafe code), that 10x would become 100x.
http://www.haskellforall.com/2015/12/compile-time-memory-saf...
However, I think this is the nuclear option. I have some experience from university where I wrote some Eiffel code, contracts and all that jazz. It often takes some head scratching to figure out the right pre- and postconditions.
I'd actually rather see more safe interfaces for the common cases (like iterators and slices) that are ergonomic to use and may actually carry the proof in their types.
(0) `pos <= str.len()`.
(1) `pos` is actually the beginning of a character - it makes sense to split the string at the position `pos`.
These things are easy to check - there is not even any multiplication involved! - but a conventional type checker won't do. Much of the pain of using dependent types is the result of sticking to unification as the only basis for type-checking.
Obviously.
> Various verification techniques (like SMT solvers) can only prove some usages, but not all.
Turns out this is good enough for most cases. Verifying 80% of your array index manipulations is better than verifying none of it.
My personal experience points to opposite results of what you claim.
Let's see the hard facts rather than conjecture masquerading as such.
(0) Implementing lexical contexts and environments whose variables are identified with de Bruijn indices or levels.
(1) Implementing multidimensional arrays and operations on them (e.g., matrix multiplication).
In both of these cases, a solver for the theory of integer arithmetic can check that I'm using my indices right.
Look, JIT and static compilation are just compilation mechanisms. You can apply them to pretty much any language you want. You can statically compile java[1]. You can JIT Rust. You can compile java with llvm (Azul does it). You can interpret java, rust, C++, etc.
You can have hybrids where you start with an optimized statically compiled form and reoptimize it at runtime.
Don't ever tie current optimization mechanisms to comparisons of languages. If it's really important to gain performance, someone will do it.
For example, JIT of C++ is often not done because it's not worth it compared to automatic profiling and other reoptimization mechanisms. But it can be done :)
If you want to compare languages, compare languages. If you want to compare particular implementations of languages, compare particular implementations of languages. Don't say you are doing one and do the other, because it's confusing, and, well, if it matters enough, someone will come along and make you wrong.
:)
[1] If you are willing to guarantee no class loading. Otherwise, you can statically compile everything that is loaded or run an interpreter or do what you want to new code at runtime
Counter-examples:
I love Python, but it's slow. People thought performance in Python was important and ... well, here we are years later and no one has made Python performant. PyPy is a splendid display of engineering and optimization, but it doesn't make Python truly performant on real world applications versus C/C++. It's more of a stop-gap to delay the inevitable (which is, if you find yourself needing performance, you'll eventually have to bite the bullet and re-write in C++).
The same goes for JavaScript. Massive companies have brought their engineering might down upon JavaScript to build what are perhaps the most impressive optimizing compilers of our modern age. Yet JavaScript is still slow, and now what are we doing? Turning to asm.js and WebAssembly...
So while it's true that any language could be performant, given a sufficiently adept compiler, the real question is whether such a compiler is actually practical. And more importantly, should we pour the world's engineering resources into building such a compiler, when we could just build a better language instead?
(0) Type-checking C++ templates requires expanding them. However, nothing forces a C++ implementor to translate the individual template instantiations to machine code (or whatever target language is used). A C++ implementor could use a strategy similar to what is used in Java and C#, and re-instantiate every template on demand at runtime. Of course, nobody does this, because it's bad for the implementor (more work, because instantiating templates is more complex than instantiating generics, so better not do it at runtime if it's already been done at compile time), bad for the user (worse runtime performance), and good for noone (except perhaps C++ detractors).
(1) A Python implementor could use whole-program analysis to assign variables and expressions more useful static types than `AnyObject` - similar to what STALIN does for Scheme. But, again, this is bad for the implementor (more work), bad for the user (less interactivity and instant gratification, due to the constant rechecking of the whole program every time a change is made), and good for noone (except perhaps Python detractors).
Now, there exist language designs that are less biased towards a fixed implementation strategy. For example, Common Lisp, Standard ML and Haskell. But these languages are also markedly less popular, which perhaps suggests that programmers usually prefer languages that have a concrete story about what use cases their design optimizes for.
Are you sure? Expanding templates can affect the parsing of subsequent code, as this example illustrates: http://yosefk.com/c++fqa/web-vs-c++.html#misfeature-3 You pretty much have to expand them at compile time.
(This sort of complexity illustrates why I prefer generics to templates, incidentally.)
(0) Expand the templates at compile-time, in order to type-check the code.
(1) Don't generate target language code for each specific instantiation, though.
(2) Re-expand the templates (or some representation of them) at runtime.
It's a very silly implementation strategy, of course. But I don't see why it's fundamentally impossible to do this - it's just undesirable.
And, yes, I agree about generics being better.
Well, to be fair, it says this at the top:
This post compares Rust-1.8.0 nightly to OpenJDK-1.8.0_60
I think it's pretty clear it's comparing particular implementations of the languages.
> ... if it matters enough, someone will come along and make you wrong.
I'll be gladly proven wrong if someone comes around and speeds up my JVM. :-D
> Both Rust and Java keep their generics to compile time.
I thought Rust generics are also available at runtime so they are different from Java.
When used as generic constraints they're statically dispatched which might mean better performances, but I believe the JVM is pretty good at devirtualisation so YMMV…
The only advantage I can think of is probably a lack of surprise when trying to use reflection and discovering your generic types are missing (but that's because there is no reflection in rust)
Why is that exactly? I personally don't like Java based GUIs. They are rarely integrated well with the base system. Qt comes closer to it.
> there are plans to integrate basic Go and Rust support.
https://www.kdevelop.org/news/first-beta-release-kdevelop-50...
Sometimes, when Apple changes up the theme, you notice it's not native because it still uses the old theme. But then eventually they update and it goes back to looking native. Or at least native enough that it looks good, which is ultimately what matters.
For example, you could use the `Read` trait as a type:
fn some_func(a: Box<Read>) { }
Why does type erasure mean they aren't true generics?
enum Foo { A, B }
impl Foo::A { fn method_on_a(&self) {} }