Show HN: Service/API to Transform Data from XML or JSON to PDF, HTML or Images - <AUTHOR> https://prexview.com <comment><USER2> Hi. PrexView is amazing! I am a developer and this has been very useful for my clients. I even had needed PrexView for personal use. You should give this a try.

<comment><AUTHOR> Thanks for your feedback, I'm glad you like it if you need any kind of help let me know!

</comment></comment><comment><AUTHOR> Hi, we just released a new service to transform XML or JSON into PDF, HTML or Images.

I would like to know what do you think and if some of you are interested in it let me know if you need any king of help. Thank you!

<comment><USER3> I'm confused about what you offer - are you creating extensions to XML & JSON for different types of documents? And adding an embedded programming API? And then I'm supposed to build those documents and submit them with REST? Will I be trapped so that I can only render if I purchase your service?

<comment><AUTHOR> Hi, sorry if the description is confusing, we are just launching and there are a lot of thing we need to polish, feedback and comments like this will help us to improve. Let me try to explain you.

This service is an API that you can consume by sending data in XML or JSON format, the service will take that data and a custom design (previously created with PrexView Studio a free app you can download in the site, it is like basic HTML/CSS editor) and finally the service will return a PDF, HTML or Image file.

There is only one design available at the moment (Invoice) but we will add more on the fly, If you have a particular XML or JSON you can map your data into a new design using PrexView Studio, save the design and then use the API to generate the documents. This is useful for apps that need to generate programatic documents like invoices and reports.

I hope this helps, if you have any additional question let me know, also if you need help to generate documents from your custom data send me an email.

Also uf you want to try the service, you can create an account with 50 credits per month for free

</comment></comment></comment><comment><USER4> I tried to use the API but was unable to get an API key without installing PrexView Studio. I'm not installing an application to try out an API.

<comment><AUTHOR> Hi, we are working on a web interface (like an admin console) where you are going to be able to get the API Key without downloading and installing PrexView Studio, the new interface will be ready at the end of next week.</comment></comment>


A flat rate approach to micropayments - <AUTHOR> http://flattr.com/beta/

<comment><USER2> Very nice idea. The problem is that if content providers don't subscribe to it, then they don't get it. What should happen is that flattr should allow for us to report who we want to give to even if they don't have a button. Then at the pay time, flattr tells the content providers about themselves and that people want to give them money for their services. And thus marketing to the providers and providers get money even if they didn't know about it.</comment>


Ask HN: What would it take to end up in a DDoS-free internet? - <AUTHOR> After the recent DDoS on Dyn, I started to wonder - what mechanisms would we have to implement and deploy to make it more complicated to perform DDoSes? Would for example adding some crypto, e.g. some kind of proof-of-work on TCP actually help here? How helpful would it be if all ISPs stopped allowing IP spoofing? How could we get there? <comment><USER2> DDoS mitigation is already a mostly solved problem; IDMS/TMS and RTBH are things. Many networks don't install them though, and when they do they often only get tested once an attack starts. For obvious reasons, many network operators are highly reluctant to hose down production services with test attacks.

Adding crypto isn't going to help in the case where someone's hosing you down with reflected UDP traffic, as the packets are still going to transit your ingress link and clog it up for production requests. Sure, you can force the use of DTLS, but your load balancers are just going to go "well this is bogus traffic" and throw it away, but by then it's too late since it's already in your network.

Mandating egress filtering for traffic isn't going to help that much either, because then a botnet is just going to stop spoofing traffic. This makes it easier to mitigate it from the target's perspective, but with a large enough set of transmitters the target will still see an impact.

The bottom line is that if you want to allow connections from the entire Internet, then every lightbulb, refrigerator, and lawn sprinkler with a wifi chip is eligible to connect to you. Unless there's an effort to create international policies to stop vendors from shipping exploitable firmware for these things, this problem is just going to keep getting worse for those of us who can't afford good DDOS protection.

</comment><comment><USER3> Pay for use billing would go a long way.

People running insecure networks and devices should feel a financial hit.

<comment><USER4> Bandwidth is already pay per use?

<comment><USER3> Most users (in the US at least) pay flat fees. Seeing your bill skyrocket because a compromised device on your network is uploading a constant 30Mbps is incentive to locate and resolve the problem.

<comment><USER4> In Australia we pay flat rates but our speed is severely reduced after a certain limit. You definitely know when you're over.</comment></comment></comment></comment>


Free hosted dev env ready in secs w/collab web IDE (Rails/django/Node/Go) - <AUTHOR> https://www.nitrous.io/join/mlcsvWTMiOw

<comment><USER2> It's not cool to be sharing your referral link to Nitrous. It's a neat service, but it's a shame that you're trying to take advantage of the HN community.</comment>


State of Text Rendering (2012) - <AUTHOR> http://behdad.org/text/ <comment><USER2> I would love to see such a report for VR text rendering.</comment>


GPS Is Going Places - <AUTHOR> https://arstechnica.com/science/2019/12/gps-is-going-places/ <comment><USER2> GPS may be reliable for early warning of larger quakes. Both seismic waves and seismometers saturate at magnitudes above M7.5. That is to say its hard to tell a 7.5 from a 8 or 9 because appear similar size waves. It takes sophisticated computer analysis of a global set of seismographs to computer true quake size. This initial confusion happened in the disastrous 2011 Fukishima quake.

On the other hand working with GPS displacements gives an answer in less than a minute for larger quakes and more warning time.

