Hacker News Reader

Comment by coffeemug | Hacker News Reader

Hey guys, Slava here. I've been up since yesterday, so I'm going to clock out (though some of the team members are still lurking here). I wanted to thank everyone for great feedback. We're working hard to improve Rethink over the next few months. FYI, you can always hop on IRC (#rethinkdb on freenode) or github tracker (https://github.com/rethinkdb/rethinkdb/issues) with questions and we'll help you out.

View on HN

Thanks for this work, it looks really nice.

I was looking at the github comments about a home brew recipe in which it was stated that aside from a recipe creating a VM, the Mac OS X port would take a bit longer.

Is that a full port from one language to another? Or just an issue of the different flavors of *nix that need dealing with and probably some of the dependency tree issues that come with it?

I'm curious what needs be done to get it building on Mac OS X — perhaps I could assist somehow.

I see a few dependencies that don't immediately sound familiar. You may have better luck with MacPorts, which uses tcl as the language for their portfiles.

Portfiles are just like homebrews recipes, but MacPorts always builds new, including the entire dependency tree ( and dependencies of dependencies etc., etc. ), for which they have thousands of working portfiles. Since those are completed and working, you wouldn't have to worry about those until you wanted to be able to make a binary outside of any package manager.

MacPorts can build binaries now ( new feature ), so you could just as easily instruct it to create a standard Mac OS X installer .pkg which makes sure everything goes in the right place, on the right platform, for the right architecture.

They are an exceedingly friendly and helpful group, I'm sure they would live to see this software in their package/portfiles list.

Seems to me that most of us who have used MacPorts have moved to Homebrew or that could just be the bubble I'm living in. Is there anyone still who still uses MacPorts who could chime in and say why they never made the switch?

Come on, Homebrew doesn't even have gcc.

I am not a Mac user, but a designer using MacBook joined our team last week, and we struggled for half a day with Homebrew. The next day, we installed MacPorts instead, and with just:

$ sudo port install python27 py27-virtualenv gcc46

we were able to proceed and get the whole stack up and running. Not to mention everything from MacPorts is installed nicely under /opt/local.

MacPorts is just way ahead of Homebrew. OTOH, Portage is way ahead of MacPorts ;)

clang is better than gcc, IMO

By what metric?

> clang is better than gcc, IMO

Maybe. Maybe not. But I don't think that's the reason homebrew doesn't have gcc. The OP is pointing out homebrew isn't extensive, and misses some commonly used utilities.

clang either does not build or defectively builds certain things on OS X, for instance Ruby 1.9.3. I had to acquire vanilla GCC for this reason the other day, and was relieved to find it in HomeBrew.

Ruby 1.9.3 working fine here and built with clang. What was defective?

Old-ass versions of Clang would build Ruby and PostgreSQL (client) binaries which would segfault upon execution. Try grabbing the latest XCode/command line tools package and you should be fine. I've been running Ruby 1.9.3 with Clang for quite a while.

brew install rbenv ruby-build; /* rc file shenanigans */; rbenv install 1.9.3-p327; rbenv global 1.9.3-p327; ruby --version

Hahah don't be naive. Use homebrew. Macports has been broken for years.

Interesting. This has not been my experience at all.

I had to fight for days to get MacPorts to install anything properly. It gives me flashbacks to the horrors from 3-4 years ago of compiling open source software on Linux.

Homebrew has been fuzzy kittens in comparison.

I'm a relatively new Mac user and never used MacPorts. When I search brew I get these results:

$ brew search gcc

apple-gcc42 gcc

homebrew/versions/gcc45 homebrew/versions/llvm-gcc28

I'm a bit confused since I thought that these are gcc. Can someone tell me what those results mean? :S

This is the way to go:

    $ brew tap homebrew/dupes
    $ brew install gcc --enable-all-languages

To use your new gcc-4.7.2 when installing new packages just add '--use-gcc' at the end of the command.

based on the sub comments, I'd have to say YMMV.

I've had only troubles with Homebrew. For example recent upgrade, and the system no longer works, I had to manually clean up folders.

MacPorts seems better to me, after years of fink in the past. I need to build for universal (386/x86_64) for testing purposes, so it fits well for me.

I actually rebuild stuff later myself, since I can't really package stuff and require people to have that in /opt/local/bin or anywhere else, but a local folder to the main app.

(I use the same way cygwin on windows, like macports - I love the tools, the stuff, I test a lot of things, but afterall for things I want to distribute I compile myself, and post binaries).

Why would I switch to homebrew? I've been using Macports for 2 years now and I never had any issues with it. It works. Also migrating from Macports to homebrew (in case there's a good reason to do it) it would be a painful experience. I would have to start from scratch right?

Personally, I migrated to homebrew due to the ease of writing packages compared to macports. But I happen to enjoy ruby more than custom DSLs. It's probably a division similar to Chef/Puppet.

Having switched and then switched back, I will agree with you. If you're inclined to write your own package installers, Homebrew is worlds better than MacPorts. But otherwise, MacPorts has many more packages that-just-work.

I never did the switch because I never had to complain about MacPorts. Last time I looked at Homebrew it had a very small number of receipes compared to MacPorts' ports.

I ran a fairly convincing "Linux-like" alternative desktop using Awesome in XQuartz for about a year before I switched to Linux full time. That was before Homebrew but I'm quite certain that it would have been impossible with it.

Most of the issues come from kernel differences. Some are relatively big, like epoll vs. kqueue, and some are very subtle (some syscalls have subtly different behavior on strange edge-case scenarios). I don't think building this natively would be too hard, but in the context of everything else left to do, it isn't an absolutely trivial project.

Reply on news.ycombinator.com