I suspect a large part of this is due to the fact that those with wealthy parents are more likely to have a) family money to fall back on if things go wrong and b) family investment in the early days
Everyone else has to seriously consider the (high) risks of their startup failing and not being able to afford rent, or whether their idea is worth burning their life savings.
It's also highly cultural; if the people around you that you see as role models are serious about business, connections, management, etc. that's what you pursue. And higher management comes more naturally to people who have spent their childhood in an ethical framework that divides people into manageable units, too.
My working class / middle class parents just didn't have room in their worldview for having employees, nor would they feel comfortable delegating their household aspects to maids and the like. When we had kids my wife and I couldn't imagine having a nanny (despite being able to afford it) while many of those around us didn't blink at it.
I remember working at a startup in the 00s and having to peel out of the office every day at 5:30 to get my daughter from daycare and my (silver spoon raised) boss saying something like "we need to pitch into get you a nanny" and it struck me then how that kind of thing was really tied to "entrepreneurship." I didn't _want_ a nanny, I liked my daughter's daycare, and I very much enjoyed picking her up and getting my hug at the end of her day of play and learning with a group of kids.
Connections, money, yes, but also a managerial/directive ethic, no qualms about telling other people what to do and paying as little as possible for it.
You forgot the family network. Zuckerberg père is a prominent Westchester dentist. Easier to find decent lawyers and accountants when you grow up in that sort of environment. Apparently, Zuckerberg met Sandberg at a party, hosted by a mutual friend.
If you had read the article, you would have seen that it's exactly what they say : “A strong economic base may benefit those interested in setting up a start-up, providing an economic safety net in the event of failure,”
Your parents don't even have to be wealthy. Just having parents who are financially stable, own their house, could literally keep you off the streets and give you food if you fell on truly hard times, makes an enormous difference compared to not having that.
And support for when it doesn't go to plan. An entrepreneur parent will empathize, as odds are they've experienced setbacks themselves.
Most ideas and first attempts fail, I'd imagine people are more likely to try again if they're not catching flak from their parents that they didn't get it right the first time.
> Pyston is a faster and highly-compatible implementation of the Python programming language. Version 2 is currently closed source, but you can find the old v1 source code under the v1.0 tag in this repository.
Yes, it does seem that it's incomplete and only documents v1 of Pyston.
That's bizarre. I just looked at the app and they support contacts-only limits for everything (voice, presence, profile photo, forwarded messages) _except_ for regular messages.
You can't reject images from non-contacts either. It's either images from everyone or nobody.
Does your chats list get filled up with these unsolicited messages from randos?
It seems like they should at the very least offer a mechanism to accept a contact request before any messages can be sent.
It's also an interesting example in the vastly different experience that different demographics can have in an app - say, women, or minorities often the recipients of abuse - and how blind an app maker can be to that experience if it's not intentionally studied.
> Does your chats list get filled up with these unsolicited messages from randos?
It was, then telegram desktop popped up with "it appears you are getting a lot of messages, would you like to automatically mute + archive those not in your contacts" or somesuch. Still, the archived folder is at the top
The only thing that stopped it was deleting my message from the community. Guess I won't be participating again :(
It certainly is an interesting example - I know nothing of their team, however things like this are also another reason as to why a diverse team is important!
In Settings / Privacy and Security / Blocked Users there's a "+ Block User" option. Clicking this brings up a list of all chats and people who have messaged your directly. Selecting a name blocks a user.
Maybe even easier is pressing and long holding the name of someone who has sent you a message. In the vertical dots menu is then an option to block the user.
I'm running v7.1.3 from F-Droid.
I do agree though that an option to block direct messages from those not in my Contacts, or at least some kind of review process to allow a specific message from someone not in Contacts, could be a nice addition.
It does. If you block people sending spam, they won't be able to contact new people. They will have to wait people to contact them to engage the conversation.
I actually am a shareholder of CenturyLink, I really don't care if you think that's satire, as long as the people we put in charge do everything they can to make it happen.
I'm really enjoying my Razer Blade Stealth! Powerful, has a nice feel to it. I was looking for something similar to my old Macbook Pro, but without buying a Macbook - this was the closest I could find.
Runs Linux really nicely + as far as I can tell everything works. Also, the screen is gorgeous!
You make the sacrifice of a "punishing" compiler, and spending more time writing code, but you gain software that's more likely to be "correct", safe, and not leak memory.
Really, as in all things computers, it depends what your set of requirements are as to what trade offs you make
There's some tradeoff there though. I'm doing most of my dev in C++ and run all the time with ASAN / LeakSanitizer. I have a leak-causing mistake, what, twice a year maybe ? Definitely not something worth loosing sleep over.
The much bigger problems imho are not really tractable. e.g. consider something that does:
there's no "leak" in the OS sense as everything will be reclaimed upon server::~server... but your memory usage will be strictly increasing. Can Rust detect those cases ? As in my experience this is the most common leak pattern (of course not in a simple example like this, but when your "server" architecture starts being split across multiple threads and source files...
In your example you are iterating over `m_requests_to_process`. As you are using `auto` instead of `auto &` it automatically clones the elements of a vector. In Rust, it's not possible to clone an element by accident. Objects are moved by default (think `std::move`) and if you want to clone instead you need explicitly use `.clone()`.
If `do_stuff` function takes ownership of a request (as in, if it takes `Request` parameter and not `&mut Request` parameter) than the problem will be pointed by Rust, and so the compiler wouldn't allow you write code like this forcing programmer to write code that removes elements from the list to take ownership of them. For example:
for req in mem::take(&mut self.requests_to_process) {
do_stuff(req);
}
`mem::take` (https://doc.rust-lang.org/std/mem/fn.take.html) replaces an object behind a mutable reference with a default value for a given type (empty vector in case of vectors) and gives you an ownership over vector.
You don't even need `std::mem::take`, you can just `drain` the `Vec`. This also allows the allocation to be reused, unlike your `mem::take` which ends up dropping the allocation.
struct request {
int id;
double parameter_value;
};
surely moving does not gain anything - the original vector object still keeps the memory allocated, right ? sure, if you have complex requests with substrings, etc, but in that case I'd have `const auto&`-ed :)
(from my experience going full-throttle on movability when C++11 came out, I'd say that this was a mistake overall, much better to keep things as const& most of the time if you can. I've not yet reached a state where I consider the need for ownership transfer a code smell... but not very far :-))
With the implementation your parent posted, the entire vector would be replaced with a fresh one. So the original vector would be deallocated entirely.
You could also do something with the drain method (which they posted originally and changed to the current implementation, not 100% sure why) and that would keep the memory around, yes, but then you'd be with only the high water mark of the number of requests, because it would be re-used.
Rust does not attempt to stop leaks. It does make it less likely to happen, but completely preventing them is not even on the table.
This particular case might be because you would probably consume the vector in the loop, which would free, but you could absolutely write the exact same code in Rust with the same end result.
Although I haven't verified this myself—I'm not much of a Rust wizard—I've heard that Rust's type system and borrow checker allows you to spend less time total, because your debugging time drops significantly.
Verifying that would be incredibly difficult/impossible but I've personally found that rust has on multiple occasions prevented me from making a mistake that would have cost likely hours to debug that I was instead able to fix in a few minutes.
Curiously, I’ve never seen anyone in forums take this premise to its logical conclusion and advocate the use of a language which has a much more powerful type system than Rust does, like dependent or refinement types. Haskell, Scala, Idris, and others (even Python with crosshair!) natively or with extensions support enforcing some very sophisticated constraints on a program. Tagged unions and interfaces are hardly the limit of what’s possible. However, I don’t think cutting edge type systems, theorem provers or other sophisticated tools for program validation have demonstrated enough business value to receive widespread adoption outside of only some (albeit very important) market sectors.
Really, I think most argumentation comes down to “the type system of the programming language I want to use anyway is the right one, and everything else is wrong”.
I lump this into the category of learning how to best apply your tools to the right situations.
If I'm slinging together an internal CRUD app, the extra time thinking about types probably will slow me down because the major risks aren't really type problems.
But if for example I'm working on something in a game engine, being able to use the language and compiler to enforce assumptions/invariants at compile time is really useful.
Perhaps compared to Python, Ruby, and vanilla ES6; there is a class of epsilon-from-typo bugs that modern statically typed languages catch and that force rigorous Python and Ruby shops to waste time writing vast batteries of tests for the most banal functionality in their codebase ("does this setter set?").
Moving from one of those languages to a modern statically typed language can come with a feeling that your programs tend to run successfully as soon as they compile --- certainly they do more often than they would in Ruby. Because the compiler is doing some of that testing work for you. It's a good feeling.
But it hasn't been my experience that the extra rigor in Rust's model produces the same boost from Java or Go; in fact, my first-run experience with Rust is generally less reliable than Go; there are a few more things that can go wrong with a Rust program and slip by the compiler.
Which is what you'd expect; Rust isn't garbage collected, so the programmer has to do the garbage collection, and every program is responsible in some sense for designing and implementing that part of its own runtime. There are things you can get wrong there that GC'd languages don't make you bother trying to get right. And, of course, if you take the time to get your per-program runtime really right, there's a performance gain to be had from doing so. It's all tradeoffs.
> Which is what you'd expect; Rust isn't garbage collected, so the programmer has to do the garbage collection, and every program is responsible in some sense for designing and implementing that part of its own runtime.
This seems like a really odd thing to say in at least two dimensions. Firstly, I would say that "the programmer has to do the garbage collection" isn't an accurate way to describe Rust. Secondly, and particularly in comparison with Go, Rust's RAII applies more universally than Go's garbage collection. How many times have you seen a missing defer or a defer inside of a loop? I've seen both quite a bit. But those bugs basically don't happen in Rust precisely because the programmer almost never needs to deal with destruction directly. It's done automatically by the compiler.
As to the broader point, I would very strongly oppose the notion that Rust is less reliable than Go. While I don't think I would argue that Rust gives the same boost over Go that, say, Java or Go give over Ruby (that's a tough argument to make anyway, even if I agreed with it), I would say there is a meaningful boost. But that's a tough argument to make too. Aside from the obvious bits (nil errors and forgetting to check errors), for me, it basically comes to my belief that Go punishes its practitioners for abstraction. I wrote a bit more about that here: https://users.rust-lang.org/t/what-made-you-choose-rust-over...
The RAII vs. defer thing is a point well taken. Also, the kind of thing that doesn't show up in the totally-informal "how many of my post-hoc tests pass the first time I get them to compile" metric.
Another point, which to your credit you didn't make but which is nonetheless true, is that I am not a good Rust programmer!
I don't think Rust is less reliable than Go in the large. I do think there are more things you have to get right in a Rust program than in a Go program, so it's "less reliable" in that weird twilight state when you're first bringing up your program.
I do agree that Go punishes practitioners for abstraction. If you're, like, you, that's a very bad thing. If you're working with a team of people for whom the project is a means to an end and not a brilliant-cut gemstone, putting the brakes on abstraction can be a good thing, which I think a lot of Rust programmers will quickly learn after the nth time they've had to do an edit-compile cycle just to `let () = something` to figure out a type.
FWIW, my experience when it comes to Go and its abstraction limitations _is_ in the context of collaborating with others on a team at work. That's where we feel the limitations of abstraction pretty acutely. Because it means we, to a lesser degree, cannot build APIs that are harder to misuse.
The point about having too much power is taken, and I don't have experience with that in a team context. And yeah, I am not exploring the Rust downsides as much here, and there are definitely others.
Fans of static type checking use that as a rebuttal against "but I'm so much more productive in $dynamically_typed_language". I've also seen it in discussions about Scala, Haskell, TypeScript, etc.
Intuitively it makes a lot of sense, and it jives with my subjective feelings (especially for longer-lived projects), but I'm not sure if there have been any studies to back up that claim.
From an organizational perspective, the benefits of static type checking are quite obvious. I'd go so far as to say it's a software engineering best practice to prefer languages with static types when building new software. The reason for this is because many, many, many engineering hours are saved at an organizational level by having a compiler that is able to enforce correct data structures throughout the application. Eschewing types for speed is just a form of technical debt that has to be repaid in perpetuity whenever it comes time to maintain or refactor the software, not to mention the fact that every new developer working on the application is now burdened with this debt.
I am not aware of any studies that definitively show an advantage for static or dynamic typing; there have been ones that didn't provide anything conclusive, and you could argue that the experiment design wasn't representative.
The issue here is that paper tests require the user to read and properly understand instructions. Teenagers in a panic can and will misread and misunderstand, as people often do when under duress.
It may seem "pointless", but making the tests more user friendly and less prone to user error is super important.
Here is a paper showing how these tests have 99% sensitivity in the lab, but this drops to 91% when the test is read in the field by a volunteer, and down to 75% when the test is read by the subject themselves:
Moreover, if it's such that even a trace of a line indicates a high confidence of pregnancy, users may misinterpret a faint result as somehow meaning "kinda" pregnant.
I wouldn't say super important. I'll probably get down voted for my opinion, but if we had proper sex education for everyone and valued women's health care than this wouldn't be an issue.
I don't think that sex education and accessible abortions stops people from being emotionally invested in finding out if they are pregnant. This can be a stressful question whether you want a child, don't want a child, or don't know!
Teenagers were specifically mentioned in the comment. Good sex education helps because reproduction is now not some mysterious process. They will then be able to make good choices when they decide to sex. Having access to abortion services helps because having sex shouldn't ruin someones life.
I don't think that anyone was arguing those points. simply that they wont eliminate the stress associated with test taking, which is the purpose of this device.
I recall us doing this a couple of times when I was at Etsy (2012-2015). I think we did it with Github as well.
The thing to keep in mind is that accepting non team members and getting them meaningful work to do was already part of Etsy's culture. New engineers would bootcamp with a team for a couple of weeks when they joined. So the culture was already set up for this - managers and team members knew what to expect from a teammate who may not be a domain expert.
I think the way to start a program like this is to start with an internal bootcamping type program and learn and make mistakes through that.
What kinds of problems would you face in creating a news app? Surely content delivery is the same as that through the web page and for displaying the content you just use some cross-platform UI library?
(From somebody on the outside with absolutely no idea.)
There's a little bit more to our news app than content delivery, even though content delivery is indeed the crux of the problem. Regarding the content itself, it's a more complex than a wall of text, so we need support for each type of content. Our content is also served differently for the website and for the mobile app as we've got an API in there, though both the website and the mobile api are communicating with what we call the content API.
Both the Guardian and the BBC have separate iOS and Android teams, I'm part of the server side team. We touched about how to organise the teams, how to handle request from editorial, how to test and release the app etc.
In the lingo, a "news app" is typically some sort of interactive presentation of one particular story, and depending on the story may allow the user to filter or visualize something from a database, it might change the information based on where you live and it can include interactive maps or charts or calculators or even mini games to illustrate a particular concept. So these are one-off projects made to deadline, not a generic mobile app for reading the news.
That wasn't part of these exchanges, but yes we produce the tools for that in house.
The Grid is a good example of what's been produced in house, and it's actually open source (and I think being used by the BBC?) https://github.com/guardian/grid
Huh, interesting idea... I guess such a thing could be quite interesting for some short form updates (i.e. live from a conference). You'd probably want that to go through some kind of editor right? I just assumed it would be a news-reader/viewer.
We do indeed have what essentially is a text-editor with Guardian specific features developed in house.
It's used for all of our content, but specifically what you're referring to are liveblogs, where a journalist can write short content and append it to the existing article.
Cross company is awesome but even better would be cross team within the same company. No single thing could do more to break us v. them thinking and silos than this imo
We have an infra rotation program, where application and service programmers can spend a quarter or two working under product infrastructure on whatever their infra passion is. It’s great to see somebody’s passion for a big change boil for a year or two, and then they rotate in and are given the authority to make that change.
That being said, I’d love to see people rotate between application and service teams. Some applications and services are years ahead of others in terms of their maturity and scaling problems/solutions, so there’s a lot of tacit knowledge to be spread. We have a monorepo so self-starters can read code and commit messages, but a formal program would really help accelerate and democratize the knowledge spreading.
Yeah my former company would have benefit a ton from something like this. I guess it takes a culture to make this a thing. Instead we just built abstractions around the “other” team’s product so that we didn’t have to deal with their bugs or tech debt.
It uses YOLOv4 to find license plates, and then opencv to blur them :)
Happy to answer questions!