[https://eos.org/features/seismic-sensors-in- orbit-2](https://eos.org/features/seismic-sensors-in-orbit-2)

</comment><comment><USER3> They mentioned probing snow.

How about if you could detect snow or ice on the road ahead of you by looking at gps reflections?

Seems like you could have a good idea what the reflections from a normal road surface look like and compare.

<comment><USER4> That sounds like a radar with extra steps.

<comment><USER5> Extra steps but no extra hardware sounds like a pretty good trade-off to me.

</comment></comment></comment><comment><USER6> Common cellphone GPS being able to feel an earthquake would be incredible. Imagine Google Maps telling you to pull over because there was an earthquake, or redirecting you to safety.

<comment><USER7> How do you differentiate an earthwuake from common behaviors while the phone is in a pocket such as running, jumping, walking etc.

<comment><USER8> Doesn't really seem that difficult. The patterns of picking up a phone, running with it and having it just lay on a vibrating surface are very different. It would be particularly easy to spot panic during a usual running routine.

<comment><USER9> More, I'd imagine you could look for a signal common to many devices. Unless you are picking up all phones in your household with the same signal, any signal common to them all is likely more global. Could detect if folks are in the same car?

</comment></comment></comment></comment><comment><USER10> All these "things" GPS can do involve the satellite signals being received by very specialized equipment, not cell phones which arguably the title implies.

<comment><USER11> >not cell phones which arguably the title implies.

Let's examine the title:

>GPS is going places

Nothing about cellphones.

Maybe it's in the byline?

>Here are five things you didn't know the navigation system could do.

Nothing there either.</comment></comment>


Ask HN: Greatest Living Thinkers Today - <AUTHOR> http://www.paraschopra.com/blog/personal/greatest-living-thinkers-today.htm

<comment><USER2> Am I the only one who finds the notion of (for example) Seth Godin on a list of "Greatest Living Thinkers" to be terrifying?

And would it be to much to ask to see, maybe, a philosopher or mathematician or two listed?

<comment><USER3> What I find scarier (or more interesting) is that if all I read were Hacker News, I would have a list that would be exactly the same as the author's.

Perhaps a better question would be what do all these people have in common, other than being successful, accomplished males with reputations for being irreverent?

</comment></comment><comment><USER4> I wouldn't pretend to know. I know the people I consider to be the best in their respective fields, but I would never pretend that that equates to "thinking" because frankly, "thinking" is all-too-often a bullshit phrase that means nothing.

If I had to name some people I thought were really making a mark on the world (and my list is biased immensely towards artists), that list would include:

* David Lynch, who I think deserves to be on the list for Eraserhead alone;

* Mark Z Danielewski, one of the very few writers I know who manages both to be fascinating, deep, experimental, and a good read;

* Steve Jobs, who has done more for the high-end consumer market than anybody else I know and who has seemingly unfailing instincts;

* Nobuo Uematsu, who is easily my favorite modern composer and who manages to write unique yet powerfully thematic pieces consistently; and

* Philip Glass, who is an absolute master of his style of composition.

But I wouldn't say that these people are necessarily the greatest thinkers today. They're just the ones whose work fascinates me, the ones who I feel are innovating the most honestly within their field.

</comment><comment><USER5> [http://freakonomics.blogs.nytimes.com/2008/06/17/who-is- the-...](http://freakonomics.blogs.nytimes.com/2008/06/17/who-is-the-greatest- modern-day-thinker/)

</comment><comment><USER6> Tim Keller is pretty high on my list. <http://www.youtube.com/watch?v=Kxup3OS5ZhQ></comment>


Ask HN: How do I deal with the "unpaid overtime crowd"? - <AUTHOR> The moment I step through my work door I set a timer for 7.5 hours. Once that timer is up, I close all my work, and go home.
There are 4 people on my team, who I honestly think just do not have their own lives. They come in at 8am, and leave around 10. Every single day.
I am at the bottom of our "scoreboard" for bug fixes, yet I work the most efficiently. They have 3x more fixes than I because they just choose to sit here for hours and hours and hours and just work, I don't get it.
Now I look bad in comparison, management doesn't give a shit (obviously) and I have already had my job threatened. "I have no problem buying out the your contract, you're the least effective on our team". And "Why can't you be like _________ and __________?"
My favourite part is, I designed the entire UI/UX for the app, I coded all of it for over 15 mobile devices. These people do not have the same skill set as I do. I explained everything to management, and they just told me "I don't buy it, I expect you to unofficially make up yours hours".
Now they want us to come in on Saturday. Of course the rest of my team has no problem with this, but I run my own company and any second I can find that is free, I'm using, and bet your ass I'm working on my own shit on the weekend.
I've never been so stressed out in my entire life. <comment><USER3> First, kudos for doing what every one of us should do i.e. value our own time. It is amazing to see a lot of people who just don't value their time.

This mentality that somehow sitting in office for long hours and cranking shit out is just so horrible. I really believe that this has to do a lot with the individual employee/person rather than just management. Yes, I am not counting out the pointy haired bosses and all but to a _great_ extent, it is up to you, the employee, to dictate how long will you be working on a given day. Sure, some of us love sitting in office because we probably have nothing better to do (been there) but learning to value your time is really underrated. People, learn to value your own time and you will suddenly see how everyone else around you respects you for that. /rant

Now, just to add the other side, creating value is a lot more than spending x hours in office. Like you said, you designed a major component of the app which is what matters. Yes, there may be days when you want to crank that stuff out like there is no tomorrow because you are excited about it, go for it. And yes, go work on _some_ weekends if needed for the team (release/critical fix etc). Take one for the team but do it wisely. Let everyone know that you are willing to raise your hand but you are not a doormat.

In your case, since are you doing the right thing, your company does not deserve you and based on what you said, they already don't care about you. So like everyone else is saying and you know the answer anyway, find something better and move on.

<comment><USER4> His company does not deserve him?

The guy, by his own admission, is more focused on his own company that he works on nights and weekends. Why would any startup want a guy like that unless he was radically better than everyone else?

<comment><USER5> If you've stopped to look around you'd notice there is a dire shortage of good developers who want to work for others. Nearly all the good developers I know work on side project/hopeful businesses in their spare time. It's almost a mark of a good creative developer that he has those kind of side projects.

A startup would want a guy like him because a startup needs to grow rapidly to justify existing in the first place and a good developer will easily justify their position on a team. If the OP is being truthful, he designed the very product the entire startup is based on. So to answer your question - <USER2> startup would want a guy like him because there might not be a startup without him.

Obviously if he's no longer worth his salary then the startup needs to let him go. That decision has absolutely nothing to do with the number of hours he works and everything to do with whether his benefit to the company justifies his cost.

<comment><AUTHOR> > If the OP is being truthful, he designed the very product the entire startup > is based on.

Hell yes I did. Entire UI. Coded it too. 45K, no benefits, nothing, just 1400/two weeks after taxes.

<comment><USER6> Why would you stay there for 45k and no benifits? 45k/year is a slap in the face for any decent developer.

<comment><AUTHOR> How on earth do I find another job? I have never once gotten a reply from another company when applying. I'm a university dropout who is 21. Nobody wants to hire me. I'm utilizing like maybe 25% of my potential, so I started my own company.

I'd love some help with this. There's so many companies I want to reply to but I'm scared.

<comment><USER5> First: don't be scared. Your best offer will be based on how many offers you received. How many offers you receive will be based on how many jobs you try for. When looking for a job you want to apply for as many jobs as possible.

If you're getting very few responses, it means your CV is hitting some kind of red flag. The university dropout might be triggering it - most recruiters will be able to look past it though if you structure it well. You probably need to make sure you downplay education as much as possible and focus on achievements. Highlight which skills and languages you are an expert in and find buzzwords that fit your skill set. There's plenty of jobs, so you can try a few different CVs to a few different companies and see which ones have a good response rate.

Or stick with your own company. You'll probably learn and accomplish more, and ultimately if you build something great then at least you'll be the one getting the rewards. (This is probably not a good option if you have zero runway available, but people have made it work in the past...)

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> ISSUE #1 - Barring unpaid overtime, what are their expectations? You're working 37.5 hours per week (7.5 × 5), which is less than the "standard" 40 (though you're still considered full-time for the sake of benefits, etc.). It's unclear whether your 7.5 hour figure includes "non-productive time" (e.g., lunch, breaks, etc.).

ISSUE #2 - Quantitatively, your numbers may be hyperbole, but they don't bear out your claims. Your co-workers have 3x as many fixes as you, but they only work 2.6x as much as you (assuming 14 hours / day × 7 days / week). By these numbers, they are 15% more effective than you are. (And they're harder workers.)

Fundamentally there's a culture mismatch. You think you have differentiating skills—they don't agree. You think you are more efficient—either they don't agree or that's not their metric. You want to work a 40 hour week—they want people who will kill themselves.

There are a couple options (e.g., going hourly), but I don't think they're realistic given the context. After all, your effective hourly rate is way higher than someone who takes home the same salary but works twice as much. So I agree with the other commentators: find an opportunity that's a better fit for you.

<comment> workhere-io _You 're working 37.5 hours per week (7.5 × 5), which is less than the "standard" 40_

I don't know where OP lives, but several countries have work weeks that are less than 40 hours. [http://en.wikipedia.org/wiki/Full- time](http://en.wikipedia.org/wiki/Full-time)

</comment></comment><comment><USER8> This is my personal opinion as a software development manager, so take it as just that.

A developer that always leave at exactly 17.00 and adamantly refuse to come in on a Saturday, gives a very clear signal that they don't give a shit about the company, the product or the team. They're there to get paid.

While most employers realize that your work isn't (or should be) your single burning passion, it is very negative for team morale when one of the guys always flakes out when the clock hits 17 regardless of the fire in the kitchen.

I knew a developer who always left at exactly 17.00, because "that's what they are paying me for". On several occasions, he deployed breaking changes to production five minutes before leaving. Other devs had to come in and work very late to get the system back online. While he is technically in his right to leave at 5, he causes his team much grief and as such is not an asset.

The other side of the coin is that lots of software companies, really has little to no control over software development. Especially startups run by young, inexperienced guys rarely have any idea what they are doing. This is a company where crisis' occurs daily or weekly instead of maybe once every couple of months.

They make up for this by rampant overtime, and excuse this with BS about being dedicated and a team player. You know you're in such an organization if they talk about how "that's what the industry is like".

Your organizations work culture seem like that - very long hours and (seemingly) no extraordinary reason for coming in on Saturday.

If that's the case, then leave. There's not much that can be done except a total change of top management.

But if it's a rare occurrence that they call you in on Saturday and there is a good explanation for it, then buckle up and help your team mates.

<comment><USER9> > A developer that always leave at exactly 17.00 and adamantly refuse to come > in on a Saturday, gives a very clear signal that they don't give a shit > about the company, the product or the team. They're there to get paid.

If once in a while something crops up that requires staying after 5 then that is fine however the expectation should be that _all the developers go home at 5pm_

> While most employers realize that your work isn't (or should be) your single > burning passion, it is very negative for team morale when one of the guys > always flakes out when the clock hits 17 regardless of the fire in the > kitchen.

If there are constant fires in the kitchen you might want to find out who keeps lighting them, if's not the guy leaving at 5 then I fail to see the issue.

> I knew a developer who always left at exactly 17.00, because "that's what > they are paying me for". On several occasions, he deployed breaking changes > to production five minutes before leaving. Other devs had to come in and > work very late to get the system back online. While he is technically in his > right to leave at 5, he causes his team much grief and as such is not an > asset.

Pushing to production shortly before going home is a separate issue to whether he leaves on time or not, a developer leaving on time should be expected, a developer pushing breaking changes and leaving should not.

The other stuff I wholeheartedly agree with.

<comment><USER10> > Pushing to production shortly before going home is a separate issue to > whether he leaves on time or not, a developer leaving on time should be > expected, a developer pushing breaking changes and leaving should not.

This. I strongly believe in finishing what I've started and not leaving things broken. I also strongly believe in work-life balance which to me means working hard until 5 but leaving then.

EC1: If you're confident that your work ethic is sound, then there sounds like there's a significant culture mismatch here. I know it's not easy to think about going somewhere new, but you may have to consider that sooner rather than later. I honestly wish you the best of luck no matter how this shakes out.

</comment></comment></comment><comment><USER11> So I'll lead with "you need to leave." Huge, obvious cultural mismatch.

With that said, I think it's bizarre how some of the commenters here are vilifying your management. I don't know the specifics of your company, but you can't run a startup at crunch time with devs putting in 7.5 hour days. Even at Google, which I considered extremely cushy and laid-back, there was the overt expectation -- repeatedly referenced in internal literature -- that engineer- weeks were about 50 hours long.

I think it's great that you've identified the level of work-life balance that will work for you and are standing your ground. But you need to understand that working 7.5 hours days is not some sort of universal human right. In the (near) future when you search for jobs, you need to communicate that preference up front and make sure that management is on board with it rather than taking for granted that they will be.

<comment><USER12> I don't agree with this. Why not be able to have a startup succeed with 7.5 hour days?

For me, I can put in a day longer than that when I need to, in an extreme circumstance. But if it becomes often, I just can't be productive longer than that. I loses ability to focus, and start accumulating burn out. My throughput is greater at 7.5 hour days than 10 hour days.

Of course, if there's like a week leading up to a launch where you need to crunch, that's different. I've been there, and have been able to be super productive like that for a week. But it can't be sustained... I feel like I'm basically borrowing some productivity from the future, and that debt will catch up to me eventually.

<comment><USER11> The sentence in question was: "You can't run a startup at crunch time with devs putting in 7.5 hour days." The "at crunch time" was meant to qualify the rest of it -- to suggest that standard hours might work some or even most of the time, but not when you get that big client on the hook who wants something custom next week. I think that's in line with what you're saying.

With that said, most of the successful startups I know involved long hours early on, and not just occasionally. It absolutely involves borrowing from future productivity and present quality of life. Sometimes taking that loan is worth it, and sometimes it's just a stupid, pointless death march and the urgency is manufactured. The latter might be more common but the former definitely exists.

</comment></comment></comment><comment><USER13> They're simultaneously threatening to fire you and also begging you to do more work; those are polar opposites. Do you feel like they need the work and are trying to use the (empty) threat of termination as motivation, or do you feel like they're trying to take advantage of you and get something for free?

Either way, you should probably quit. But if you can figure out what they actually need, it might help reduce your stress a little bit. Only a little, though, because having abusive managers or coworkers is really terrible and wears at you in a way that's pretty hard to describe. So you should probably quit.

</comment><comment><USER14> Leave. You're a bad fit for the company culture. The company culture is a bad fit for you.

<comment><USER15> ...best answer.

</comment></comment><comment><USER16> Its hard to do, but I really think you need to leave.

Give your 2 weeks but be OK if they let you go on the spot.

If you dont have a lot of money, maybe you could put in a few more weeks before you quit and literally try and save every penny you can. If you have vacation time in the bank hopefully you get paid out for it.

I've been in situations where the "Boss" doesn't have a clear technical understanding between different roles and it is very hard. It feels like a Dilbert and/or Office Space moment to me.

<comment><USER17> > If you have vacation time in the bank hopefully you get paid out for it.

I was under the impression that is legally mandated (at least where I live - NYC). Is that not true?

<comment><USER16> I think it is, at least here in CA. I also lived in NY and it was the case too.

What I was thinking is that maybe if they terminate him and he is a contract employee they could get out of paying it for a while if there was legal action brought by either party..so he shouldn't count on that money to live until it clears his bank.

</comment></comment></comment><comment><USER18> I once worked in a cafe in my teens, we would be paid up until half an hour after close to do cleaning. Mopping the floor was the last task I did, it would usually end up running 5 or 10 minutes over the time I got paid. Your post makes me imagine dropping the mop half way through finishing the floors and walking backwards out the door while flipping off my boss because that half hour ticked over.

"The moment I step through my work door I set a timer for 7.5 hours." This is a terrible work ethic. You set a timer? I don't agree with doing unpaid overtime either, you certainly won't see me in the office on a Saturday, but sometimes things need to be completed before you leave for the day. But maybe that's just my opinion working in a remote office in a vastly different time zone to head office where my work needs to be delivered.

Although not a metric, I did chuckle that you state your co-workers work twice as long as you (14hrs vs 7.5) yet have three times as many fixes as you and then reference the reason for this is the time they spend at work.

</comment><comment><USER19> If the stress is overwhelming you, then you should see if there is a solution to remove the stress. If not, then you should probably quit. It isn't worth what stress can do to your health and relationships.

If they need you to do more work beyond your 40 hour week, to the point that they threaten to fire you, then your supervisor likely realizes they need you.

If you find that at 5pm that you are twenty minuets away from finishing something up, then you should consider doing that from time to time, just to show you're on the team.

I am lucky enough to be in a position that I am on salary, but I am still paid overtime if the work load moves beyond 40 hours a week. If I need to work an extra 15 to 30 minutes to finish up what I'm working on, I don't count that as overtime. If I get a ticket that needs addressed, but there isn't time to do it in the normal work day, that counts as overtime.

Maybe consider proposing something similar. If what they really need is a little more help, but don't want to hire a new dev, they may be willing to come up with a compromise.

Good luck.

</comment><comment><USER20> As stated by other, the obvious answer is to leave.

What is puzzling to me is that you sound like a skilled and confident developer, yet seem afraid of wading into the job market. Are your local employment options that bad?

<comment><USER9> They can be that bad depending where you live.

I've got 16 years experience with Linux, more than 20 years experience of programming, more than 3-4 years commercial experience on my current stack.

I've written desktop applications for businesses, I've written software for market traders, I've written web based systems for engineering companies.

I still wouldn't want to be looking for a job where I live right now.

<comment><USER21> May I ask where you live? I live in flyover country, and I can't imagine you would have a difficult time finding a new gig around here.

<comment><USER9> North East England, Just outside a town called Hull.

</comment></comment></comment></comment><comment><USER22> Stress isn't good for your clients and your personal relationships. I've had a similar problem, I'm quite insistent on using my own equipment, my recent client said yes to get me move over 4hrs away from my home, then the security team said no once I setup my kit and put down a six months deposit on a flat. I insisted on new equipment or a pay raise for pay in lieu of my slower rate of experience and discomfort which effects my out of hours work. They bought me a new iMac and I'm now technical lead for a reputable sports product. I arrive at 7am and leave at 3pm but turn out 200% more than other members in the team and maintain test coverage +90%. Remember to keep a smile on your face when you discuss it with them though. They'll worry about what you know and what they don't. The first one to lose their manners is usually wrong regardless of the technical details in companies like these.

</comment><comment><USER23> I don't think they necessarily "don't give a shit about the company".

In fact, I think setting appropriate personal boundaries is extremely important. A lot of devs recognize 'hour creep'. You know, stay in a few days until 6, and before too long, it becomes expected. I am saying this as a founder and someone who puts in as many possible hours.

At first, I thought, "Are you guys not really in the game?". But now I recognize that there are only a few people who I should really expect to be on that level, and it should be made explicitly clear from the get-go.

In this case, there is a clear metric that the employee is facing. However, this person certainly adds quite a bit of value.

I think this is worth confronting management over. But I also agree, that if there is a rare occurrence for weekend work, then that is also part of the team. Rather than quit outright, like many suggest, I would confront management very clearly about your personal boundaries and ask them explicitly what is the gulf between their expectations and what you are giving.

</comment><comment><USER24> For reasons like this, I'm not sure I'll go back to a salary model (in favor of hourly model). I value my family time and personal time, but for those times where "the barns burning down", at least I'm compensated for putting out the fire.

(...And if the barn is always burning down, look for a new job.)

</comment><comment><USER25> Sounds like management doesn't appreciate you, nor are they competent at what they do. You deserve better. It's commendable and professional to work a set number of hours (~7-8 / day, though it varies). It is unprofessional and a sign of management's failure to ask you to work more, work on weekends, or catch up to hours you don't owe them. It would also be unprofessional for you to bow down to such ridiculous requests. It sounds like you are contributing more than anyone and with your skill-set, you should have no problem finding another job, hopefully one that isn't filled with unprofessional managers who can't manage and demand one work unprofessional hours.

tl;dr: Working more than 8 hours a day is unprofessional (except in rare, extreme circumstances where it is rewarded).

</comment><comment><USER26> > They come in at 8am, and leave around 10

> Now they want us to come in on Saturday.

I would definitely GTFO!

Productivity != hours sitting at a desk.

I have worked at a company like this and the issue was definitely poor management direction and poor technical discipline.

<comment><USER27> In addition to having a bug "scoreboard". That is so easily gamed it not funny. Grab all the easy bugs, get the top score.

<comment><USER28> I always find it funny when management lauds developers for aggressive bug fixing. Do they not realize that the developers introduced those bugs in the first place?

<comment> jack-r-abbit A bug scoreboard needs two columns. One for bugs fixed and one for bugs created.

Edit: actually, bug scoreboards need to die in a fire. But until then... they need two columns. :)

<comment><USER16> And a few more columns for:

1\. Did you really understand the bug you were fixing?

2\. Did you test it at all?

3\. Really did you test it?

</comment></comment></comment></comment></comment><comment><USER29> My two cents is that this situation is more prolific than you might think.

My own theory is that most young engineers start out by valuing their own time -- but they find themselves in a situation like this. They then relegate themselves to working long hours to please management, and eventually they work inefficiently all the time and are OK with that.

They're too withdrawn/introverted to stand up to management or take the leap to find a new job.

Regardless, like many others said, time to quit. They're not a good fit for you and a "bugfix scoreboard" sounds absolutely vile.

</comment><comment><USER30> Look for a new job. Your relationship with them can't be salvaged.

Also, this is why you keep a 6-12 month emergency fund, in case you have to walk away or get fired.

</comment><comment><USER31> If you aren't already looking for a new job, why aren't you? It sounds like a bad fit and they don't appreciate your contributions.

</comment><comment><USER32> You posted this looking for support for what you know you need to do.

Quitting isn't fun, but sometimes it's the only way to solve a problem.

</comment><comment><USER33> Sounds like they are trying to exploit you. There are plenty of companies out there that want you to think of them as "more than a job", but don't want to give you equity or pay competitive wages. Start taking interviews for other jobs. Once you have on lined up, you can either quit, or use it as leverage to talk to your boss.

</comment><comment><USER34> Instead of writing to the HackerNews posters asking for common sense advice, just quit your job.

<comment><USER35> It is not easy to leave a paying job for some people. In the same way it is not easy to leave a paying job that is crappy. He isn't asking for common sense advise his is looking for some sort advice that will serve as validation to give him the confidence to make this decision. He probably knows what he needs to do, our answers can only serve to assist him in making this decision.

</comment></comment><comment><USER36> No matter what, get out. They are toxic people with twisted values who do not understand quality. Get out.

Accept their offer to buy out your contract. If they try to terminate you, be ready to lawyer up for a breach-of-contract suit.

Get out.

</comment><comment><USER37> Like everyone else said the best option is to find place with a better fit. Second, I would throw them a bone here and there until you find something else. third, do enough to get off the bottom of the list.

</comment><comment><USER38> My suggestion: Look for a company that you can comfortably work the 9-5 and not have any issues with that.

</comment><comment><USER39> There is no point to play that game, you will loose anyway. Keep with sane hours, find a new job, quit.

</comment><comment><USER40> Just.. leave. I know it's easier said than done but, I've been in a similar situation. No money in the world pays the stress you're going through.

<comment><USER41> Environments like this aren't worth dealing with, +1 for bailing. When you're looking at new gigs, ask questions about what the culture is like, oriented around work / life balance, and try to get a feeling for the number of people with families. I personally am a single guy with no children, but I like working around family oriented folks because they are used to the idea that you have many aspects of your life that are more important than your job (whether that happens to be family obligations or not).</comment></comment>


Two Years with Rust - <AUTHOR> http://brooker.co.za/blog/2020/03/22/rust.html <comment><USER3> Here is an historical note for those who might be interested. In 1979 I did a Post-doc with Rod Burstall. I helped implement the programming language Hope, which was the first functional programming language to use pattern-matching in function definitions. The implementation was written in an older language called POP-2. Robin Milner and his group were at the the time working on LCF and ML, and they eventually incorporated Burstall's pattern ideas. Eventually, I recall there was a decision within the UK functional programming community to consolidate their efforts into what became Haskell. And of course we see how much Haskell has influenced the newest crop of imperative languages.

It is interesting (to me) to compare factorial in Rust with factorial in Hope:

Rust:

fn factorial(i: u64) -> u64 {

        match I {

            0 => 1,

            n => n * factorial(n-1)
        }

}

Hope:

dec factorial : num -> num;

\--- factorial 0 <= 1;

\--- factorial n <= n* factorial(n-1);

Note that, in Hope (unlike its own inspiration, Prolog, and, I think unlike Rust), the order of the rules does not matter: the most specific pattern takes precedence. Hope was primitive with respect to types, and did not use Milner's type inferrencing ideas. I don't think Burstall ever intended it to be a "real" programming language. When I left Edinburgh, Don Sanella took over from me, so I was not involved in writing the paper about Hope, but my contribution is acknowledged.

I implemented the pattern matching code, and the idea of pattern compilation occurred to me. I remember showing it to Rod. He freaked out at first, but after about a five minute harangue, the penny dropped, and I remember him saying "clever Michael", "clever Michael" in his charming way.

<comment><USER4> Very cool, thank you for this history!

> I think unlike Rust

Yes, this is correct: Rust looks at patterns in order, top to bottom.

Incidentally, some folks have asked for a syntax closer to Hope (and Haskell, and others) [https://github.com/rust- lang/rfcs/pull/1564](https://github.com/rust-lang/rfcs/pull/1564)

      fn factorial(0: u64) -> u64 { 1 }
      fn factorial(n: u64) -> u64 { n * factorial(n - 1) }

I doubt this will ever happen, though.

<comment><USER5> I really hope this doesn't happen.

I've never understood the infatuation for this Haskell type syntax where you need to repeat the name of the function for each and every single match case. It's so needlessly verbose.

<comment><USER6> I find it dramatically cleaner.

Each clause is categorically isolated, unlike a case statement (the alternative in Erlang, with which I'm most familiar) where code can precede the case statement and thus introduce bindings that can muck up the logic.

<comment><USER5> Yes but why repeat the name of the function every time?

It might make more sense if such clauses are scattered through the source, but they are pretty much all the time grouped together, so the name of the function doesn't need to be repeated all the time.

For example, instead of

        factorial 0 => 1;
        factorial n => n* factorial(n-1);

Something like

        factorial {
            0 => 1
            n => n* factorial(n-1);
        }

<comment><USER6> As much as I like short functions, not all function clauses are just one line. I don't see your alternative as helpful for longer clauses.

<comment><USER5> Whatever syntactic means you use to specify long clauses with the current syntax you can reuse with my syntax.

<comment><USER6> Yes, but function names are a useful way to separate long clauses

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> > It's been over 10 years since I last worked with C++ every day, and I'm > nowhere near being a competent C++ programmer anymore. Part of that is > because C++ has evolved, which is a very good thing. Part of it is because > C++ is huge. From a decade away, it seems hard to be a competent part-time > C++ programmer: you need to be fully immersed, or you'll never fit the whole > thing in your head.

This is really true. I have worked with C++ for 15/20 years, reading and studying everything I could.

I've reached a good competence but every time I stopped for a while I immediately fell behind.

C++ is a difficult beast.

<comment><USER8> I think to get good at a given systems language these days the effort is the same. For instance, concurrency still requires the same underlying ideas to be understood whether C++ or Rust. After all the machine underneath is the same.

Rust has some nice-to-haves of course, but C++ has been able to grow up and evolve because of the rich feature-set the template meta-programming language has provided it.

One can simply stick to C++11 or 14 and work with those features alone to make strides in development. Hell, people have used C++98 for decades.

Personally, I think what C++ offers is the same as Rust. Both need a robust testing and code-coverage tools for correctness, but the end result requires simply good development practices and love for the work being done.

<comment><USER9> > Personally, I think what C++ offers is the same as Rust.

I think this dismisses incidental complexity that can certainly exist in general, and certainly does exist in C++.

Just look at how complex move semantics are in C++:

* you have & and && references,

* there are all sorts of categories (e.g. glvalues),

* in a template && means something different (but not always),

* std::move by itself doesn't actually do anything (yes I know it's a cast but this is still confusing at least upfront),

* even if you do pass the result of std::move (or otherwisie know you have an rvalue reference) to a constructor then it's still possible that the object will actually be copied with no error or even warning.

In Rust, the difference is enormous:

* When you move from a value, it's guaranteed that the old object's destructor will not be called, so you don't need a move constructor that hackily sets up an empty value so is destructor won't do anything;

* Move is _always_ a bitwise copy so it's easier for the caller to understand and free for the implementor to implement (this is enabled by the previous point)

* Move is the default instead of copy which makes a million times more sense because you can just implement copy as a regular method that happens to return (move!) its result (whereas you could never implement move as something that returns its result by copying) and if you actually want to copy a value to a function you can just call the copy method and move that value to it.

This final one is key is really, it's not possible because of C++'s history and backwards-compatibility requirements and that's why it had to come up with the crazy system it now has. Rust has many nice features but really the move vs copy stuff by itself is a huge saving in complexity, and the fact that Rust manages it at all proves that it is not intrinsic to the problem.

(Disclaimer: I have worked with C++ on and off full time for more than 15 years, whereas I have only tinkered with Rust.)

<comment><USER10> You forgot about SFINAE, CTAD, decltype vs auto, perfectly forwarding references, guaranteed RVO (but only in certain ISO versions), initialization semantics, ...

<comment><USER11> He didn't forget perfectly forwarding references.

<comment><USER9> But that does show how confusing the notation is!

<comment><USER11> I guess I watched the back to basics c++ series on move semantics and its not really all that bad. I did struggle with it beforehand though. I've never worked in C++ tbh. I does take the 2 hours but you have it when you're done. [https://youtu.be/St0MNEU5b0o](https://youtu.be/St0MNEU5b0o)

<comment><USER9> Really? You can tell off the top of your head what the difference between an xvalue and a glvalue is? Which function has higher precedence in the overload list out of foo(string&) and foo(string&&)? (Note that's not a const string&!) That these are so obvious to you that there's no chance you would make a mistake about them when you're in a hurry trying to solve an actual problem that has its own complexities rather than playing games with C++'s unnecessary complexity? The one where foo(std::move(x)) doesn't necessarily move x is a particular killer (although at least it only causes a performance problem rather than noticable change in behaviour).

I have worked with C++ for a hell of a lot more than 2 hours since C++11 came out (the first version with move semantics) and worked with many others that have too, and I can tell you that "once you have it you're done" is just not true. I fully understand all the concepts but I can still make mistakes.

<comment><USER11> Is there more? Yea. Do you need for most code ? No. Also I lied I have coded professionally in C++.

<comment><USER12> Yeah we totally believe you, you just keep on digging your heels in on this one cause that's how you get people to take you seriously and think you're smart.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> I would expect Rust to do well in these sorts of areas involving systems programming and low level development including projects like Firecracker.

The features that are very compelling is that installation is painless, static linking is encouraged and used widely and its APIs aren't tied to any specific platform, thus is a true cross-platform language done right. It would be better to compare it to C++ rather than C since they both interface and surpass the complexity of the language.

While the language is mature, the author fails to mention that most of the crates ecosystem is immature and some are unsafe. Especially in the domain the author is working in, there's a degree of risk in importing some crates which can compromise the safety of the project (use at your own risk).

Cross-compilation is there in Rust, it requires downloading the toolchain for the specific platform and Go has it truly built-in, so I'll give them that one. Lastly, it may be possible to use a cross-platform GUI library like gtk- rs, but it isn't widely adopted unlike Qt, Electron and Flutter. The question around that is whether if Rust is suitable for that use-case? As many ideas and crates for Rust GUI development are coming, for now I'd say soon.

The author is certainly bullish on Rust in general and in low-level development and so am I.

<comment><USER14> > The author is certainly bullish on Rust in general and in low-level > development and so am I.

While I share your sentiment, I've recently talked to about 5 people who write software for low-level, security relevant things in airplanes. Imho the best application for Rust one could think of. None of them had even heard of Rust. But this is highly anecdotal of course.

<comment><USER15> There's a number of reasons. Anything in a regulated industry like that has to have everything approved by regulators. The whole compiler toolchain, all libraries, blah blah. All have to be certified versions before you can use them. You can't just pick up github latest compiler and expect to ship a safety critical device with it. Coders in regulated industries may have never even heard of github, much less rust. Different mindset.

Second, it's typically not x86 architectures. They'll have a specific CPU or SOC that they use, from a specific vendor, and other specific vendors that provide the (certified) compiler and possibly RTOS that is used to target that CPU. Those vendors have decades of investment in their C code. Some small change in the asm rust produces vs c (and I'd expect the difference to be much more than a small change) could just break everything in a finely tuned RTOS.

Third (and last one I can think of offhand), there are tons of things like static analyzers and such that can be used against C code and have been developed over decades to find many of the things Rust has built in. They're not as good as Rust at some things but better in others.

Oh, fourth, these companies already have huge codebases and libraries they've already written and are used to. Rewrites / refactors are less common in regulated industries because of all the documentation they require.

Okay, fifth, and perhaps the biggest one, at least in my experience, we didn't ever malloc / new in the app code anyway, because of the potential for out of memory errors. We created a couple big buffers up front and used those exclusively. So rust's ownership model wouldn't even help there iiuc. I imagine most safety critical devices are similar?

None of this is to say that Rust will never be useful in a regulated context, but it has a lot of hurdles to jump.

<comment> Ar-Curunir Rust's ownership model isn't useful just for heap-allocated things; it's useful for all kinds of other safety guarantees, such as preventing unnecessary mutability.

<comment><USER4> To elaborate on this, nothing about ownership or borrowing has anything directly to do with heap or stack allocation. Allocation fits into the ownership and borrowing rules, not the other way around.

<comment><USER15> Nice. Is it frequently used in contexts outside of allocation? I assume allocation is the primary use, or at least it's the most talked about, but I have never done anything complex in rust.

<comment><USER16> One example of where it's used: to enforce correct usage of mutexes. Rust's `Mutex<T>` owns the data it protects. When you lock the Mutex, you get a reference to the data inside it, but it's impossible (a compile-time error) to store a copy of the reference beyond the point where you release the lock.

<comment><USER15> Cool. So the fifth point is largely nullified, which is a big one -- that the features of Rust would at least be _useful_ in typical safety-critical code.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17>
       "Static linking and cross-compiling are built-in."

I found out that the above is not completely true. According to the official Rust documentation, only Rust dependencies are statically linked by default. But compiled Rust programs depend on more than Rust dependencies, as they also use shared C libraries. The _capability_ is built-in, but it's definitely not straightforward.

"Pure-Rust dependencies are statically linked by default so you can use created binaries and libraries without installing Rust everywhere. By contrast, native libraries (e.g. libc and libm) are usually dynamically linked..."[1].

I did a small experiment to make a from-scratch Docker container with no dependencies and a single Rust binary and found out that I could not do that without jumping through some hoops[2]. I had to have it include a minimal implementation of libc called "musl". See my write-up here[3]. If anyone has found another way around this I would love to hear about it and make a correction in my write-up.

References:

[1]: [https://doc.rust-lang.org/1.13.0/book/advanced- linking.html#...](https://doc.rust-lang.org/1.13.0/book/advanced- linking.html#static-linking)

[2]: [https://doc.rust-lang.org/1.13.0/book/advanced- linking.html#...](https://doc.rust-lang.org/1.13.0/book/advanced- linking.html#linux)

[3]: [https://bxbrenden.github.io](https://bxbrenden.github.io)

<comment><USER18> To be honest you're overcomplicating the whole thing by involving Docker in the build process. Assuming you have Rust installed (which is only one `apt- get` or `curl` + `sh` invocation away) and your project does not depend on any external C libraries (except libc) then building a fully-static Linux executable is as simple as those two commands:

        rustup target add x86_64-unknown-linux-musl
        cargo build --release --target=x86_64-unknown-linux-musl

There are no hoops to jump through here. I can totally understand using Docker for something which can be a pain to setup a toolchain for or install all of the dependencies for, but for the Rust compiler I see very little reason for running it inside of a container except in a very few very niche cases.

<comment><USER19> At one point docker was the only way to do this, I think. So if you start searching the internet for how to do static linking with musl you're very likely to find links to the docker'd approach.

<comment><USER4> I don't think docker has ever been the only way to do this, but it is a popular one. It helps when you go beyond pure Rust.

<comment><USER19> Maybe not the only way, but it was the easiest and most widely recommended way when I was figuring out how to do musl builds around 2 years ago.

<comment><USER4> Huh, I've just been pointing people to [https://blog.rust- lang.org/2015/04/24/Rust-Once-Run-Everywhe...](https://blog.rust- lang.org/2015/04/24/Rust-Once-Run-Everywhere.html) for the last five years. Maybe someone was recommending Docker a lot and I just missed it.

<comment><USER19> Maybe it's the more niche use case of deploying to AWS Lambda before custom runtimes.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> " I've also found that programs seem more likely to work on their first run, but haven't made any effort to quantify that." Had the same experience with Modula-2, once I got all the compile errors cleared.

I think there is a real need for the current generation of business programmers to start focusing more on safety and rigor as they transition into IoT. For instance, I don't see most programmers I've worked with capable or will to use enough rigor to make autonomous cars safe. All these programmers have generally been slinging java for years, without even much effort to exposed themselves to other languages unless there is a business requirement to do so.

So the concern I have with Rust (as a newbie) is it isn't consumable enough to have it's value adopted by most business programmers out there, and I've wondered if Ada would serve that role better because it seems generally easier to grok percentage wise.

<comment><USER21> Whatever bad things you see in this world - it's done by java developers. Go, scala, kotlin, JavaScript, python developers would never do anything as bad as java developers. I see that a lot of people stick to that mantra.

<comment><USER22> Java is used on projects with more scale (business process complexity) than the other languages you list, though.

There are reasons for the things that are done in the Java community. We might not like the result, but there are reasons, and most of them have to do with scale and process at scale.

There are other ways to build out scale, but they may require different kinds of organizations to build them, with a different mix of people. Big Java projects tend to be structured to make efficient use of developers with 0-5 years of experience, because at scale those developers are reasonably easy to hire. Those developers need to colour inside the lines (=> framework, we'll call you, follow the patterns, don't invent abstractions), create code which can be tested in isolation (=> inversion of control), and have their output glued into position (=> dependency injection) in a much larger solution. Most of the structure of the Java ecosystem follows from this.

</comment></comment></comment><comment><USER23> I've been immersed in C++ at the office for over a year. It is a big language, but like all big languages one ends up finding the parts of it they need to use and get really good at it.

The more languages I learn, the more I dislike language zealots. They're great to leverage when learning, but they're blinded by their own opinions to see that they're making mountains out molehills.

<comment><USER24> I think part of the tension is that some people are in it for a better hammer, while others are in it as an end unto itself. PL is just plain interesting as a hobby interest.

</comment></comment><comment><USER25> I find it interesting that both Go and Rust, in practice, step on one of their relative foundational concepts. (2010: [https://blog.golang.org/codelab- share](https://blog.golang.org/codelab-share), for Go, and I suppose don't need to cite "safe system code" for Rust).

For example, Go community could have stuck to their guns about building server side concurrent code only using channels and value objects, performance impact be damned, and we would not have high performance server code written in Go (using locks and shared memory). And as OP points out, "system level" code written in Rust likely will have (possibly opaque) unsafe code segments.

Intent here isn't to rag on either language. It's more musing out loud about the impact of conceptual consistency in course of development on product success: is it a (practical) mistake to insist on it? Based on Go and Rust teams' decisions to date, it seems it pays to be pragmatic. (Or are we simply throwing the towel in too early?)

<comment><USER4> I'm not entirely sure. I think this line of inquiry is interesting, but I'm also not entirely sure that you're declaring Rust's original principles correctly. That is, the safe/unsafe dichotomy was always there. It's impossible to build real systems without it, and so I think that's why people gloss over it a bit.

See slide 16 of [http://venge.net/graydon/talks/intro- talk-2.pdf](http://venge.net/graydon/talks/intro-talk-2.pdf), the original presentation of Rust to the world.

<comment><USER26> Funny that the talk says "we are not rewriting the browser", given the current projects at mozilla.

<comment><USER4> I always took that to mean "we are not doing the Big Rewrite."

</comment></comment></comment></comment><comment><USER27> Recently we've added support to curate the Rust programming remote jobs at Remote Leaf[1]. We've seen a some surge in the Rust remote jobs in the recent months. Maybe because it's being accepted by a wide variety of developers and also hiring companies started using it?

[1] - [https://remoteleaf.com](https://remoteleaf.com)

</comment><comment><USER28> I see a lot of people comparing Rust favorably against C++, largely due to C++'s complexity. And yet at the same time, the Rust dev team are changing and expanding the language very quickly.

Is there any plan to feature-freeze Rust?

Otherwise it'll just become C++ 2.0 - a giant mass of features that are progressively designed to replace each other, until the language becomes too complex for any one person to master.

<comment><USER16> Notably almost none of Rust's new features are replacing old ones. Most of them are either opening up new capabilities (e.g. async-await), or making existing mechanisms more general/flexible (e.g. const generics, GATs).

It might accumulate cruft eventually, but I think it's at an inherent advantage over C++ due to its heavy functional influence, which is all based on math / PL theory. On the other hand C has always been a quick-and-dirty language, and C++ inherited a lot of that legacy.

The macro system also helps a lot, as features can be prototyped as macros, and only stabilised once the design has been iterated and used. More niche features can stay as macros in 3rd party libraries.

<comment><USER29> It also has years of crucial hindsight in language-theory. OOP and FP are both fairly mature at this point, and Rust started out of the gate by elegantly weaving them into a single coherent model, compared with C++ which started with _neither_ (C) and had to monkey-patch both of them on, over the very decades when the ideas behind them were most actively evolving.

</comment></comment></comment><comment><USER30> I've had a much shorter frame of time with Rust and I have to say I really enjoy the learning experience, and that is to say that learning the language is a pleasurable experience. Other languages with larger more established communities are often unable to replicate this same feeling of inclusion and value as a member of the ecosystem of contributors.

</comment><comment><USER31> A south african domain, but a blogger from seattle...

you don't see that every day :)

<comment><USER32> Hi, I'm the post author. As you guessed, I'm South African. I worked at Amazon in Cape Town in the early days of EC2, and live in Seattle now. A lot of core development on EC2 (and other AWS products) still happens in Cape Town.

</comment></comment><comment><USER33> Everyone always seems so positive about Rust. I'd love to try it for some personal projects. Are there any downsides beyond the niggle the author mentioned?

Are compilation speeds an issue for anyone?

Is there much that can be done to improve this? (Both in Rust itself and at a developer level; presumably a faster dev machine helps?)

<comment><USER18> > Is there much that can be done to improve this?

I have a 50k+ lines of code project which usually recompiles after a change in ~2 seconds in release mode.

There are many tricks which can be used to improve compile times to the point that even on medium-sized projects the compile time is not an issue. But you need to keep a certain discipline to adhere to these.

1) Use LLD instead of the system linker.

2) Don't add dependencies willy-nilly. Especially for trivial stuff which you don't need pedal-to-the-metal optimized. (e.g. do you really need to add that 4000 lines long SIMD-optimized base64 encoder/decoder, or can you live with a naive 10-lines long version you can write yourself in a few minutes?)

3) Feature-flag gate dependencies/features not necessary during development. (e.g. do you actually need HTTPS support during development, or can you test your webapp on HTTP and only compile-in the TLS stack for production deployment?)

4) Avoid heavy dependencies. (e.g. there are some popular web frameworks for Rust which have over 100+ dependencies by default; if you pick such a framework then your compile times are obviously going to be very heavily affected)

5) Use dynamic dispatch (&dyn T and Box<dyn T>) instead static dispatch (impl T) when accepting generic arguments in cases where you don't need pedal-to- the-metal performance.

6) If you absolutely need to use static dispatch purely for ergonomics (and not because of the performance) then create two function - a dynamically dispatched private one which accepts a &dyn T and contains the actual functionality, and a public one which accepts impl T and is a one-line wrapper around the private one.

7) Don't use #[inline] annotations if you don't absolutely need them.

8) Split your project into multiple crates.

<comment><USER26> > 6) If you absolutely need to use static dispatch purely for ergonomics (and > not because of the performance) then create two function - a dynamically > dispatched private one which accepts a &dyn T and contains the actual > functionality, and a public one which accepts impl T and is a one-line > wrapper around the private one.

Would you really recommend this as common advice? It seems like not a good idea to me. If all you cared about was binary size and compilation speed, maybe, but not otherwise. Same with blanketly recommending use of &dyn T instead of <T>. There are other problems with dynamic dispatch in rust, namely it's kind of a pain if you need to `+ OtherTrait` with it.

<comment><USER18> Yes I would. In general people tend to overuse static dispatch even when it's not really necessary. Of course the issue is a little bit more nuanced than "always use X unless Y" and there are tradeoffs in play here that need to be balanced.

For example, if your function is really small - yeah, it's probably fine to just use static dispatch. If you're writing a generic data structure - <USER2> most likely also want it to be a statically dispatched Struct<T>, but with a healthy dose of #[cold] annotated non-generic functions for the cold paths. However, let's say that you have a function that accepts a filesystem path and loads a PNG from it - you do __not __want the PNG loading code to be 1) duplicated in every compilation unit (compilation time bloat), and 2) monomorphised three times just because you passed an ` &str` once to it, a `String` another time, and a `PathBuf` yet another time (compilation time and executable size bloat), so you definitely do want dynamic dispatch here (at least under the hood with the two function trick).

I do think the default should indeed be &dyn T and you should only go for impl T when you can actually clearly substantiate _why_ you should use it, instead of the other way around which is the default now in the Rust ecosystem. (Which is how you end up with 20+ second edit-compile cycles one of the sibling comments mentioned.)

<comment><USER34> Could a proc macro be written that uses dynamic dispatch in debug and static dispatch in release? That would be optimal for dev compilation speed and binary speed, at the cost of binary size. It seems like a pretty good tradeoff for most cases.

<comment><USER18> IIRC I think there was a crate with a procedural macro like that which did something kinda similar to this. However currently that isn't really optimal for quite a few reasons: 1) having a procedural macro by itself pulls in extra dependencies, 2) it introduces extra work for the compiler so it does negatively impact the compile times (the procedural macros don't operate directly on the AST, so they have to parse the token stream into an AST, process it, serialize it back into a raw token stream, and the compiler has to parse it again), 3) Rust's current procedural macro machinery doesn't yet support emitting proper error messages from a procedural macro, so if you'll get an error or a warning from a piece of code generated by a procedural macro it will just point to the #[name_of_the_macro] annotation instead of the actual location where the issue originated from.

</comment></comment></comment></comment></comment></comment><comment><USER35> > The biggest long-term issue in my mind is unsafe

I'd say that, but for different reasons. It's depressing how often you have to use unsafe. I would not mind if it was hidden in libraries tested within an inch of their life 99.9% of the time, but it didn't work out that way for me. Recursively defined data structures like trees were just a nightmare to do without unsafe's.

I thought that was perhaps because I just sucked at Rust, but then I listened to a talk from one of the Mozilla core devs working on Servo. Their code had more unsafe's than mine. The amount of parallelism they were trying to get was extreme of course, so it wasn't really much of a comparison. It made me feel much better all the same.

</comment><comment><USER36> Seeing as the prime (and arguably only essential ^1) use cases for C are 1. O/S kernels and drivers, 2. embedded code for tiny microcontrollers, 3. language interpreters/runtimes and JITters, 4. bootstrap compilers, 5. portable command-line utilities, 6. low-level/mixed asm routines for performance, and 7. the large body of legacy apps of course, are there any examples for successful implementations for these categories in Rust? I'd imagine developing a nontrivial language runtime using Rust's memory model could be hard or impossible to do performantly. But that is or was the mainstay of C programming on Unix - implementing higher-level languages such as shell or awk.

^1: This is of course opinionated, but my reasoning for not including application code, and in particular long-lived evented or multithreaded app servers is that I personally think these are beyond C's memory management capabilities (even if you get malloc/free 100% right, there's still the problem of memory fragmentation) and are basically erratic outcomes of 1990's multithreading code originating from corouting in GUI programs

