Hacker Newsnew | comments | show | ask | jobs | submit | pnathan's commentslogin

I have developed in Python for the past 4 years, give or take. Virtualenvs have, hands down, been one of the worst parts of the experience, without exception, and I can not recommend them.

(No, I won't write up an essay about why on HN. If you really want me to, shoot me an email and I'll write an essay about them).


mbreese 3 days ago | link

I've been doing this for a while longer (Python heavily for the past 7-ish years) and I've had a great experience working with virtualenvs...

So, I'd love to see that essay :)


Last time I looked at D (maybe 6-8 years ago), I saw a C++ reskinned, and two standard libraries, incompatible.

Looking at it today, it looks much more modern, but I'm simply not interested. I've drunk the Rust koolaid. :-)

(But it would be interesting to do a compare and contrast with a decently sized project for both D and Rust).


I sit in that area (SRE/DevOps/Tools) as well, and I strongly believe that Rust is a better foundational language because of the type system strength and guarantees. Particularly useful is the `enum` type and type matching. I want, simply put, to be able to write code that is "bulletproof" after I've brought it to deployment, and Rust gives me some awesome tools for that.

(I've also come to understand that Go is an extremely sharp tool for Google's problems - the style of coding, the concurrency, the expectations of the developers (look at the Google style guides to see the culture of development there, there's a harmony with Go). Your harmony with Go reflects your harmony with Google's problems).


I am generally very happy with KDE.

It's much more hacker-friendly than Gnome/Unity IMO. Its footprint is huge and there's enormous power in it that I don't use. XFCE is similar but doesn't have the polish that KDE does, especially around multimonitor support.

I would encourage the KDE team to focus on driving towards the hacker use case and letting that power drive the end user experience. :)


IMO,a multiplexing system should be done: a stack emits a given standard output. Which then gets read by a operating system package builder and ginned into the OS standard format.


TylerE 17 days ago | link

That's never going to work. How is yum or apt ever going to grok the 5+ python virtualenvs I'm working with at any given time?


I think that Cricket Test matches (take place over 5 days) also seem to stress team capability fairly well. But I'm not a cricket expert (I would need to be introduced by someone knowledgable), so I may be quite wrong!


There is a wisdom here, lieing in the English name: accounting, to hold accountable, to reckon up the debts and mete out justly and rightly.

It's something worth pondering and considering it as a righteous practice.


pcrh 18 days ago | link

The origin of the words "audit" and "auditor" is also interesting. The auditor would receive (listen to) the state of affairs/finances as described to him and then report that to his master.


This sounds fascinating and the kind of game I'd get a rush from. Is there a popular forum to find other face to face players?


nnnnni 23 days ago | link

Yes! http://www.webdiplomacy.net


bhickey 23 days ago | link

Most tournament play is organized on mailing lists. If you e-mail me, I can put you in touch with players in Seattle.



I'm working on my first non-trivial system with Rust right now, and I'm finding that the learning curve related to the borrow checker and lifetimes is rough. I'd liken it to macros in Common Lisp, but not quite as a cliff as monads.

In other words, I would like to ask that a substantial amount of your time in documentation at some point be pointed at the lifetime & memory system, as it is, IMO, the really unusual and hard part of Rust (As well as the whole freaking point of it too! ;)).


charlieflowers 25 days ago | link

This topic would be well served by something like "katas." A series of code samples that look (to the noob) like they should compile, but don't. The series of samples would be chosen to walk the learned through the surprises in pedagogical order.


pnathan 25 days ago | link

I actually find the whole kata code sample thing to be entirely inverse to how I learn. I typically learn by principles first.

Others entirely differ. And that's A-OK! :)


charlieflowers 22 days ago | link

Actually, that's my preference too. But for certain topics, even after you grasp the principles, there are certain things that are going to surprise you until you get more experience. You can identify these in advance and find they will surprise most learners. So the kata approach is supplementary, kind of like well chosen exercises in a good textbook.


steveklabnik 25 days ago | link

Yes, as you mention, the lifetime system is the big issue for newbies in Rust, and also a large part of the point! Revamping those guides is high-up on the TODO list.

I also suspect that lifetimes are one of those features that people might say, "I learned Rust, and I don't code in it, but learning about lifetimes improved my code in $DAYJOB_LANGUAGE." Just like how I think Haskell improved my ability to program in a variety of other languages, but I don't really write Haskell anymore.


This is probably something worth saying louder.

If you commonly display $information in all sorts of settings, then $information is not ipso facto private and leaking that information further is not a privacy threat.

(Of course, it can be used as an input to deanonymize you in some data-mining system, so there's that...).



Guidelines | FAQ | Lists | Bookmarklet | DMCA | News News | Bugs and Feature Requests | Y Combinator | Apply | Library | Contact