I know people complain about the negativity on HN, so this is a minor nitpick. I have been an on-and-off Linux and UNIX user for a while, but ...
> It's just a standalone executable that will run anywhere without being installed. See the Releases page for pre-built Linux x64 binaries (you need Rust and GTK+ 3.10 or above installed).
Is this not contradictory? Granted, statically linking GTK, 2 or 3, must be ridiculous, but would this still be considered a standalone binary? Granted, I think this might be a variant of libc needs to link to and I am just confused, but I am curious what more knowledgeable people think.
Anyway, I am not dismissing this project though. It sounds very cool. I might give it a shot.
FYI to everyone, racer is also a core component of making Rust hacking on Emacs wonderful, from what I hear. I have yet to be Rustacean.
I read "standalone executable that will run anywhere without being installed" to mean that it's a single executable file that you can move around, it doesn't drop a mess of `.so`s or config files all over your system, and it doesn't need to be in any particular directory to work properly, but NOT that it has no dependencies. As you alluded to, it's nearly impossible to package any non-trivial program (especially anything with a GUI) into a single executable with every dependency statically linked; it would be enormous and unwieldy. So defining "standalone" in terms of the number of new files entering your system (only one) is, IMHO, the more useful definition.
Yeah that's a good way of putting it (I'm the developer). I intend to bundle the GTK libraries in the Mac version when I'm ready to start pre-building it.
I just want to say I am way below your skill level, and I mean no disrepect. I see a lot of standalone (especially playing with Haskell binaries, like pandoc). To use one such example, even Pandoc and company are not even self-contained. The problem is I am not sure where other people in Linux communities draw the line. It is not a really serious thing.
Still I applaud you and other Rustaceans. It is nice to see fully formed GUI apps in Rust, because it makes it look to outsiders that news of stabilizing releases means people are really investing building useful tools.
Well, that, and anywhere realistically means anywhere except the most widely-used operating system in the world. Of course, the dev has absolutely no responsibility to provide that, I just thought it was funny.
Windows is not supported.... Sublime being on all platforms is what made it so huge. There are developers on WIndodws machines, and because they like it!
> There are developers on WIndodws machines, and because they like it!
Looks like there's no obstacles in getting this to run on Windows, GTK and all the other components behind this should run just fine on Windows. It just takes some effort from a Windows dev to set up builds and port whatever minor incompatibilities there are.
The problem with Windows is that non-Windows devs don't find supporting that platform pleasant (to put it mildly) and in my experience, there's a very limited number of Windows devs who actually contribute back to open source projects (this may be a cultural thing coming from a proprietary OS).
Additionally, supporting Windows is a bit painful because there isn't as much free tooling available, e.g. doing automated Windows testing in travis-ci is not an option AFAIK.
> ... there's a very limited number of Windows devs who actually contribute back to open source projects (this may be a cultural thing coming from a proprietary OS).
>
> Additionally, supporting Windows is a bit painful because there isn't as much free tooling available, e.g. doing automated Windows testing in travis-ci is not an option
I believe the second influences the first, plus the project maintainer needs to share the opinion that releasing on Windows is worth the inevitable project changes required to do so. I have seen more than my fair share of pull requests sit idle because "meh, can't be bothered".
Regarding the travis-ci item separately, I am hoping that the work that Vagrant is doing toward being able to provision fresh virtual machine instances on Windows will provide some hope. I do fully appreciate that just provisioning them isn't the whole story, but it's a major hurdle IMHO.
I have a friend who contributes Windows bug fixes to his favorite open source projects. It is a fairly miserable slog for him.
On the other hand, it's probably because of people like me: I really don't like using Windows. Everything is weird and designed for people not like me (not to mention the lack of F/OSS). :-/
Windows isn't supported, but I'm going to guess that adding Windows support wouldn't be impossible. GTK is definitely cross-platform, I don't think neovim has any changes that would make it any harder to build for Windows than vim, and you can get POSIX calls through cygwin or MinGW. Might actually make a good project for anyone wanting to get into rust on Windows.
I think that's debatable... with the currently humongous list of available plugins and it's project-focused interface, I don't think it's much of a stretch at this point to identify it as a lightweight IDE.
The one thing which nags me about Rust is the amount of what seem like weird syntax choices, deliberately different from most popular programming languages.
Why not declare the array type as c_int[2]? And why use semicolons instead of commas?
There are enough such "wtf?" moments that it causes pause and a sense of weirdness while reading Rust code, if the reader is familiar with other C-like languages (which is not to say that Rust itself is C-like).
> if the reader is familiar with other C-like languages
I like to think that Rust wants you to be familiar with C and ML syntax and philosophies before getting comfortable :)
The array type syntax you quoted is a bit like Haskell's `[Char]` syntax with a fixed-length property bolted on. You are right, though, that semicolon looks a bit weird. I guess using commas was not an option because the same syntax on the right hand side of the `=` means `[0, 0]`, i.e. two elements which are 0.
The semicolon decision was equally baffling to a lot of longtime Rust users, as previously , .. was used (or possibly , ...? I honestly can't remember). It was changed because with Rust's new range syntax x..y, there was a conflict in the grammar, at least that's my recollection. Anyway, my experience with stuff like this is that they're horribly confusing for a couple of days and then you forget (as you can see, I already don't remember the old grammar).
> I suggest learning the language before making an attempt to criticize it.
I will learn it.
I like the semantics of Rust, it's a thing which needed to be attempted. What I am suggesting is, that for a language to be popular and accepted in already existing communities, it should have as little syntactic differences from the standards already present in those communities (or more elaborate: that things with similar semantics should have similar syntax). This does not preclude adding both new semantics and new syntax to the language.
In this case, I think the "target audience" for Rust is the crowd already familiar with C and C++, and languages (which are in many cases superior to C and C++) with significant differences such as LISP, Haskell, Erlang are vastly less popular compared to C, C++, C#, Java, JavaScript.
As a counter-example to my claim I recognize Python, which succeeded even if it was radically different and even today has some serious issues (for me, it is its performance and the GIL in CPython). IMO, it succeeded precisely because it was radically different than mainstream languages before it, so it didn't cause "mind crosstalk" issues you get when you encounter something which seems familiar but actually isn't.
Of course, this is inconsequential, it really boils down to arguing about personal taste and preferences. And even if I am right, if the semantics of Rust become popular, I'm sure that a more C-like language will evolve from it (maybe called Crust? :D ). If I am wrong, Rust will live long and prosper as it is.
The syntax itself is such a low hurdle to learning the language it hardly merits complaining about, especially given how drastically the Rust core team has simplified the syntax of the language since its early days. It's not particularly arcane at all if you've ever used C/C++, Ruby, and perhaps any ML-family language (SML, OCaml, Haskell, F#) because Rust cherry-picks the best ideas from each of those languages.
Go is intended to be syntactically very C-like, you may find it more comfortable than Rust in that regard.
And yet the decision to keep <> as the type annotation container was made entirely on the basis of familiarity, despite the fact that most people in the discussion personally preferred the more intuitive and readable but unfamiliar syntax inspiration from D or Scala. They didn't want to alienate the C++ crowd.
There are lots of competing ideologies about syntax in the rust community. Not everybody thinks the same way.
This is sorta kinda true. A long time ago, Rust used `[]`s. Then, at some point, it changed to `<>`s. When the discussion you're referring to came up, it was determined that there wasn't a good enough reason to switch back to `[]`s, as that also introduced other problems, and so wasn't clearly better, and would introduce a lot of churn.
I'd love to know which problems that would have introduced.
Rust's choice of <> ignored the lessons from all the language which made that choice before (Java, C#, C++) and from there, other bad ideas just snowballed on top of it.
The ambiguity had a clearly proposed fix in the issue thread: use () for array access. Just like in scala.
Lots of people were clamoring for the change, and the only unaddressed opposition to it was from those that explicitly wanted to cater to the c++ familiarity.
Using () doesn't work without introducing yet more concepts to the language, to make both
let element: i32 = some_integer_array(i);
let reference: &i32 = &some_integer_array(i);
work. In particular, the second one should give a reference to the element inside the array. I believe Scala doesn't have to deal with this subtlety, since everything is a pointer and generally the precise location of things in memory isn't so important.
This issue is definitely not insurmountable, but it is also definitely not a simple direct replacement.
For the record, dbaupp is on the core team for Rust.
But can you explain it to me? Because his explanation makes sense to me: they can't support that syntax, including getting references, without introducing new concepts. How does what your proposing get around introducing those new concepts?
For the record, Rasmus Lerdorf is on the core team for PHP.
When I said "some_integer_array.at(i)" I certainly didn't mean "rename both things".
Alternatively, having one additional magic kind/trait/... to denote "addressable" would be more manageable than shoe-horning things into the language's syntax which can – at this change – not be fixed anymore.
It still baffles me how people can invent two separate ways to invoke something, () and [], and pretend that's a good idea.
If they used [] for types, they wouldn't have needed to consider such a bad idea.
Now, Rust has to deal with all the random syntax quirks caused by misusing <> for Generics, and it does it pretty badly: As an example, the Foo::<Bar>:: syntax is even worse than Java's Fuz.<Baz>Meth() hack.
Rust would have needed to do `Foo::[Bar]` anyway in order to deal with the ambiguity surrounding the `[]` operator, as explained in a comment upthread (using `()` instead for indexing is not as simple of a substitution as it seems).
In any case, I plan to propose a backwards-compatible extension to Rust's grammar post-1.0 which will make `Foo<Bar>` possible.
Finally, I should note that personally I prefer D's syntax for generics, though I'm ambivalent about the particular sigil used (Rust already uses `!` for a fine purpose).
Because the "&" reference operator goes before types, not after. (Rust makes the same decision as, for example, Go does.) This would lead to ambiguity when combined with postfix array type notation. What does "&c_int[2]" mean: is it "(&c_int)[2]" or "&(c_int[2])"?
This looks pretty cool. It's nice to see there are working GTK3 bindings for Rust.
It'll be interesting to see how many IDE features will be implemented. Currently it seems like a distribution of NeoVim + directory tree + Racer (Rust Autocompletion).
The specific build errors won't show because Cargo hides the output. Try cloning https://github.com/oakes/neovim and running `make libnvim` inside it. The errors you get should make it more clear what dependency is missing.
Thanks for the tip .. looks like I've got something not quite right with my busted install, posting the details here in case any other HN users run up against it:
Scanning dependencies of target stable-busted-deps
[ 93%] Generating usr/lib/luarocks/rocks/stable-busted-deps
PANIC: unprotected error in call to Lua API (.../rust/neovim/.deps/usr/share/lua/5.1/luarocks/fs/lua.lua:3 68: cannot open /Users/fit2rule/.cache/luarocks/https___rocks.moonscript.org/manifest-5.1: No such file or directory)
make[3]: *** [usr/lib/luarocks/rocks/stable-busted-deps] Error
.. seems like a conflict resulting from having lua5.2 installed alongside lua5.1 .. if I figure it out, I'll update.
Update: for reasons I don't understand, the manifest-5.1 file is .zip'ed up .. so:
$ cd /Users/fit2rule/.cache/luarocks/https___rocks.moonscript.org/
$ unzip manifest-5.1.zip
.. fixed the issue, and now libnvim can be built properly. Seems like there are issues with having lua5.2 and lua5.1 side by side as maintained by homebrew on OSX .. so if others run into this issue, there's the facts.
Update2: SolidOak still refuses to build, this time getting further but still reporting build failure:
Compiling glib-sys v0.1.0 (https://github.com/oakes/rgtk#01b611cf)
Build failed, waiting for other jobs to finish...
EDIT: Never mind, I neglected to set PKG_CONFIG_PATH again in a new shell session, as per the README .. I'm now running SolidOak just fine and proceeding to use it to learn me some rust ... So .. leaving all the above for historical purposes ..
> It's just a standalone executable that will run anywhere without being installed. See the Releases page for pre-built Linux x64 binaries (you need Rust and GTK+ 3.10 or above installed).
Is this not contradictory? Granted, statically linking GTK, 2 or 3, must be ridiculous, but would this still be considered a standalone binary? Granted, I think this might be a variant of libc needs to link to and I am just confused, but I am curious what more knowledgeable people think.
Anyway, I am not dismissing this project though. It sounds very cool. I might give it a shot.
FYI to everyone, racer is also a core component of making Rust hacking on Emacs wonderful, from what I hear. I have yet to be Rustacean.
https://github.com/phildawes/racer#emacs-integration