<comment><USER37> Don't C++ and Rust still have the memory fragmentation issue, since they have to use an allocator at some point?

<comment><USER36> Exactly. That's why I don't think close-to-metal languages are the way to go for _most_ apps (as in "C is _not_ a general-purpose language"), except the ones I listed, and probably some. I admire the Rust community's energy and persistence to create a new zero-overhead language, but, for me at least, they're ultimately falling victim to the idea that an app must be a single giant monolithic binary. C and Unix grew strong because of small little composable programs, where each program's memory was manageable enough in a way multithreaded, let alone async/evented server-like programs aren't (if they need dynamic memory at all). But ever since idk Java app servers? people have this idea that they're better at memory management than the kernel + MMU when that isn't clearly demontrated at all considering that eg. GC overhead isn't insignificant in long-running programs. What I'd rather like to see is bringing down process spawning overhead (response latency), or at least a rational discussion backed by benchmarks why everybody (except unikernel folks) blindly follows the big fat app server idea when, from the outset, a process-per-request model with memory/permission/resource isolation clearly looks much saner given service-oriented workloads and troubles in recent years (eg side-channel attacks, DOSing, leaks).

</comment></comment></comment><comment><USER38> This is only tangentially related to the article, but why does any discussion of Rust and/or Go asymptotically approach "RUST VERSUS GO RUST VERSUS GO", or at least have everyone and their grandma chip in on which one they prefer (like this very post)?

