Now everyone can know the joys and horrors of Bundler! ;) I kid. This announcement is very exciting for people tinkering with Rust like myself.
I really like Go, but the lack of a solid package management solution that I like using is a downer. Before you rage-comment: I know how Go packages work. I know you think they're better than anything that's ever been invented. I know there are solutions out there for some portions of what I want. But nothing has been created that really works for me (yet). So, to see this development in another one of my "tinker with it but not build a ton of production quality code just yet" languages is exciting!
Handling packages in Go is always something that stops me from going any further when I look at it. Every time I realize I won't be able to properly specify dependencies with versions or pin them (like what Bundler does) it drives me away screaming. It's only the last few years dependency hell has been resolved in other environments (like Ruby and Node, to a lesser and sometimes weirder extent Python), I don't really want to go back in time any more.
> I really like Go, but the lack of a solid package management solution that I like using is a downer. Before you rage-comment: I know how Go packages work. I know you think they're better than anything that's ever been invented. I know there are solutions out there for some portions of what I want. But nothing has been created that really works for me (yet).
What is it that you do want in a Go "package manager", then?
You say that you know how Go packages work, so I'm assuming it's not one of the typical misunderstandings of newcomers from the Python/Ruby/Node.js world (all 1.x code is forwards-compatible with no modifications, static linking means makes specifying versions of packages less relevant, the package/filesystem layout parallel means that vendoring project-specific forks of packages is relatively straightforward once you know how, etc.)
I put "package manager" in scare quotation marks because one of the design goals of Go is essentially to render most of the functionality of such package managers irrelevant.
I say this as someone who has been writing Go for work on a daily basis for over a year and half: while Go's package system isn't perfect, it's pretty damn good, and I haven't felt the need for a package manager at all ever since I learned the way things worked.
Coming from Ruby, when I last looked at Go about 5 months ago, I was dismayed at the package management state. My specific concern was around version pinning. I'll be excited to try out Cargo when it launches.
Yehuda's taking on another major software project before Rails.app [0] / Tokaido [1] is released? It's been 22 months since it raised twice its initial goal.
@molecule Fair question. Tokaido ended up taking far longer than I expected (a big, huge mea culpa for sure). TL;DR: At long last, I plan to ship Tokaido, along with a website, documentation and automation at RailsConf this year. That wouldn't be the first time I said such a thing, but the feature set is actually done (and working on many test machines).
I dedicated a bunch of medium-time months at the beginning of the project to getting the initial set of functionality done:
* Figuring out how to statically build Ruby, which has required non-trivial updates with every version of Ruby, and a bunch of work to get some of those fixes upstream. Many of the projects that bundle Sass or Compass in a pretty GUI are making use of this initial work.
* Building a number of OSS libraries (https://github.com/tokaido) that enabled an application-isolated workflow like Pow with many fewer failure modes.
* Integration with popular tools that people use in development (redis-server and Postgres.app)
This process took longer than I expected (a year, rather than more like six months), and at the end of it, I had run out of work-time time to devote to the project. I turned my attention to nurturing a small community of people who could make Tokaido an open-source project that could be community maintained once we ship.
Andrés Robalino, in particular, helped me squash a number of important bugs that I was having trouble with (including a bug that was triggering occasional 100% CPU usage on some machines), and has cleaned up the process of building static Ruby and added a bunch of polish to the UI.
Tokaido has definitely not been my finest, quickest open-source turnaround, and it's fair for people who don't like me to use it as an example of my failures. That said, I think people who follow me know that I have committed my heart and soul to many more projects than Tokaido, many of which have large communities of people who love them.
Not everybody needs to love my projects or my style. I should have shipped Tokaido earlier, and for that I am sorry. That said, I am committed to finishing the job with Tokaido, and believe that the other major projects I have worked on speak for themselves.
Totally agree. At Snowplow, we have had far more problems supporting user-deployments of two in-theory simple Bundler-wrapped Ruby CLI apps than with deploying _the entire rest of our stack_. The Ruby packaging, deployment and environment ecosystem is an absolute mess - we are going to move these two apps to JRuby-Warbler, which is the only sane take on application packaging in the whole Ruby ecosystem. It's a real shame that Mozilla couldn't get people from npm or Lein, heck even SBT, involved.
I am very skeptical about this. Every language which needs a "package manager" tends to make building standalone applications painful.
I do think C++ is in dire need of being replaced, it is unsafe at any speed and full of legacy cruft. Unfortunately D jumped on the GC train and had other serious issues as well, allowing C++ to survive that attempt without a scratch.
Rust finally did the right thing, aiming for the same zero overhead/you only pay for what you use design which made C++ such a success.
However, C++ is a platform agnostic language, while Rust thus far has only supported Linux as a first class platform. I find the attitude of the Rust devs ("we will improve Windows support once the language is stable") deeply misguided. It meant that they largely missed out on feedback from Windows developers during the development of the language. "Windows developers" also means all the AAA PC(+console) game developers (the most diehard C++ users). Linux still is not a relevant platform there.
And the Rust developers seem to continue to go down that rabbit hole by enlisting Ruby developers to develop a "package manager". As a Windows guy the very word makes me cringe. How is that thing going to integrate with Visual Studio and other Windows specific concerns?
Ruby only really works on Linux, first advice you get as a Windows guy wanting to learn Ruby is "Install Linux, if you try to do Ruby development on Windows you are in for a world of pain". I do not trust any Ruby developer to write portable software, they are married to the GNU/Linux ecosystem. Would you expect Microsoft guys to develop something which actually works well on Linux?
Also remember that C++ does not have a "package manager". Some of the most complex and massive applications in the world are written in C++, yet you do not hear many C++ developers crying "When will we finally get a package manager?". It is not even on the agenda. C does not have one either.
"Package managers" are a Linux-ism, they deliver a certain UX you may or may not like (personally I hate it with passion), but they should not be part of a platform agnostic programming language. A package manager may belong to a Linux development environment for Rust, but the language itself and its library handling should be completely independent of it. Rust libraries should work just like C++ libraries so that they do integrate well with other development environments.
I see Rust becoming a new OCaml, utterly Linux-centric and thus leaving C++ as the sole competitor in the maximal performance + high-level abstractions + platform agnostic category.
For the sake of games no longer crashing randomly because of memory corruption bugs: change course now.
> Every language which needs a "package manager" tends to make building standalone applications painful.
Huh? Python has a (sort of) package manager and you can still make a standalone application by bundling every dependency. You are very certainly mistaking the OS-level package manager (used primarily for installing applications) from the language-level package manager (used primarily for building applications). Once you have built a standalone binary, the job of the language-level package manager is done.
> However, C++ is a platform agnostic language, while Rust thus far has only supported Linux as a first class platform. I find the attitude of the Rust devs ("we will improve Windows support once the language is stable") deeply misguided. It meant that they largely missed out on feedback from Windows developers during the development of the language. "Windows developers" also means all the AAA PC(+console) game developers (the most diehard C++ users). Linux still is not a relevant platform there.
I regularly use Rust (nightly) in Windows. Windows support is problematic since it differs from every other major platform, but it did not have a serious problem that seriously discourages the Windows platform. (Not to mention that I regularly build a standalone binary for Windows!) I admit it is not in the best state, but it should be improved and is being improved.
> And the Rust developers seem to continue to go down that rabbit hole by enlisting Ruby developers to develop a "package manager". As a Windows guy the very word makes me cringe. How is that thing going to integrate with Visual Studio and other Windows specific concerns? Ruby only really works on Linux, first advice you get as a Windows guy wanting to learn Ruby is "Install Linux, if you try to do Ruby development on Windows you are in for a world of pain". I do not trust any Ruby developer to write portable software, they are married to the GNU/Linux ecosystem. Would you expect Microsoft guys to develop something which actually works well on Linux?
As a multiplatform guy the introduction of package manager actually marks the divorce with the strong Unix assumption, since Rust has actively avoided the platform-dependent tools so much that it now does not require the C compiler at all (!) and the only remaining platform-dependent tool was the Make. This is now about to change.
> Also remember that C++ does not have a "package manager". Some of the most complex and massive applications in the world are written in C++, yet you do not hear many C++ developers crying "When will we finally get a package manager?". It is not even on the agenda. C does not have one either.
That's why SQLite ships with an amalgamated source code, a sort of unfortunate thing. Dependency problem is so bad in C/C++ that most developers gave up and grew the half-baked solutions, which have another share of problems.
Windows is a first-class platform for Rust. Windows is Firefox's most important platform, and Servo needs to demonstrate that opportunities for optimization that could be relevant to Gecko are applicable to browsers running on the Windows platform.
If Rust seems like it's less well-integrated into Windows than it is into Linux and OSX, it's because none of the Windows developers who keep complaining about Windows support seem to be willing to step up to the plate. I've made this same offer several times to self-proclaimed Windows devs on HN: if you want Rust to get better on Windows sooner, make it happen sooner. Until then, the Rust devteam will spend their resources finalizing the language itself, while the Linux and OSX and FreeBSD and Android/ARM contributors continue to provide better integration with their chosen platforms.
This is not hostility. Please help us. We know that Windows is important. We need experts.
> However, C++ is a platform agnostic language, while Rust thus far has only supported Linux as a first class platform. I find the attitude of the Rust devs ("we will improve Windows support once the language is stable") deeply misguided. It meant that they largely missed out on feedback from Windows developers during the development of the language. "Windows developers" also means all the AAA PC(+console) game developers (the most diehard C++ users). Linux still is not a relevant platform there.
This is not correct. Mac OSX is very much a first class platform supported as well as (or better than) Linux, and the "wait until the language is stable" is not the attitude that is being taken: firstly, every single changeset is required to pass tests on Windows to be merged (i.e. Windows is being regarded as first class too, even if there's a few lacking areas), and secondly, people are working on it, although slowly, such as the removal of the dependency on GCC's C++ runtime.
> A package manager may belong to a Linux development environment for Rust, but the language itself and its library handling should be completely independent of it. Rust libraries should work just like C++ libraries so that they do integrate well with other development environments.
I don't see this changing particularly. AIUI, cargo is more designed to be a (pluggable) dependency manager, exposing as much of its internals as possible (via CLIs, i.e. callable binaries) so that external tooling can hook into it in a sane way.
> Also remember that C++ does not have a "package manager". Some of the most complex and massive applications in the world are written in C++, yet you do not hear many C++ developers crying "When will we finally get a package manager?". It is not even on the agenda. C does not have one either.
So? C also doesn't have a module system. It doesn't mean it's not a desirable feature.
> "Package managers" are a Linux-ism, they deliver a certain UX you may or may not like (personally I hate it with passion)
Package managers and UX are orthogonal concepts. You're free to not like Linux package managers, but the development of nuget in Visual Studio shows that not everybody embraces the installer download "package management" with enthusiasm. You'll note that most modern (and not so modern) programming languages (Java, Python, Perl, Ruby, Haskell, PHP...) have found the need for one.
> I am very skeptical about this. Every language which needs a "package manager" tends to make building standalone applications painful.
Rust does not need a package manager. We've used it for a long time without one. If the package-manager-free workflow with manual installation (or through an IDE, etc.) is to your liking, use it!
> However, C++ is a platform agnostic language, while Rust thus far has only supported Linux as a first class platform.
Totally false. I'm the earliest developer still full-time on the Rust language (4+ years) and I was exclusively using Mac OS X from the beginning. If you look at Servo, Mac is actually better supported than Linux at the moment.
Graydon was adamant that Windows must be supported from the start, and we have not changed that.
> I find the attitude of the Rust devs ("we will improve Windows support once the language is stable") deeply misguided. It meant that they largely missed out on feedback from Windows developers during the development of the language.
What feedback is that? Most of the language-level concerns are platform-independent, except for COM, etc (which we are familiar with).
Furthermore, we have Windows support, and it's not that far behind the other platforms. Later on in your comments, you talk about a binary installer. That's not something we have on any platform yet.
> And the Rust developers seem to continue to go down that rabbit hole by enlisting Ruby developers to develop a "package manager". As a Windows guy the very word makes me cringe. How is that thing going to integrate with Visual Studio and other Windows specific concerns?
You don't need to use it if you're using Visual Studio. If you like your tools, keep them! That's Rust's attitude.
> I do not trust any Ruby developer to write portable software, they are married to the GNU/Linux ecosystem. Would you expect Microsoft guys to develop something which actually works well on Linux?
Of course I would, if they were competent developers.
> Also remember that C++ does not have a "package manager". Some of the most complex and massive applications in the world are written in C++, yet you do not hear many C++ developers crying "When will we finally get a package manager?". It is not even on the agenda. C does not have one either.
There are tons of popular C++ package managers: Homebrew and apt-get, to name a couple.
> A package manager may belong to a Linux development environment for Rust, but the language itself and its library handling should be completely independent of it.
That is precisely what Rust does.
> Rust libraries should work just like C++ libraries so that they do integrate well with other development environments.
That is also precisely what Rust does.
> I see Rust becoming a new OCaml, utterly Linux-centric and thus leaving C++ as the sole competitor in the maximal performance + high-level abstractions + platform agnostic category.
This is really silly and hyperbolic, and somewhat insulting to those of us who have spent a lot of time making sure the design works well on Windows. Like I said, I've been working full-time on this project longer than anyone else and I exclusively use a Mac.
Mozilla is not going to invest in a language that won't work on Windows, for obvious reasons. We have a lot of Windows developers here too, you know.
First-class support for Windows is evident everywhere in the design, from the use of libuv instead of libevent for the green threading to the lack of exposure of `select` or `fork` due to that not performing well on Windows.
> For the sake of games no longer crashing randomly because of memory corruption bugs: change course now.
To what? Abandoning the package manager? That'd be alienating a large segment of users who want a tool to create and share libraries, and deploy binaries onto servers for the sake of unhappy Windows developers who dislike that workflow. Instead I think we should do what we're doing now: invest in the package manager, but allow the tools and libraries to be totally independent of it, so that you can use Visual Studio or whatever you'd like with Rust.
A large part of the linux|mac centering of the current development is that the lack of contributions from Windows developers. It's an open source project, and while we make sure it works on windows, more feedback and contribution from "Windows natives" would be fantastic.
I have never programmed on Windows, and wouldn't be able to gain the experience needed in time for a Rust 1.0 launch. Join the mailing list and IRC channel and offer feedback, if not patches!
Firefox, and Mozilla, the biggest users of rust are windows developers, and multiplatform C++ developers.
C++ has no packages, and making multiplatform code in C++ is hard. Very little code is reusable, especially outside of the platform in which it came in.
"For the sake of games no longer crashing randomly because of memory corruption bugs: change course now." You realise, this is one of the main design goals of rust?
Lots of people in the ruby, python, and node worlds use package managers on windows. Besides, windows is C#, and moving heavily towards tools such as node.js, and other multiplatform tools.
I think the fact that Windows devs are getting itchy to have full support is a good sign. It means that the language is becoming popular.
That said, I'd like to point out that the same thing happens all the time with languages developed in Windows land. I happen to really like F#, but Linux support for the language compared to Windows support has historically been relatively poor. It was only the heroic volunteer efforts of the mono devs that brought a respectable degree of support for F# to Linux.
And like mono, Rust is an open source project. Consider pitching in and helping build the Rust you want if you know how, or else consider learning how to do so if you don't.
I do happen to agree that package manager support should probably not be a priority at this stage. I think all available manpower and funds should be used to get the language to 1.0 as fast as possible. People won't put up with massive amounts of breaking changes forever.
> I do think C++ is in dire need of being replaced, it is unsafe at any speed and full of legacy cruft.
Lack of decent package management is part of that cruft. As someone else pointed out, you're definitely confusing this with system package management. A good package manager for Rust could make it much much easier to have good Windows support, because it could Windows-specific compilation and packaging problems in one place, rather than relying on each individual library author to solve them. There is no reason it couldn't interact nicely with Visual Studio, unless that is not something Visual Studio is interested in doing.
This could be a really good thing for your apparent interest in Rust, but you're looking at it through the narrow lens of your past frustrations, rather than thinking about and advocating for ways it could alleviate them.
I hate package managers too, but the worst I've ever seen were proprietary "solutions" in the games industry which did do awful tricks to make VS play ball.
It is no exaggeration to say people would avoid updating packages in their projects (i.e. the whole point of using a package manager was nullified) since they knew they would lose days or weeks merely getting back to where they were.
The problems with package management seem to be exponentially proportional to how clever the person implementing the system thought they were. Any more than a declarative list of dependencies per package that can be fully evaluated to a programmer readable dependency tree prior to a single package update and you've created a self sustaining beast that will consume more of your time than developing the actual product.
I personally have much the same reaction to language-specific package managers as you do. But my question is a little different: how is the Rust package manager going to interact with the Linux distribution's package manager?
If the answer starts with "Well, you build your own installation of the language..." (Hi, Haskell!) I am afraid I may start to cry uncontrollably.
> Also remember that C++ does not have a "package manager"
Many large, truly cross-platform, continuously-integrated C++ applications do - out of necessity - have an (ad-hoc, underspecified) approximation of a package manager. CMake-based projects come to mind immediately with the "build the world" approach using CMake external projects. GYP for chromium is the same.
How do you deal with dependencies in Windows-land? Do they wind up all getting embedded in the Visual Studio project? How do you deal with projects with different build systems? Or are Visual studio projects basically the package management in the ecosystem?
On linux I've basically wound up depending on the distribution packages, but this varies from distro to distro. The other option is embedding a build of all dependencies into the project, but this is slow, painful, and prone to error. Having a neutral package manager for C and C++ would be amazingly useful for this (though it would have actually be used. We use some python packages but some of them don't work when installed via pip so it's back to depending on the distro package).
I'm all for Rust package system. But Rust isn't even stable or sort of stable yet? What is the point of working on a package manager when they don't even know what vectors or the extern crate/mod system will look like in 3 months?
A package manager will be a forcing function for stability. The Rust team wants to ship Rust 1.0 sometime late this year (I think? Correct me if I'm wrong)
Building a package manager is not a one-month project, and getting it done in parallel with the stabilization of the core means that there will be a full-stack system that people can use and help iterate on as things stabilize, and that will be ready to go once Rust itself is ready for mass consumption.
We do know what those two things will look like. The design is fairly ironed out at the moment, just not fully implemented. For vectors (dynamically-sized types), there's even a PLT Redex model to verify that the design holds together…
Package managers make everything way more complex than they are supposed to be. I see package managers as a component of an operating system. The proper way of packaging software source is having it contained in a directory tree with one, public build script (a Makefile, a shell script...) at its root. One or many build artefacts are generated, which at user's disposal.
With language specific build systems, this process gets more complicated. They disallow the user to arrange their source tree the way they want, customise the build process, and make the whole thing as convenient as running make, or e.g. ./build.sh. Provided a conventional compiler command (e.g. the cc interface), it is easy to create a Makefile that exploits it.
I have had a lot of confusion with Go compiler, when I tried to build and use a checked-in, external package. Python's pip is quite complicated. Cabal, can easily be replaced with a bunch of Makefiles. Binary packages can be supplied as [tar/zip] archives, and users would eventually package them for their OS. Also, most these package managers are exploited for installing applications, which is problematic.
I have not used Rust, but I will try it out. The package manager, though, is not just a bad idea, but also an inconvenience.
I don't know much about Rust, but AFAIK it's mostly static linking like Go. So 2 Rust applications won't have to share anything, so developments packages do not have to be converted into deb packages. Unlike ruby or python packages.
a) no to cargo exec
b) If you have a better solution for bundler, please open an issue and suggest it.
c) There are few simple solutions to avoid `bundle exec`, which is mostly there to make things easier when getting started. I'm sure you spent a few moments to get to know your tools, so you must already be aware of these.
I have included my phone number on virtually every piece of public email (to mailing lists) I have ever written. I have found that people do not abuse it.
For Rust, this is good. I'm sure this is very good for Rust.
Take the rest of my message with a grain of salt. It's 6:30am and I'm working through my first cup of coffee still. I'm not intentionally trying to be a grumpy old man.
For the rest of us, I'm concerned that yet-another-package-manager (YAPM? Yap-meager?) will just continue to fracture the library ecosystem.
Why can't something like APT handle it? NPM doesn't work the same as PIP, doesn't work the same as Nuget, doesn't work the same as Gem, other than the most basic install functionality. Packaging libraries for distribution is different for each, and if you have a problem, tearing into the system to figure out where the failure occurred is different for each.
Maybe it's because, through hard-fought experience, I've finally learned how to manage .NET dependencies without too much headache. Don't ever even think of trying to use the GAC. Don't let your developers install the dependencies on their own. Just make a directory full of DLLs in your project root and use relative paths to load them. It's the only way I've been able to get developers up and running with a project in Visual Studio as soon as they clone the repository. Even Nuget gave me issues (though granted, I gave up on it so fast I don't remember what they were, other than telling the jr. dev to just dump the DLL in the libs directory already and get to work on the issue list).
Attempting to isolate your library ecosystem from the file system feels like it encourages "reinventing the wheel" at the language level for libraries that will mostly be the same across platforms. Do we really need to figure out how to do database connections in yet another language? Why are there 15 different syntaxes for positional arguments in strings?
I'm just getting a little... weary... of starting to learn a new programming and spending the next few hours just figuring out that they've renamed printf to writeln and %s to {0} for no good reason, or that there are no database connectors yet, or if there are they only implement a strange subset of databases. It almost feels like language devs have gone out of their way to be superficially different from everyone else, without being substantially different.
Given that most languages have support for some kind of foreign function interface, especially with the C ABI, it seems like we have the tools available to us to start building cross-platform libraries and distribute them regardless of consuming language.
I've been wanting to dabble in Rust for a little while, but damn, yet another package manager to learn, yet another notion of what a library ecosystem should look like, just doesn't excite me right now. It's time I will have to spend to get in the door, and I am not even sure right now if I will want to stick around.
But I suppose with an initiative like Rust, isolation is probably the correct ideology, considering it's about security/performance before productivity.
Anyway, complaining done. No hate for Rust-team's work. Just kind of yearning for a probably unobtainable utopian future :/
In the end, Rust will always just produce the same types of binary artifacts that C++ does. Currently people use Make and friends to build Rust, and that will always remain possible. Cargo is just an attempt to simplify the versioning, updating, and dependency-resolution stories in a platform-independent way.
[+] [-] jeremymcanally|12 years ago|reply
I really like Go, but the lack of a solid package management solution that I like using is a downer. Before you rage-comment: I know how Go packages work. I know you think they're better than anything that's ever been invented. I know there are solutions out there for some portions of what I want. But nothing has been created that really works for me (yet). So, to see this development in another one of my "tinker with it but not build a ton of production quality code just yet" languages is exciting!
[+] [-] stormbrew|12 years ago|reply
[+] [-] chimeracoder|12 years ago|reply
What is it that you do want in a Go "package manager", then?
You say that you know how Go packages work, so I'm assuming it's not one of the typical misunderstandings of newcomers from the Python/Ruby/Node.js world (all 1.x code is forwards-compatible with no modifications, static linking means makes specifying versions of packages less relevant, the package/filesystem layout parallel means that vendoring project-specific forks of packages is relatively straightforward once you know how, etc.)
I put "package manager" in scare quotation marks because one of the design goals of Go is essentially to render most of the functionality of such package managers irrelevant.
I say this as someone who has been writing Go for work on a daily basis for over a year and half: while Go's package system isn't perfect, it's pretty damn good, and I haven't felt the need for a package manager at all ever since I learned the way things worked.
[+] [-] Argorak|12 years ago|reply
https://github.com/pote/gpm
[+] [-] cryptolect|12 years ago|reply
[+] [-] Matrixik|12 years ago|reply
[+] [-] molecule|12 years ago|reply
[0] https://www.kickstarter.com/projects/1397300529/railsapp
[1] https://github.com/tokaido/tokaidoapp
[+] [-] wycats|12 years ago|reply
I dedicated a bunch of medium-time months at the beginning of the project to getting the initial set of functionality done:
* Figuring out how to statically build Ruby, which has required non-trivial updates with every version of Ruby, and a bunch of work to get some of those fixes upstream. Many of the projects that bundle Sass or Compass in a pretty GUI are making use of this initial work.
* Building a number of OSS libraries (https://github.com/tokaido) that enabled an application-isolated workflow like Pow with many fewer failure modes.
* Integration with popular tools that people use in development (redis-server and Postgres.app)
This process took longer than I expected (a year, rather than more like six months), and at the end of it, I had run out of work-time time to devote to the project. I turned my attention to nurturing a small community of people who could make Tokaido an open-source project that could be community maintained once we ship.
Andrés Robalino, in particular, helped me squash a number of important bugs that I was having trouble with (including a bug that was triggering occasional 100% CPU usage on some machines), and has cleaned up the process of building static Ruby and added a bunch of polish to the UI.
Tokaido has definitely not been my finest, quickest open-source turnaround, and it's fair for people who don't like me to use it as an example of my failures. That said, I think people who follow me know that I have committed my heart and soul to many more projects than Tokaido, many of which have large communities of people who love them.
Not everybody needs to love my projects or my style. I should have shipped Tokaido earlier, and for that I am sorry. That said, I am committed to finishing the job with Tokaido, and believe that the other major projects I have worked on speak for themselves.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] defen|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
I am very emphatically _not_ saying that you're wrong, but without enumerating what your problems are, you can't get them solved.
[+] [-] alexatkeplar|12 years ago|reply
If the Rust community ends up with blog posts and comments like this, I will be sad: http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the...
[+] [-] copx|12 years ago|reply
I do think C++ is in dire need of being replaced, it is unsafe at any speed and full of legacy cruft. Unfortunately D jumped on the GC train and had other serious issues as well, allowing C++ to survive that attempt without a scratch.
Rust finally did the right thing, aiming for the same zero overhead/you only pay for what you use design which made C++ such a success.
However, C++ is a platform agnostic language, while Rust thus far has only supported Linux as a first class platform. I find the attitude of the Rust devs ("we will improve Windows support once the language is stable") deeply misguided. It meant that they largely missed out on feedback from Windows developers during the development of the language. "Windows developers" also means all the AAA PC(+console) game developers (the most diehard C++ users). Linux still is not a relevant platform there.
And the Rust developers seem to continue to go down that rabbit hole by enlisting Ruby developers to develop a "package manager". As a Windows guy the very word makes me cringe. How is that thing going to integrate with Visual Studio and other Windows specific concerns? Ruby only really works on Linux, first advice you get as a Windows guy wanting to learn Ruby is "Install Linux, if you try to do Ruby development on Windows you are in for a world of pain". I do not trust any Ruby developer to write portable software, they are married to the GNU/Linux ecosystem. Would you expect Microsoft guys to develop something which actually works well on Linux?
Also remember that C++ does not have a "package manager". Some of the most complex and massive applications in the world are written in C++, yet you do not hear many C++ developers crying "When will we finally get a package manager?". It is not even on the agenda. C does not have one either.
"Package managers" are a Linux-ism, they deliver a certain UX you may or may not like (personally I hate it with passion), but they should not be part of a platform agnostic programming language. A package manager may belong to a Linux development environment for Rust, but the language itself and its library handling should be completely independent of it. Rust libraries should work just like C++ libraries so that they do integrate well with other development environments.
I see Rust becoming a new OCaml, utterly Linux-centric and thus leaving C++ as the sole competitor in the maximal performance + high-level abstractions + platform agnostic category.
For the sake of games no longer crashing randomly because of memory corruption bugs: change course now.
[+] [-] lifthrasiir|12 years ago|reply
Huh? Python has a (sort of) package manager and you can still make a standalone application by bundling every dependency. You are very certainly mistaking the OS-level package manager (used primarily for installing applications) from the language-level package manager (used primarily for building applications). Once you have built a standalone binary, the job of the language-level package manager is done.
> However, C++ is a platform agnostic language, while Rust thus far has only supported Linux as a first class platform. I find the attitude of the Rust devs ("we will improve Windows support once the language is stable") deeply misguided. It meant that they largely missed out on feedback from Windows developers during the development of the language. "Windows developers" also means all the AAA PC(+console) game developers (the most diehard C++ users). Linux still is not a relevant platform there.
I regularly use Rust (nightly) in Windows. Windows support is problematic since it differs from every other major platform, but it did not have a serious problem that seriously discourages the Windows platform. (Not to mention that I regularly build a standalone binary for Windows!) I admit it is not in the best state, but it should be improved and is being improved.
> And the Rust developers seem to continue to go down that rabbit hole by enlisting Ruby developers to develop a "package manager". As a Windows guy the very word makes me cringe. How is that thing going to integrate with Visual Studio and other Windows specific concerns? Ruby only really works on Linux, first advice you get as a Windows guy wanting to learn Ruby is "Install Linux, if you try to do Ruby development on Windows you are in for a world of pain". I do not trust any Ruby developer to write portable software, they are married to the GNU/Linux ecosystem. Would you expect Microsoft guys to develop something which actually works well on Linux?
As a multiplatform guy the introduction of package manager actually marks the divorce with the strong Unix assumption, since Rust has actively avoided the platform-dependent tools so much that it now does not require the C compiler at all (!) and the only remaining platform-dependent tool was the Make. This is now about to change.
> Also remember that C++ does not have a "package manager". Some of the most complex and massive applications in the world are written in C++, yet you do not hear many C++ developers crying "When will we finally get a package manager?". It is not even on the agenda. C does not have one either.
That's why SQLite ships with an amalgamated source code, a sort of unfortunate thing. Dependency problem is so bad in C/C++ that most developers gave up and grew the half-baked solutions, which have another share of problems.
[+] [-] kibwen|12 years ago|reply
Windows is a first-class platform for Rust. Windows is Firefox's most important platform, and Servo needs to demonstrate that opportunities for optimization that could be relevant to Gecko are applicable to browsers running on the Windows platform.
If Rust seems like it's less well-integrated into Windows than it is into Linux and OSX, it's because none of the Windows developers who keep complaining about Windows support seem to be willing to step up to the plate. I've made this same offer several times to self-proclaimed Windows devs on HN: if you want Rust to get better on Windows sooner, make it happen sooner. Until then, the Rust devteam will spend their resources finalizing the language itself, while the Linux and OSX and FreeBSD and Android/ARM contributors continue to provide better integration with their chosen platforms.
This is not hostility. Please help us. We know that Windows is important. We need experts.
[+] [-] dbaupp|12 years ago|reply
This is not correct. Mac OSX is very much a first class platform supported as well as (or better than) Linux, and the "wait until the language is stable" is not the attitude that is being taken: firstly, every single changeset is required to pass tests on Windows to be merged (i.e. Windows is being regarded as first class too, even if there's a few lacking areas), and secondly, people are working on it, although slowly, such as the removal of the dependency on GCC's C++ runtime.
> A package manager may belong to a Linux development environment for Rust, but the language itself and its library handling should be completely independent of it. Rust libraries should work just like C++ libraries so that they do integrate well with other development environments.
I don't see this changing particularly. AIUI, cargo is more designed to be a (pluggable) dependency manager, exposing as much of its internals as possible (via CLIs, i.e. callable binaries) so that external tooling can hook into it in a sane way.
[+] [-] mercurial|12 years ago|reply
So? C also doesn't have a module system. It doesn't mean it's not a desirable feature.
> "Package managers" are a Linux-ism, they deliver a certain UX you may or may not like (personally I hate it with passion)
Package managers and UX are orthogonal concepts. You're free to not like Linux package managers, but the development of nuget in Visual Studio shows that not everybody embraces the installer download "package management" with enthusiasm. You'll note that most modern (and not so modern) programming languages (Java, Python, Perl, Ruby, Haskell, PHP...) have found the need for one.
[+] [-] pcwalton|12 years ago|reply
Rust does not need a package manager. We've used it for a long time without one. If the package-manager-free workflow with manual installation (or through an IDE, etc.) is to your liking, use it!
> However, C++ is a platform agnostic language, while Rust thus far has only supported Linux as a first class platform.
Totally false. I'm the earliest developer still full-time on the Rust language (4+ years) and I was exclusively using Mac OS X from the beginning. If you look at Servo, Mac is actually better supported than Linux at the moment.
Graydon was adamant that Windows must be supported from the start, and we have not changed that.
> I find the attitude of the Rust devs ("we will improve Windows support once the language is stable") deeply misguided. It meant that they largely missed out on feedback from Windows developers during the development of the language.
What feedback is that? Most of the language-level concerns are platform-independent, except for COM, etc (which we are familiar with).
Furthermore, we have Windows support, and it's not that far behind the other platforms. Later on in your comments, you talk about a binary installer. That's not something we have on any platform yet.
> And the Rust developers seem to continue to go down that rabbit hole by enlisting Ruby developers to develop a "package manager". As a Windows guy the very word makes me cringe. How is that thing going to integrate with Visual Studio and other Windows specific concerns?
You don't need to use it if you're using Visual Studio. If you like your tools, keep them! That's Rust's attitude.
> I do not trust any Ruby developer to write portable software, they are married to the GNU/Linux ecosystem. Would you expect Microsoft guys to develop something which actually works well on Linux?
Of course I would, if they were competent developers.
> Also remember that C++ does not have a "package manager". Some of the most complex and massive applications in the world are written in C++, yet you do not hear many C++ developers crying "When will we finally get a package manager?". It is not even on the agenda. C does not have one either.
There are tons of popular C++ package managers: Homebrew and apt-get, to name a couple.
> A package manager may belong to a Linux development environment for Rust, but the language itself and its library handling should be completely independent of it.
That is precisely what Rust does.
> Rust libraries should work just like C++ libraries so that they do integrate well with other development environments.
That is also precisely what Rust does.
> I see Rust becoming a new OCaml, utterly Linux-centric and thus leaving C++ as the sole competitor in the maximal performance + high-level abstractions + platform agnostic category.
This is really silly and hyperbolic, and somewhat insulting to those of us who have spent a lot of time making sure the design works well on Windows. Like I said, I've been working full-time on this project longer than anyone else and I exclusively use a Mac.
Mozilla is not going to invest in a language that won't work on Windows, for obvious reasons. We have a lot of Windows developers here too, you know.
First-class support for Windows is evident everywhere in the design, from the use of libuv instead of libevent for the green threading to the lack of exposure of `select` or `fork` due to that not performing well on Windows.
> For the sake of games no longer crashing randomly because of memory corruption bugs: change course now.
To what? Abandoning the package manager? That'd be alienating a large segment of users who want a tool to create and share libraries, and deploy binaries onto servers for the sake of unhappy Windows developers who dislike that workflow. Instead I think we should do what we're doing now: invest in the package manager, but allow the tools and libraries to be totally independent of it, so that you can use Visual Studio or whatever you'd like with Rust.
[+] [-] factorialboy|12 years ago|reply
I've used Node extensively on Linux but working with Node + Windows (with the NPM package manager) in the last few months has been pretty smooth too.
I fail to understand why you think package managers are a Linux-only phenomenon.
[+] [-] mcpherrinm|12 years ago|reply
I have never programmed on Windows, and wouldn't be able to gain the experience needed in time for a Rust 1.0 launch. Join the mailing list and IRC channel and offer feedback, if not patches!
[+] [-] illumen|12 years ago|reply
Firefox, and Mozilla, the biggest users of rust are windows developers, and multiplatform C++ developers.
C++ has no packages, and making multiplatform code in C++ is hard. Very little code is reusable, especially outside of the platform in which it came in.
"For the sake of games no longer crashing randomly because of memory corruption bugs: change course now." You realise, this is one of the main design goals of rust?
Lots of people in the ruby, python, and node worlds use package managers on windows. Besides, windows is C#, and moving heavily towards tools such as node.js, and other multiplatform tools.
[+] [-] jnbiche|12 years ago|reply
That said, I'd like to point out that the same thing happens all the time with languages developed in Windows land. I happen to really like F#, but Linux support for the language compared to Windows support has historically been relatively poor. It was only the heroic volunteer efforts of the mono devs that brought a respectable degree of support for F# to Linux.
And like mono, Rust is an open source project. Consider pitching in and helping build the Rust you want if you know how, or else consider learning how to do so if you don't.
I do happen to agree that package manager support should probably not be a priority at this stage. I think all available manpower and funds should be used to get the language to 1.0 as fast as possible. People won't put up with massive amounts of breaking changes forever.
[+] [-] sanderjd|12 years ago|reply
Lack of decent package management is part of that cruft. As someone else pointed out, you're definitely confusing this with system package management. A good package manager for Rust could make it much much easier to have good Windows support, because it could Windows-specific compilation and packaging problems in one place, rather than relying on each individual library author to solve them. There is no reason it couldn't interact nicely with Visual Studio, unless that is not something Visual Studio is interested in doing.
This could be a really good thing for your apparent interest in Rust, but you're looking at it through the narrow lens of your past frustrations, rather than thinking about and advocating for ways it could alleviate them.
[+] [-] fidotron|12 years ago|reply
It is no exaggeration to say people would avoid updating packages in their projects (i.e. the whole point of using a package manager was nullified) since they knew they would lose days or weeks merely getting back to where they were.
The problems with package management seem to be exponentially proportional to how clever the person implementing the system thought they were. Any more than a declarative list of dependencies per package that can be fully evaluated to a programmer readable dependency tree prior to a single package update and you've created a self sustaining beast that will consume more of your time than developing the actual product.
[+] [-] SeanDav|12 years ago|reply
[+] [-] mcguire|12 years ago|reply
I personally have much the same reaction to language-specific package managers as you do. But my question is a little different: how is the Rust package manager going to interact with the Linux distribution's package manager?
If the answer starts with "Well, you build your own installation of the language..." (Hi, Haskell!) I am afraid I may start to cry uncontrollably.
[+] [-] ihnorton|12 years ago|reply
Many large, truly cross-platform, continuously-integrated C++ applications do - out of necessity - have an (ad-hoc, underspecified) approximation of a package manager. CMake-based projects come to mind immediately with the "build the world" approach using CMake external projects. GYP for chromium is the same.
[+] [-] rcxdude|12 years ago|reply
On linux I've basically wound up depending on the distribution packages, but this varies from distro to distro. The other option is embedding a build of all dependencies into the project, but this is slow, painful, and prone to error. Having a neutral package manager for C and C++ would be amazingly useful for this (though it would have actually be used. We use some python packages but some of them don't work when installed via pip so it's back to depending on the distro package).
[+] [-] teacup50|12 years ago|reply
[+] [-] chrismorgan|12 years ago|reply
[+] [-] dubcanada|12 years ago|reply
[+] [-] wycats|12 years ago|reply
Building a package manager is not a one-month project, and getting it done in parallel with the stabilization of the core means that there will be a full-stack system that people can use and help iterate on as things stabilize, and that will be ready to go once Rust itself is ready for mass consumption.
[+] [-] pcwalton|12 years ago|reply
[+] [-] gkya|12 years ago|reply
With language specific build systems, this process gets more complicated. They disallow the user to arrange their source tree the way they want, customise the build process, and make the whole thing as convenient as running make, or e.g. ./build.sh. Provided a conventional compiler command (e.g. the cc interface), it is easy to create a Makefile that exploits it.
I have had a lot of confusion with Go compiler, when I tried to build and use a checked-in, external package. Python's pip is quite complicated. Cabal, can easily be replaced with a bunch of Makefiles. Binary packages can be supplied as [tar/zip] archives, and users would eventually package them for their OS. Also, most these package managers are exploited for installing applications, which is problematic.
I have not used Rust, but I will try it out. The package manager, though, is not just a bad idea, but also an inconvenience.
[+] [-] davidgerard|12 years ago|reply
I BEG YOU as a sysadmin: make sure this stuff is compatible with Debian packaging. Please. Please.
[+] [-] byroot|12 years ago|reply
[+] [-] vlucas|12 years ago|reply
[+] [-] carllerche|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] gleenn|12 years ago|reply
I am very excited though honestly, I think he did amazing work with Bundler and is quite smart so I'm sure we'll get something quite useable.
[+] [-] wycats|12 years ago|reply
[+] [-] moron4hire|12 years ago|reply
Take the rest of my message with a grain of salt. It's 6:30am and I'm working through my first cup of coffee still. I'm not intentionally trying to be a grumpy old man.
For the rest of us, I'm concerned that yet-another-package-manager (YAPM? Yap-meager?) will just continue to fracture the library ecosystem.
Why can't something like APT handle it? NPM doesn't work the same as PIP, doesn't work the same as Nuget, doesn't work the same as Gem, other than the most basic install functionality. Packaging libraries for distribution is different for each, and if you have a problem, tearing into the system to figure out where the failure occurred is different for each.
Maybe it's because, through hard-fought experience, I've finally learned how to manage .NET dependencies without too much headache. Don't ever even think of trying to use the GAC. Don't let your developers install the dependencies on their own. Just make a directory full of DLLs in your project root and use relative paths to load them. It's the only way I've been able to get developers up and running with a project in Visual Studio as soon as they clone the repository. Even Nuget gave me issues (though granted, I gave up on it so fast I don't remember what they were, other than telling the jr. dev to just dump the DLL in the libs directory already and get to work on the issue list).
Attempting to isolate your library ecosystem from the file system feels like it encourages "reinventing the wheel" at the language level for libraries that will mostly be the same across platforms. Do we really need to figure out how to do database connections in yet another language? Why are there 15 different syntaxes for positional arguments in strings?
I'm just getting a little... weary... of starting to learn a new programming and spending the next few hours just figuring out that they've renamed printf to writeln and %s to {0} for no good reason, or that there are no database connectors yet, or if there are they only implement a strange subset of databases. It almost feels like language devs have gone out of their way to be superficially different from everyone else, without being substantially different.
Given that most languages have support for some kind of foreign function interface, especially with the C ABI, it seems like we have the tools available to us to start building cross-platform libraries and distribute them regardless of consuming language.
I've been wanting to dabble in Rust for a little while, but damn, yet another package manager to learn, yet another notion of what a library ecosystem should look like, just doesn't excite me right now. It's time I will have to spend to get in the door, and I am not even sure right now if I will want to stick around.
But I suppose with an initiative like Rust, isolation is probably the correct ideology, considering it's about security/performance before productivity.
Anyway, complaining done. No hate for Rust-team's work. Just kind of yearning for a probably unobtainable utopian future :/
[+] [-] kibwen|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] dllthomas|12 years ago|reply