I'll admit that I only have experience with the former, but they seem like totally different beasts to me, intended for very different domains / target audiences. I figured that the holy war would be between Rust and the other trendy systems languages (Nim, Zig, Crystal) or between Go and other Web- oriented / glue languages (Java, Python, Perl, et cetera).

<comment><USER39> It's an accident of history and messaging. They were both publicly announced at the same time, and both described themselves as "systems programming languages."

As it turns out, the two languages have entirely different ideas of what "systems programming" means. And Go was announced very close to its 1.0 launch while Rust was announced very, very early in its development cycle. So in reality they actually align neither in timing, nor in target domain. Still, the initial contrast seems to have stuck.

The only real overlap is that both deign to be C successors. But in such different ways that the head-to-head comparisons make little sense.

There's also the perception that they're the only recently-created languages that have gained any real traction. You don't see nearly the ink spilt on Nim or Zig as you do on Rust or Go. So there's maybe some sibling rivalry there. (In this vein, I occasionally see comparisons of Rust vs Swift.)

<comment><USER40> Learning Go and Rust recently, it feels like Go is aiming to be a better Java(GC, excellent libraries, feature rich std library, fast enough but easier on devs) and Rust is aiming to be a safer C.

<comment><USER11> Its weird people don't compare Go to Kotlin. It has channels and coroutines. I think Kotlin does better with contexts and I think flows are a really cool addition. There does seem to be a lot there but honestly, it reminds me a lot of Go in its pick up and play nature

<comment><USER10> Maybe because on the JVM it is a guest language and on LLVM, Kotlin/Native is barely production ready.

</comment></comment></comment></comment></comment><comment><USER41> Is it just me and my 30" monitor, or is the font for this webpage extremely small?

<comment><USER42> Not just you. It's tiny. I also wish people would turn on hyphenation if they insist on justifying text on the web.

</comment></comment><comment><USER43> "I want off Mr Rust's wild ride."</comment>


Slip Coaches: Back When British Express Trains Detached Passenger Cars at Speed - <AUTHOR> https://99percentinvisible.org/article/slip-coaches-back-when-british-express-trains-detached-passenger-cars-at-speed/ <comment><USER2> The flight path of landing planes is often directly over my home. How many times I have wished during the final approach that I could hop in an personal landing pod or sky dive out, landing in my driveway, than take the extra hour or so that is required to deplane, get to transportation, and drive home... Slip air travel anyone? :)

<comment><USER3> Reminds me of Mad Jack Churchill, who in his later years would surprise fellow passengers by throwing his briefcase out the train window -- ostensibly into his backyard to avoid having to carry it home from the station.

[https://en.wikipedia.org/wiki/Jack_Churchill](https://en.wikipedia.org/wiki/Jack_Churchill)

<comment><USER4> Churchill was said to be unhappy with the sudden end of the war, saying: "If it wasn't for those damn Yanks, we could have kept the war going another 10 years!"

This made me laugh. His story is a really good read.

</comment></comment></comment><comment><USER5> The Aramis PRT system of the 70s was intended to do this with individual or 4 seat cars, accelerating and decelerating to make trains. But the control systems of the time weren't quite up to it.

</comment><comment><USER6> ...But could you match a platform to a slipcoach's velocity?

<comment> cup-of-tea I remember reading a proposal for a system where a high speed train would travel non-stop for the entire length of its route. In halfway towns a shuttle would be sent out to match the train's speed, interface with it to exchange passengers then detach to return to the halfway town platform.

It sounds unbelievable, but remember it was once considered insane to consider building a railway between Liverpool and Manchester.

<comment><USER7> The problem would be the scheduling. Even at the best of times railways rarely run on the kind of precision that these kinds of operations would demand. Plus it'd require a lot of duplicate railway since presumably it would take distance for shuttles to accelerate and decelerate, and the shuttles would need to get back to the original stations in time for the next trains.

<comment><USER8> > The problem would be the scheduling.

Not in Japan.

</comment></comment></comment></comment><comment><USER9> I always figured the solution to this problem was buses. Take a bus and drive it alongside the running train, then merge it sideways into a C-shaped train car frame that accepts it and lifts it up. Now the bus is just another train car. At another point along the route, it can be set down, and un-merge back out again, and ply the streets again.

</comment><comment><USER10> They used to do this India till at least 15 years ago.

<comment><USER11> As an Indian who used to travel in trains quite a lot, this is news to me. Was it only for particular routes? And sources I can read?

<comment><USER10> [https://www.quora.com/What-is-a-link-express-train-in- Indian...](https://www.quora.com/What-is-a-link-express-train-in-Indian- Railways)

</comment></comment></comment><comment><USER12> Splitting for different destinations also seems useful. If one is to walk the transfer time must be that of the slowest passengers. I lose 2 times 20 min like that twice per day.

<comment> cup-of-tea Many trains in Europe split up and go in different directions. It's something you have to be aware of so you don't end up on the wrong one.

<comment><USER13> Reasonably frequent for London trains heading to the coast (e.g. Brighton)

<comment><USER14> The phrase in announcements for these trains will be e.g. "This train divides at Southampton. Passengers for stations to Poole should be in the front 5 cars of the train".

Because (as described below) these trains are actually constructed from Multiple Units, the train can only be sub-divided if it in fact consists of two or more smaller trains, for example 450s come in multiples of 4 so a 12 car train could divide into three. Some designs offset the driver's cab so that a gangway for passengers fits through the "nose" of the train when it's connected. In other designs you must leave the train and walk along a platform to pass the point where the trains are joined.

<comment><USER15> On one UK journey from Portsmouth to Preston (Virgin Trains on Sundays), the train would divide en route and the rear half continue to Preston and the front half would go to Manchester.

One time, the conductor announced - several times during the first part of the journey - that due to an electrical fault in the rear half of the train (no lights), that part would go to the depot in Manchester, and the front would go to Preston, so when the train stopped for splitting, please would everybody swap carriages and make sure they were in the right half.

Needless to say, a few minutes after our section was on its way to Preston, a few fretful discussions that included the phrase "...didn't you hear the announcements?..." could be heard, followed by the odd expletive.

On another occasion, my train left London Victoria for (I think) Brighton, Bognor Regis and Southampton Central (a double split to make 3 x 4 coach trains), and the announcement went something like...

"This is the xxx train to Brighton, Bognor Regis and Southampton Central. Due to a fault, this train is composed of 10 coaches instead of 12. This train divides on route so please make sure you are in the correct part of the train; the front 4 coaches will call at....the rear 4 coaches will call at....and the middle 4...oh we've only got 10..oh, how are we going to do this...erm...hang on I'll have to have a think about this...."

I don't recall the outcome!

<comment><USER14> Southern has a bunch of different variants of class 377 in different lengths, so presumably your 12 cars would have been 3 x 4 car length 377s.

Depending on what they had spare ("due to a fault") the 10 cars might have consisted on 2 x 3 car plus 1 x 4 car, or of 2 x 5 car configurations.

In the latter case obviously the train can't split three ways, that's impossible. I would expect that for your service they would choose to run the train to Brighton, then split it and run half to Southampton Central, half to Bognor.

To be fair this route actually could be served (albeit with a little delay) by a single train, there's no huge divergence along the route to serve all of them, it's mostly that it'd be a pain to get back out of Bognor heading for Southampton, the signaller may not want to allow the relevant movement (crossing from the up to the down side, or reversing on the down side) and the driver may not be trained to do it even if a signaller will signal it.

</comment></comment></comment></comment></comment></comment><comment><USER16> There is no reason this can't be done for modern rail systems. It would greatly improve efficiency and time schedules. But alas, innovation in rail has been very incremental (HyperLoop aside), and practically non-existent in the States.

<comment><USER17> Rail systems shine when they can concentrate steering an power in more efficient dedicated locomotives, with as many "dumb cars" as possible "automatically" following them (thanks to the rails).

But in order to achieve higher granularity and better schedules, cars would have to become more autonomous, which means duplicate steering systems and lower efficiencies... unless there were no efficiency benefits in having a dedicated locomotive, in which case it would make no sense to join cars together in the first place.

<comment><USER18> Dedicated locomotive? That's true for things like diesel freight trains, but most high speed electric trains have motors in every car because electric motors scale down just fine.

<comment> cup-of-tea Most, if not all, high speed trains operate as "train sets". They don't split arbitrarily. Some like ICE use smaller sets that can join. Others, like Eurostar, are fixed.

Some inner-city rail in Europe is like you describe but not anything high speed (>~100mph) AFAIK.

<comment><USER14> The technical term you're looking for is "multiple unit", and you're correct that in a multiple unit it is not possible to arbitrarily couple together arbitrary carriages, re-arranging the multiple unit is possible only at dedicated maintenance facilities and may require a complete refit.

However everything else you've claimed is wrong. The designs you're talking about DO have motors under many (or in some cases all) passenger coaches driving the wheels, rather than a dedicated "locomotive" so they support your parent's point, not yours.

The original Eurostar (class 373) trains are confusing because they're built as multiple units but the lead and trailing cars basically just provide traction, so the result looks a lot like a "conventional" locomotive plus carriages. But modern Eurostar (class 374) looks exactly like any other multiple unit and has motors distributed across the whole train.

Britain does operate a bunch of locomotive pulled high speed (125mph) services, but it also owns a bunch of 125mph multiple units. Even the Desiro 444 and 450 trains could do 125mph if not for the fact they're configured exclusively for third rail power limited to 100mph.

The reason none of those trains exceeds 125mph is purely down to legal/ safety considerations. Britain uses coloured light signals with route control, as speeds increase drivers struggle to correctly interpret and act on a light signal by the side of the track. HS-1 (Eurostar) and many European high speed services have in-cab signals, so the driver doesn't need to try to observe fixed coloured light signals at the side of the track, the indications are inside the cab with them.

As well as the reasons given earlier about improved performance from distributing the traction power across the train, distributing the weight also improves crash performance. Heavy locomotives will tend to crush a lightweight passenger car, if we make all the cars of more similar weight this problem goes away.

<comment> cup-of-tea > However everything else you've claimed is wrong.

Eh? I didn't say anything at all about where the motors were.

You're the second person in this thread to imagine me saying something wrong and call me out on it.

<comment><USER14> You wrote:

> Some inner-city rail in Europe is like you describe but not anything high > speed (>~100mph) AFAIK.

That's referring to a post which claimed:

> most high speed electric trains have motors in every car because electric > motors scale down just fine

The examples you gave were ICE and the Eurostar, which are groups rather than specific classes of high speed train, but in both cases the modern classes have motors in every car, they specifically _disprove_ your claim.</comment></comment></comment></comment></comment></comment></comment>


2020 Knuth Prize is awarded to Cynthia Dwork [pdf] - <AUTHOR> https://sigact.org/prizes/knuth/citation2020.pdf <comment><USER2> I took a class senior year with Cynthia which tried to cover some of the things that she had discovered. One of most surprising things about her work is that she brings this full algorithmic firepower to problems that I had always considered outside the realm of mathematics - fairness and privacy. Some of her greatest achievements, I think, are figuring out what problems to solve (and of course solving them). She really stood out as one of our best faculty even in a very crowded room.

<comment><USER3> On a side note, I notice you call her "Cynthia" instead of Professor or Doctor. I've noticed other Harvard students do this with other professors too.

Is this a typical Harvard thing?

<comment><USER4> At least in the US, having a Ph.D. and insisting on being referred to as "Doctor" is considered a real asshole move. Usually one might address the person once as "Dr. Whatever", but they will invariably reply, "Please, call me Jane".

Even referring to someone as "Dr. Whatever" in the third person is pretty unusual, if you've ever met them. If I was to speak of my college professors right now, I certainly wouldn't use "Doctor". Maybe if they were 70 or had a Nobel or something.

(Related: In the movie Avatar, one scientist introduces himself to another scientist as "Doctor Norm Whatever". It absolutely clangs, at least to my ears.)

<comment><USER3> If you know them sure. But for a professor who I took a class with? I would always call them Professor Whatever if my only interaction with them was in a classroom context.

<comment><USER5> Maybe a generational thing? Not sure when you went to school, I went to a midsized state school 3 years ago and mostly referred to professors by their first or last name. I think this is more common in CS perhaps? I don't think my physics friends did the same thing as often though.

</comment></comment></comment></comment></comment><comment><USER6> I really liked Dr. Dwork's Turing lecture:

[https://www.youtube.com/watch?v=vsA4w3itxA0](https://www.youtube.com/watch?v=vsA4w3itxA0)

It's an introduction to differential privacy to an academic audience (i.e. not necessarily computer scientists). I sweeps across a range of surprising real- life privacy attacks that are possible against anonymization approaches that feel good-enough. Really gives you a sense for sort of problem that privacy protection is in today's world of greatly increased data collection and computational power.

<comment><USER7> Thanks for the link to the talk, it was really enjoyable and informative!

</comment></comment><comment><USER8> As an interesting example of what differential privacy is, consider this excerpt from Wikipedia:

"A simple example, especially developed in the social sciences,[15] is to ask a person to answer the question "Do you own the attribute A?", according to the following procedure:

1\. Toss a coin.

2\. If heads, then toss the coin again (ignoring the outcome), and answer the question honestly.

3\. If tails, then toss the coin again and answer "Yes" if heads, "No" if tails.

(The seemingly redundant extra toss in the first case is needed in situations where just the act of tossing a coin may be observed by others, even if the actual result stays hidden.) The confidentiality then arises from the refutability of the individual responses.

But, overall, these data with many responses are significant, since positive responses are given to a quarter by people who do not have the attribute A and three-quarters by people who actually possess it. Thus, if p is the true proportion of people with A, then we expect to obtain (1/4)(1-p) + (3/4)p = (1/4) + p/2 positive responses. Hence it is possible to estimate p.

In particular, if the attribute A is synonymous with illegal behavior, then answering "Yes" is not incriminating, insofar as the person has a probability of a "Yes" response, whatever it may be."

<comment><USER9> Not only is this differentially private, it's locally differentially private, which is an even stronger privacy definition. It's "local" because the user adds randomness themselves. Generic differential privacy is a weaker definition because it lets whoever's running the algorithm collect raw data and then add randomness somewhere in the computation pipeline to produce privatized outputs.

This kind of example also predates the definition of differential privacy by about 40 years [1], although the motivation is pretty much the same.

[1] [https://www.jstor.org/stable/2283137?seq=1](https://www.jstor.org/stable/2283137?seq=1)

</comment></comment><comment><USER10> Basically invented Proof of Work (see Bitcoin):

Cynthia Dwork and Moni Naor. Pricing via processing or combatting junk mail. In Proceedings of Crypto, 1992\. Also available as [http://www.wisdom.weizmann.ac.il:81/Dienst/UI/2.0/Describe/](http://www.wisdom.weizmann.ac.il:81/Dienst/UI/2.0/Describe/) ncstrl.weizmann_il/CS95-20.

</comment><comment><USER11> Is anyone aware of any work for how to apply differential privacy to language models?

So the main question I have is let's say I'm working with sensitive data like emails or doctors notes. How can I train an ML model that would still learn something useful without leaking private data.

When I say "leak", an example would be I train an RNN on some company data email data and when I feed the RNN "$AMZN" the network would say SELL.

How can I quantify how much the model has learnt and how much privacy has been leaked.

<comment><USER12> Check out Han Song's (MIT, most well-known for NN compression) Lab new paper on gradient leaking and follow-up work. [https://arxiv.org/abs/1906.08935](https://arxiv.org/abs/1906.08935) I attended a talk by him recently and was very impressed by the work of his lab in this area.

</comment></comment><comment><USER13> Original DP paper remains a great read: [https://www.microsoft.com/en- us/research/publication/differe...](https://www.microsoft.com/en- us/research/publication/differential-privacy/)

<comment><USER14> This is not the original Differential Privacy paper, this is an invited talk (I agree with you that it remains a great read). However, the original paper is "Calibrating Noise to Sensitivity in Private Data Analysis"[1] with four co-authors: Cynthia Dwork, Frank McSherry, Kobbi Nissim, and Adam Smith.

[1]: [https://people.csail.mit.edu/asmith/PS/sensitivity-tcc- final...](https://people.csail.mit.edu/asmith/PS/sensitivity-tcc-final.pdf)

</comment></comment><comment><USER15> Anyone else find it funny that the first paragraph of a Knuth Prize announcement writes "treat like alike" instead of ``treat like alike?''

<comment><USER16> More accurately, the _typeset_ output has "treat like alike" instead of "treat like alike", which suggests that the TeX _input_ (most likely) had "treat like alike" instead of ``treat like alike?''. Some historical context that led to features like this (or gotchas, today) in TeX and other systems of the time is here: [https://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html](https://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html)

<comment><USER17> I kept reading and re-reading 'treat' \- 'like' \- 'alike' trying to figure out where the difference was.

For those left wondering -- it's the first double-quotation mark leaning the wrong way in TFA.</comment></comment></comment>


LaTeX Table Generator - <AUTHOR> https://www.tablesgenerator.com/latex_tables <comment><USER2> Can someone help in setting up LaTeX on Android?

</comment><comment><USER3> I used it for my thesis in the past, pretty useful tool and time saving</comment>


Merit-Based News has arrived: Social news fueled by the submitters' puzzle solving abilities. - <AUTHOR>

There's no voting here. Rather, the point score of a submission is equal to the submitter's Numbrosia Puzzle score from the last 24 hours divided by the number of submissions made by that submitter.
http://numbrosia.com/?cmd=puzzle_n
http://numbrosia.com
Note that it makes sense to delete submissions so that the set of submissions associated with you is not too large (so that the score for each submission is not too low). <comment><USER2> It's an interesting concept, but practicality wise it looks like a stillborn.

Why not just tie it to their FICO score for yet another more random solution? At least the person can have a life outside of solving esoteric puzzles all day long.

</comment><comment><USER3> Interesting for a proof of concept project, but totally useless in the real world where one of the obstacles to get a successful social news site up and running is to get submissions.

Besides I don't see a strong correlation between users ability to solve a puzzle and their ability to find and post interesting content. Which would result in a pretty random front page...

</comment><comment><USER4> What is my motivation to spend time solving puzzles?

I've got my hands full starting a company.

I hate to sound negative, but I don't think that the folks who have that time to solve puzzles have the appropriate judgment to figure out what I might want to read.

<comment><AUTHOR> Some of the Numbrosia Puzzle players obviously have very high IQs and it would be interesting to see what they think is worth reading.

Moreover, if they have lots of time to play with puzzles, maybe they have lots of time to keep up with the latest news as well.

</comment></comment><comment><USER5> Mensa has always been the canonical example of a Groucho Marx punchline: A club that I don't want to belong to, because it would accept me as a member.

This looks like more of the same. I'm not interested in pretending that the ability to solve puzzles is some sort of overall mark of quality, instead of just a specialized skill that is irrelevant as often as it's relevant. I've had more than enough of that attitude. I spent _years_ in high school and college being exalted for my skill at constructing complex solutions to toy problems, as if SAT scores were the true measure of wisdom, or competence, or virtue. They aren't.

</comment><comment><USER6> Interesting idea, but the problem is many people use social news as a quick way to view/post/discuss things. The time involved in solving puzzles offsets that convenience, i.e. it can discourage posting because of the time necessary to make your post heard.

Though it would be funny to see porn sites have you solve a puzzle to view some pics :)

<comment><USER7> That's actually a common method for breaking captchas...

</comment></comment><comment><USER8> Imagine hordes of offshore spammers solving this puzzle all day long for fun (and profit).

<comment><AUTHOR> How smart are these offshore spammers though? Presumably smart people would find better work?

<comment><USER8> Based on what I see on my site they are pretty smart and very determined.

I think you should make it truly merit based - submit a bugfix or a feature patch to an open source project to post a link :)

<comment><AUTHOR> You can vary the task based on the sort of news site you would like to have. To compete with programming.reddit.com, you could use merit-based news with your suggestion.

As for puzzle solving, you can make the puzzles really difficult to eliminate the vast majority of spammers.

</comment></comment></comment></comment><comment><USER9> What's wrong with voting?

<comment><AUTHOR> It's easily gamed and does not consider the intellect and/or knowledge of the voter/submitter.

Moreover, as suggested by gaika, one can use merit points from useful contributions to society instead of puzzles/games (e.g., contributions to open source projects).

</comment></comment><comment><USER10> It looks like this can be brute forced because its in javascript...

</comment><comment><USER11> The homepage is scary.</comment>