Ask HN: Any framework to manage tech debt, increase quality – for small teams - <AUTHOR> Am trying to find if there any reference process framework/guideline that small engineering teams could follow, to improve their engineering practice quality, in short, near and long term windows.
I have used the 12 step Joel test as a basic reference in a few places and found good success.
I am now dealing with a totally chaotic environment. (Think wild west of the olden days - no rules, no law) Seems like a daunting task, to carve order from chaos, but I believe it is doable.
Am sure many of us here would have dealt with such stuff. I need the help in form of larger wisdom of practitioners.
Please suggest! Thanks! <comment><USER2> I've worked at many startups and a high level principle i've found useful is "introduce process when not doing it hurts more"

\- you could just work on flat files and sync with Dropbox. But losing history and context hurts. Introduce version control.

\- hurts more to host your own git than just paying GitHub/GitLab. Do that.

\- Small prototype for startup. Don't need tests. That's cool. Ship to production directly. Now you have customers and shit is regressing and pissing customers off. Introduce CI so every merge with master has some level of quality.

\- Now you have multiple team members all committing code at various levels of quality. Make sure they reviewed by people who have code context and know what good code is. Pull requests and reviews for merges.

\- people don't know what to do. What is highest priority? what is the scope? what are the unknowns? how long will things take? Introduce something like trello or any other task management system. Work against goals broken down into tickets and plan in small increments.

\- shit goes on fire occasionally. Have an oncall rotation. Monitor metrics and alert if something needs investigating.

<comment><USER3> This is definitely a good approach, totally agree with it.

It is bad to introduce too much process too early, and a good measure of when you need it is when the pain of not having it exceeds the pain of the process. I really dislike unnecessary process, but as you grow different processes become necessary and they make life easier and more predictable.

It isn't rare to have the wild west at a startup in the early days and it isn't rare to lose a few people when you start putting in necessary processes because they don't want the constraints. One of the most valuable lessons I have learned over the years is that it is healthy when people leave that aren't on the same growth path or maturity of the organization. Don't fight to keep people when this is the case, it just adds stress to the organization and people internally know that the person isn't a good fit anymore. So let them go. Hard thing to do sometimes, but necessary as companies grow and mature.

<comment><AUTHOR> > it is healthy when people leave that aren't on the same growth path or > maturity of the organization

Yes. That's real!

<comment><USER4> Yes, and it works in both directions of the relationship.

<comment><USER3> Completely agree, both the company and individual win here, no one wants to be unhappy doing their work. And no one wants to work with the person that is always complaining about how the company has changed.

</comment></comment></comment></comment></comment><comment><USER5> The core of the issue is usually the team culture, mindset, and expectations. If things are as chaotic as you say, then you need to identify what is the cause of the chaos. Some possible scenarios:

1\. Ignorant leadership has led to a culture of not respecting software engineering best practices.

2\. Engineering team is ignorant of software engineering best practices.

3\. Team understands best practices but culture is such that there is no time/incentive to implement them. This could be due to people being overworked and as result, prioritizing for delivery and only being able to focus on things other than fixing tech debt. It could also be due to the fact that bonuses are given to those that are implementing new features into the product, therefore creating environment that values delivery over proper software engineering.

You need to figure out what the reason is for your team's tech debt chaos and only then will you be able to fix the problems. There are also degrees of tech debt that you need to consider (architectural-level tech debt vs unit-level tech debt) that will play into what things you can do to rectify the issues and prevent them in the future.

</comment><comment><USER6> Most of the important points have already been raised by others (version control, CI/CD, etc.).

I would only like to recommend one specific tool, which you can integrate into your CI/CD pipeline: SonarCloud ([https://sonarcloud.io/about](https://sonarcloud.io/about))

The on-prem version is called SonarQube ([https://www.sonarqube.org/](https://www.sonarqube.org/)) which you can easily host yourself if you need/want to, but the cloud version is dirt cheap.

This single tool can bring tremendous value into your work life, especially if you have a team full of junior/inexperienced people. It has saved me countless hours on different projects by providing actionable insights on their code bases.

Disclaimer: I have no ties to the company making SonarQube, I am just really thankful that this tool exists. :)

<comment><AUTHOR> Thanks for the pointer. I will certainly explore if that works well with a hosted gitlab instance.

I understand the value of static code analysis very much. Alas, I cannot start talking about things like cyclomatic complexity of code, or water-tight dependency mitigation and its impact on quality/cost-to-company/risk, as the audience isn't mature enough to really grok it.

</comment></comment><comment><USER7> I introduced a thin process at my last job called "capacity setting". It's more abstract than just tech debt, but highly autonomous while still being aligned to the company's needs and goals - including making it clear on one page what the team is working on and why. It worked out reasonably well as Tech Leads were able to control capacities and the business was able to see justification of why we're working on various elements and how much of each.

Here's the brief. Will be glad to answer any questions. [https://drive.google.com/file/d/1-ej- qOCYIaNHJITq8wiMj0hZTFK...](https://drive.google.com/file/d/1-ej- qOCYIaNHJITq8wiMj0hZTFKSxYHS/view?usp=sharing)

<comment><AUTHOR> > capacity setting

Very interesting. Will surely read it and reach out if questions arise. Thanks!

</comment></comment><comment><USER8> Don't look for a silver bullet. Find the largest cause of chaos and try to solve it in the simplest way, which may be a manual process. Some things that cause chaos are: no CI, no tests, no code review, etc.

Trying to add some kind of process or framework is likely to just suck more energy out of the system and make the ICs think you're wasting their time. If anything, they know what they need to do, but probably are being pushed to ship or do something else. Nobody likes to live in chaos.

<comment><AUTHOR> > Don't look for a silver bullet.

Have cut my teeth long enough to know that there's no silver bullet (except in a 'con'sultant's marketing brochure, that is! :D)

> Trying to add some kind of process or framework is likely to just suck more > energy out of the system and make the ICs think you're wasting their time.

Absolutely. Point taken!

> Nobody likes to live in chaos.

Unfortunately, few do want to, cause it makes them look like heroes. And that's where the problem arises. These fellows to nurture their heroic image end up ruining it for everyone, and worse - make the org just stagnate in a limbo.

<comment><USER8> Almost sounds like you have a cultural hero issue? This happens a lot. I think some of it is because people praise people who work extra hard, rather than those who finish their work quickly and well and rarely have to come back to it. Maybe reinforcing good process and looking at things like bug count might help prevent the heroes. Or ask them "how can we make it so next time we don't have to work all night?"

Maybe let the heroes own the solution so that they are still heroes after implementing the thing that fixes everything?

Culture is probably the hardest thing to turn around though. But so important!

<comment><AUTHOR> > Or ask them "how can we make it so next time we don't have to work all > night?"

That's a good one; will certainly use it! thanks!

</comment></comment></comment></comment><comment><USER9> Hi, glad to hear you are using GitLab! Would love to get your feedback on a couple of things we are working on, which I think can help out: \- [https://gitlab.com/gitlab-org/gitlab- ee/issues/12196](https://gitlab.com/gitlab-org/gitlab-ee/issues/12196) \- [https://gitlab.com/gitlab-org/gitlab- ee/issues/12260](https://gitlab.com/gitlab-org/gitlab-ee/issues/12260) \- [https://gitlab.com/gitlab-org/gitlab- ee/issues/12683](https://gitlab.com/gitlab-org/gitlab-ee/issues/12683) \- [https://gitlab.com/gitlab-org/gitlab- ee/issues/12079](https://gitlab.com/gitlab-org/gitlab-ee/issues/12079)

</comment><comment><USER10> One thing I think is forgotten or neglected, particularly when you are a startup, is to learn your tools. If there are too many, cut down on them or isolate it's code impact. Having too many tools/frameworks around increases the level of cognitive load and how to use them thoroughly. I've seen too many times where there are several different tools solving the same general problem interfere with each other because the coders don't know that one would be enough.

<comment><AUTHOR> Yup. This is certainly one problem that we are dealing with.

JIRA - so that non-tech folks can be on-board. Documentation is virtually non- existent - even though there's wiki on git.

git for DVCS, but done in a haphazard way.

Bug tracking on JIRA, as tasks.

Operations/customer success/top management still depending on excel sheets for reports.

End result: cognitive load on apt way of tools usage is very high, and also puts a high barrier of entry and adoption in the right way.

</comment></comment><comment><USER11> I've been reading Basecamp's Shape Up / stop running in circles and ship work that matters.

My twitter feed showed a few shops which implemented the process and are happy with it.

[https://basecamp.com/shapeup](https://basecamp.com/shapeup)

<comment><AUTHOR> > [https://basecamp.com/shapeup](https://basecamp.com/shapeup)

Thanks, that's a really useful resource!

<comment><USER12> In addition to ShapeUp (which is awesome btw), I would like to add Gitlab's Handbook: [https://about.gitlab.com/handbook/product/](https://about.gitlab.com/handbook/product/) [https://about.gitlab.com/handbook/](https://about.gitlab.com/handbook/)

<comment><AUTHOR> hmm, this is useful too! Thanks

</comment></comment></comment></comment><comment><USER13> Release early, release often and fast.

Stability and quality relies on rapid iterations. Optimize for that.

</comment><comment><USER14> Conformance tests, code reviews and ACLs for check-ins.

It's the only way.

<comment><AUTHOR> hmm, agree. Am still figuring out the way to bring these in, without adding more chaos to an already chaotic system. :)

<comment><USER14> There is no way to do this gradually.

Don't try to get everyone's buy in. You won't.

This needs to be enforced from the top. And immediately to stop the bleeding.

<comment><AUTHOR> > Don't try to get everyone's buy in. You won't. > This needs to be enforced > from the top. And immediately to stop the bleeding.

Yup. Sounds reasonable.</comment></comment></comment></comment>


Am i Banned? My posts are only visible to me - <AUTHOR> Have i broken any rules ? My posts are only visible to me and not my friends to whom i share URL. I have not shared anything that could break rules, but if i  have done any, i would like to say, i was and am not really aware of rules, which could ban me. <comment><USER2> You're not banned. Your post hit a spam filter. Sorry—those are more aggressive on new accounts. We'll mark your account legit so it won't happen again.

You can repost your site, but you should put Show HN at the head of the title and add a first comment to the thread introducing yourself and explaining how you came to work on this. That way it will be clear that you're participating in the community and not just trying to promote something.

<comment><AUTHOR> Great! I will love to introduce the story behind starting this startup.

My heartfelt Thanks

</comment></comment><comment><USER3> I unkilled this. I don't see anything suspicious in you post ...

You can contact the moderators at email@example.com in case this is a false positive in one of the automatic filters. This kind of post are sometimes unnoticed.

<comment><USER4> Looks like his first two posts (with [dead] tags only) were killed by the moderators. I'm guessing that it's because they look more like advertising a service rather than something that can be discussed on HN.

<comment><USER3> Yep, I agree. The post are too generic, something like submitting [http://www.youtube.com](http://www.youtube.com) , but there are plenty of similar posts that are submitted and ignored.

My recommendation to the OP is to write something interesting about the service. What is the technology stack? How are you hosting video without melting the server? How do you curate/find content? An interesting use case?

<comment><USER5> They don't host video nor curate anything. The technology stack is very simple:

1\. Search up Internet for the existing tutorials. 2\. Plagiarize the content. 3\. When caught, rewrite several sentences to make it look slightly different and hard to google. 4\. When asked to remove the plagiarized content, make an innocent look and say "It's not me, it's the author! I can't do anything."

My tutorial has been plagiarized on this site, thus such a bitterness. But nevertheless it's a fact that all tutorials that published on the site at the moment are just compilations of plagiarized content.

You can browse this site ( [https://www.google.com/search?q=site:w3clan.com](https://www.google.com/search?q=site:w3clan.com) ), pick a random tutorial and google for a sentence taken from any chapter. And you will see the original source. The technology behind this site is mostly cheating.

<comment><USER6> I took your Google challenge and found that you were largely correct (one or two searches out of ten or so missed).

It makes one wonder about the self-esteem of people who only achieve a stolen recognition; a recognition that they know rightfully belongs to others. Sure, there might be some quick money involved, but even so these types knowing that the money they spend wasn't earned by their own actions would have to lower their visions of self-worth.</comment></comment></comment></comment></comment>


Ask HN: What's your favorite TED Talk? - <AUTHOR>

I've watched many great TED talks and am wondering if there are any gems that I'm missing.
So HN, what are some of your favorite TED talks?
I'll start with mine:
(http://tedxtalks.ted.com/video/Hackschooling-Makes-Me-Happy-Lo) <comment><USER2> I really love any ted talk on cities. Here are a few of my top picks.

[http://www.ted.com/talks/aziza_chaouni_how_i_brought_a_river...](http://www.ted.com/talks/aziza_chaouni_how_i_brought_a_river_and_my_city_back_to_life)

[http://www.ted.com/talks/james_howard_kunstler_dissects_subu...](http://www.ted.com/talks/james_howard_kunstler_dissects_suburbia)

[http://www.ted.com/talks/dan_barasch_a_park_underneath_the_h...](http://www.ted.com/talks/dan_barasch_a_park_underneath_the_hustle_and_bustle_of_new_york_city)

[http://www.ted.com/talks/edi_rama_take_back_your_city_with_p...](http://www.ted.com/talks/edi_rama_take_back_your_city_with_paint)

[http://www.ted.com/talks/jeff_speck_the_walkable_city](http://www.ted.com/talks/jeff_speck_the_walkable_city)

A few others that I can't really find right now, Creating Forrests in Cities, and Unique City building design

Edit for readablility

</comment><comment><USER3> In no particular order:

[http://www.ted.com/talks/dan_pink_on_motivation](http://www.ted.com/talks/dan_pink_on_motivation)

[http://www.ted.com/talks/simon_sinek_how_great_leaders_inspi...](http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action?language=en)

[http://www.ted.com/talks/amanda_palmer_the_art_of_asking](http://www.ted.com/talks/amanda_palmer_the_art_of_asking)

[http://www.ted.com/talks/ken_robinson_says_schools_kill_crea...](http://www.ted.com/talks/ken_robinson_says_schools_kill_creativity)

[http://www.ted.com/talks/derek_sivers_how_to_start_a_movemen...](http://www.ted.com/talks/derek_sivers_how_to_start_a_movement)

[http://www.ted.com/talks/nancy_duarte_the_secret_structure_o...](http://www.ted.com/talks/nancy_duarte_the_secret_structure_of_great_talks)

I can't count how many times I've seen these.

<comment><USER4> That was my list - almost exactly. Especially Ken Robinson and Dan Pink. +1.

<comment><USER3> Life altering stuff for sure.

</comment></comment></comment><comment><USER5> Two oldies but goodies

[http://www.ted.com/talks/tom_wujec_demos_the_13th_century_as...](http://www.ted.com/talks/tom_wujec_demos_the_13th_century_astrolabe)

[http://www.ted.com/talks/joshua_klein_on_the_intelligence_of...](http://www.ted.com/talks/joshua_klein_on_the_intelligence_of_crows)

found here : [http://mayageddon.tripod.com/TED_Talks.html](http://mayageddon.tripod.com/TED_Talks.html)

</comment><comment><USER6> You'll fail to have a great career: [http://www.ted.com/talks/larry_smith_why_you_will_fail_to_ha...](http://www.ted.com/talks/larry_smith_why_you_will_fail_to_have_a_great_career)

93-year old body builder [http://tedxtalks.ted.com/video/Why-Bodybuilding-at- Age-93-is...](http://tedxtalks.ted.com/video/Why-Bodybuilding-at-Age-93-is-a)

</comment><comment><USER7> [http://www.ted.com/talks/tim_berners_lee_on_the_next_web](http://www.ted.com/talks/tim_berners_lee_on_the_next_web)

</comment><comment><USER8> [http://www.ted.com/talks/kelly_mcgonigal_how_to_make_stress_...](http://www.ted.com/talks/kelly_mcgonigal_how_to_make_stress_your_friend?language=en)</comment>


Ask HN: Where to Put Money? - <AUTHOR> if you have a small amount of money (around 20k), where you would invest? What would you buy in order to earn another money e.g. 200€/month or so. <comment><USER2> Your best bet is to invest that money in a Total Market ETF like Vanguard's VTI. [https://investor.vanguard.com/etf/profile/VTI](https://investor.vanguard.com/etf/profile/VTI)

It should net you 5-6% a year compounded over the long-run.</comment>


Ask HN: Why do you use Rust, when D is available? - <AUTHOR> D supports Ownership and Borrowing, just like Rust. DMD, D's reference compiler, can compile itself in less than 5 seconds, thanks to a fast frontend and fast backend. D is easy to metaprogram through traits and templates. You can make your own JIT in D with dynamicCompile.<p>I'd love to hear some reasons why so D and Rust can learn from each other. <comment><USER4> Personally, at some point Rust was just clearly better and after a while - <USER2> lost interest in D. I don't have time to keep track of D catching up, when I'm so happy with Rust, and ecosystem is growing so fast. Maybe D got much better in last few years... but I kind of don't care anymore. It's hard enough to introduce a raising star like Rust to your coworkers and D just don't have traction anymore.

I've been following D since early 2000s. 2 decades. It took it a long time to get good: make it open source, make it community driven instead of one-man show, add some really important features and focus on important things (ownership, memory-safety), get the tools to be good.

It just missed the boat, and never really had a right niche for itself. It was kind Java/C++ mix, and it wasn't all that better to dethrone anyone in that space.

Rust swooped in and executed everything perfectly in a really short time. It's a C++-killer: same strengths, none of the weaknesses. Normal people don't want to touch C++ anymore. Only people that think that CVEs are "just fault of bad developers" (LOL) can still be considering C++ a good language to start new projects in. Industry really, really needed C-like language that was memory safe, and all-round good: both low and high level. And Rust quickly delivered that, borrowing all the great aspects of other languages and addressing a lot of problems.

D is great, and I like it far more than e.g. Go, but it was an ambitious project by one individual for a long time, while Go had a whole Google behind it. There's no shame that it didn't "took over the world". Rust would possibly not do so well if it wasn't for Mozilla support. The marketing, credibility and traction a big backing company like this gives a new language is probably the single bigger reason for different outcomes.

<comment><USER5> I'm currently trying to get into robotics. But why does everyone want c++? Surely robots can be programmed in other languages.

<comment><USER6> Because the real world doesn't really match the expectations and statements of the HN community. It's really rare that I see here anything pragmatic regarding what programming languages to learn/use.

The community lives in a bubble and is out of touch with mainstream software development.

<comment><USER7> I'm a _very_ senior engineer. I've had a strong desire to find a better alternative to C++ since the 90s when I was first exposed to it (I worked with it for about a decade, after a few years with C). Now, decades later, enough bandaids have been applied that it's somewhat tolerable. Congratulations...?

The industry has needed good alternatives for a long time. Finally, they're coming, and not nearly soon enough to suit me! :-)

<comment><USER6> I believe you're right about those alternatives not coming soon enough. If all things go right, by the time Rust will be (sort of) mainstream you'll be able to set up the "Rusty Grampas League" :-)

</comment></comment></comment></comment></comment><comment><USER8> First mover. For a long time D targeted the same abstraction level as Go, and most of its libraries were designed with that in mind. Stuff like no_std was never a major goal for most supposed "systems languages" (that are not C/C++) until Rust came along. D was too slow in gaining momentum, getting corporate sponsorship, and adding new features that pushed the boundaries of what a systems programming language was capable of. Go had first class tooling, D felt like a C++ with a Garbage Collector. It reminds me a lot of Ocaml which also had a lot of great ideas and occasionally showed up in the engineering blog of a major corporation but if you look closely then you would notice severe issues with package management and multithreading (both of which are finally getting attention and being fixed, 5 years too late). There are a lot of boring engineering that goes into making a good programming language ecosystem that many smaller languages do not have either the willpower or resources in tackling.

This is not criticism of the D language, programming languages are like startups, success often has little to do with the product itself but more the ecosystem, funding, and luck.

<comment><USER9> > Go had first class tooling

Eh, I would describe go's tooling as "minimalist" or, less charitably, as "barely adequate." Pre-modules the global GOPATH approach was hacky and ugly, and post-modules the go command is a mess of contradictions straining against the backwards compatibility guarantee. And editor integration back in the day wasn't much more than running go fmt and go build.

<comment><USER10> Arguably that's one of the things that made it easy to pick up. I remember tons of JavaScript programmers who were suddenly systems programmers when it came out.

</comment></comment></comment><comment><USER11> I know most people won't like this answer but the reason why rust is more popular now is because it had klabnik-san, mozilla, cargo and the super excited community.

The same goes for go-lang. It throws away years of research into programming languages. While rust is a great language and deserve the popularity, do you think go would have peaked in popularity if there weren't rob-pike-san and google behind it.

It's not a matter of features for programming languages popularity. It's who is backing them and doing the work to unite the community.

Programming communities also need to be aggressively cultish to take off in the beginning. You must be able to bite everyone's same repeated rehashed argument about lacking ecosystem, bad tooling and so on. You must be able to survive that and still shill the language.

It's reality. Everyone will tell you I don't care about your language when I can use my favourite language. People have invested more money than one can imagine into fixing php, js etc.

You can't easily get someone to switch from their single threaded language when they can scale it through AWS lambdas or other layers of abstractions.

This is why you don't see wide use of ML. All those communities are passive. They write their tutorials and papers in pure html on a weird forgettable domain name. They don't tell people to use the language because they are conscious of the lacking ecosystem but how would you get a good ecosystem without someone adopting it? OSS doesn't pay enough. Tooling require money. They don't focus on marketing or sponsorship.

Same applies for dlang.

<comment><USER12> Case study: awk. Brian Kernighan, who (co-)wrote the book on C, designed (with two others) another language, awk. Same organization (Bell Labs) pushing it as pushed C. C ate the world. awk... um... was available on all Unix installations, and got used for some things.

Sure, there are people who rave about how great awk is. I've read them here on HN. When you've got the right kind of problem, it's a great tool. But there are very few people for whom it is their main everyday language.

My point: Author/designer and organization can only take a language so far. At some point, the actual usefulness of the language determines how much it is actually used.

<comment><USER13> So you're saying Awk isn't "actually useful" which is why it's hardly used?! It's an entirely different kind of tool to C. Or rather, C is a programming language, Awk is a tool. To "get used for some things" is what it's for. Sounds like you're talking more about what purpose things are used for than how much they're actually used. And Awk seems a failure to you because it's used for Awk-problems rather than C-problems? I don't understand your negativity. Awk was and is wildly successful.

<comment><USER12> > So you're saying Awk isn't "actually useful" which is why it's hardly used?!

I deny you the right to put words in my mouth. That is not remotely what I am saying.

</comment></comment></comment></comment><comment><USER14> As far as I know, D does not have ADTs (algebraic data types, a.k.a. tagged unions, a.k.a. Rust enums). I see that it has "enums" and "unions", but neither of these appear to be ADTs if I'm reading them correctly.

And Rust's borrow checker can give _very strong guarantees_ that aren't present in any other mainstream language that I'm aware of. In Rust, you can pass mutable references to large data structures between threads, without copying or GC or any type of runtime checking (e.g. Mutexes), and the borrow checker will guarantee that you can't have a data race (data race = concurrent read & write). In comparison, I believe that in Haskell you'd do this with GC, in Java you'd do it with GC and a mutex, and in C you'd do it _very carefully_.

As another example, in Java if you modify an ArrayList while iterating over it, you'll get a ConcurrentModificationException. In Rust, you _can 't_. The borrow checker won't let your program compile.

The cost of this borrow checker is _huge_ : every reference in every program needs to be annotation with whether it's shared or mutable, and you often need to splatter confusing lifetime annotations all over the place. It adds a big learning curve to the language.

I don't know the details of D's ownership system, but it's not like Rust's borrow checker. Does someone who does know more want to describe it? I've just seen the language reference page here, that describes "scope" and "returns". [https://dlang.org/spec/memory-safe-d.html](https://dlang.org/spec/memory- safe-d.html)

<comment><USER15> D's borrow checker is only semi-documented/WIP at the moment.

[https://dlang.org/blog/2019/07/15/ownership-and-borrowing- in...](https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/)

Basically D just needs that big break to actually get things done. There are some absolutely brilliant people working on D but there's only so much sweat people will donate (some people are paid but I imagine rust probably has upwards of a hundred full time staff given that Mozilla and Microsoft use it in an official capacity)

<comment><USER16> Also D has a gcc backend.

Which is nice but it's still missing some of Rust's features.

<comment><USER17> Its more than that. D is part of GCC - The GNU Compiler Collection. Meaning that if you use linux and have recent GCC you already have D compiler.

<comment><USER18> Don't know anyone that uses the D GCC compiler, it is still playing catch up. The frequency of new D releases with intended and unintended breaking changes, usually source only ever compiles for a very narrow range of versions of D. What people usually focus on is the latest, unless there is a new bug that prevents them from using the newest version.

</comment></comment></comment></comment></comment><comment><USER19> I remember how about 5 years ago I researched what new language to take on. I was in an unusual position to not consider job availability since I planned for a long game and was primary interested in growing my basic coding skills. It narrowed down to D, Go, Nim and Rust.

Rust won on paper based on C-like performance without GC and being not OOP- oriented in a Java way (I tried Java earlier and wondered who in his right mind would want to write that). But what convinced me was excellent basic documentation (the Book), concise and well documented standard library and nice FP-inspired idioms which I had no previous experience with.

I passed on Go due to GC and the fact that while I could probably learn the ropes quickly, there was not much I saw the language could teach _me_ (I may be wrong here but such was an impression). Main accent was on speedy development in teams and it was orthogonal to my needs.

Nim (still Nimrod at the time) was intriguing but too fresh and lacking on documentation. It's much more intriguing now with gc:arc, move semantics and overall general momentum. I keep my eye on it.

D was the one I couldn't really find a place for. It was promising less, there was no killer feature that set it apart. To me it looked like more friendly C++ but with GC. I saw no real advantages.

I tend to think time proved my analysis to be mostly on point. At the time tooling and library ecosystem was rather poor for all four. Today even if featurewise D looks much more interesting, it needs to deliver on well- libraries to be competitive (I have no idea on its current situation on that front).

Sorry for such a long personal anecdote.

<comment><USER20> > _Go [...] there was not much I saw the language could teach me_

Interesting that you mention this; one of the reasons I really enjoy Rust is because of how it forces me to think through things more clearly, and how a number of the higher-quality crates teach more advanced approaches in a straightforward way.

<comment><USER21> I am a Python programmer first and foremost (data science-y stuff), but lately I've started reading the Rust documentation. First and foremost its really an enjoyable read. I also learn alot from it, and become a better programmer in general. I will try to write a library that I will use for my PhD, in Rust. I think it will teach me a lot about programming, be enjoyable and also give me a great library for string parsing and decryption.

</comment></comment></comment><comment><USER22> A mix of misteps by D, and some unique advantages of rust.

* Releasing D under a closed source license was a non-starter. This has killed every language that has tried in the past 30 years.

* Garbage collection was really the only memory management until recently. Manual memory management has always felt clunky and tacked on. Ownership and borrowing came really late to the game in comparison with rust.

* Rust embraced all of the best parts of ML, like algebraic data types and pattern matching and strong static typing, but combined them in a package that made for extremely fast software with low resource utilization and static memory management. They combined it with hygienic fully typed macros. They added type classes, securing the majority of the benefits of OOP while still maintaining a functional style.

Whereas Rust has taken influence from a broad range of PL research, functional programming concepts, high assurance concepts, etc., and applied them to system programming, D has always just felt like C++ with garbage collection.

The one area where I think D still has an advantage over rust is GUI development. Functional programming advocates make lots of platitudes of functional reactive programming, and there are no shortage of toy examples for it, but when it comes down to industrial use, OOP still rules the roost. And while Rust gets _most_ of the benefits of OOP, they still don't have anything approximating inheritance, which just works too well for GUI development to give up on. Maybe Rust will address that in the future, but it's not there at the moment.

<comment><USER23> Java, C#, Visual Basic and JavaScript all are less than 30 years old and all started off with proprietary main implementations. The phenomenon is probably real, but it's more recent than you suggest.

<comment><USER24> I can't remember one that's more recent than 20. All these languages were introduced before open source became the clear winner it is now.

</comment></comment></comment><comment><USER25> Phobos/Tango. GC, then optional-GC. Compiler support for various platforms was wonky, never sure if I was using the right one.

D as of _now_ is a worthy competitor to Rust, it wasn't always the case, it was more like Go, with the GC. I hit some snags and moved on and didn't go back. I am sticking with Rust.

I think a question with closer alignment is, "Why use Go when D is available" ? D feels like a 5x better Go, not a Rust competitor.

<comment><USER11> Why did go took off then?

<comment><USER26> It's impossible to measure how much impact just having Rob Pike and Google behind Go has had on its adoption.

<comment><USER27> Google and Pike get you in the door. Goroutines get you to sit down. The onboarding-oriented nature of the language and ecosystem convince you to sign.

<comment><USER25> What Go did for the tooling space cannot be underestimated, it is wonderful and we will never go back to the before time.

<comment><USER28> What providing a formatter like indent has provided for decades?

Selling a Turbo Pascal/Modula-2 like compilation speed from MS-DOS days as novelty?

Or was using IDE code refactoring tools as UNIX CLI?

</comment></comment></comment></comment></comment></comment><comment><USER29> Engineers learn languages because of success stories by other companies—not by the merits of the syntax or one-off tricks like compiling itself in 5 seconds.

The fact that Firefox uses Rust for the browser engine or that Dropbox uses Rust for the sync engine is the kind of thing that gets me interested.

<comment><USER30> That's a dangerously general statement, and it does not apply to me (an engineer) for example. I learned a lot of languages because of the language itself, e.g. their type system.

<comment><USER31> It may be dangerous to blindly trust that a language is good based on a company's success with that language, but a large company deciding to heavily invest resources and take a risk on a language is also evidence that the language has the designs to succeed.

<comment><USER32> That's based on the company, tech...yes, insurance..probably no ;)

</comment></comment></comment></comment><comment><USER33> The syntax is nicer.

Granted, I'm not very familiar with D. I didn't even know it had a borrow checker.

Rust took a lot of great features from Haskell, while keeping itself reasonably approachable from a C/C++/D/Java programmer's perspective.

Rust put type names after variable/function/parameter names, which really cleans up the syntax nicely.

Rust has very nice syntax for pattern matching, monads, and a slew of other really helpful functional language features.

Even if rust didn't have a borrow checker, it would still be a wonderful systems programming language.

<comment><USER34> One of the reasons why I haven't approached Rust is its syntax. Subjectively ugly and polluted with punctuation symbols that tell you little about their semantics. D looks cleaner and more readable even for a person not familiar with the language. D's readability is on par with scripting languages. Rust is far away from that.

Type names after variable or before? When you think about declaring a variable, do you think about its type of name first? I can't imagine you do the latter because "Hmm, I need an array of doubles to represent my tensor" is double[][] tensor; and not tensor: double[][]. Besides the types after names end up being more verbose in the languages which adopt the scheme (hello Scala).

I invite you to get familiar with D syntax to see a wider picture.

The borrow checker in D is WIP and given how much stir it created, I don't see it's happening any time soon.

<comment><USER35> For reading code, which arguably should happen more often than writing code, having the variable name first makes it easier to find, since it's right near the beginning of the line and it's a single word. If the type comes first, I have to scan the line to figure out where the type ends and the variable name begins.

Also, having "let" at the beginning of the line makes it immediately clear that it's a variable definition, whereas if it starts with some arbitrary type I haven't seen before I have to spend more time figuring out what's happening. Good syntax highlighting helps, but I think starting with types like C/C++/D is less elegant than starting off with a keyword that clearly identifies what the line does.

Similar applies for function definitions. It's nice when the function names are all lined up and not buried halfway across the screen because it has some long return type.

<comment><USER34> Subjectively, I see no point in having "val", "var", "let", "def", "fn" symbols which bring only noise to code. Why would you want to explicitly tell that something is a value while all you need to do is write its type and name?

double[] arr;

bam! Simple and clear.

What about functions? It has input, name and output and D nicely presents you with

double[] createArray(int size) {...}

This is as little typing as you can get while keeping readability.

And here is a basic Rust function

fn add_one(x: i32) -> i32 {...}

What kind of type is i32 btw? oh, there is u32 as well. integer 32bit and unsigned 32bit? What on earth are these? Ah, this is just D's size_t, the same size_t as in C/C++. So that C/C++ ppl have zero overhead reading D code and for Rust they will google. To top that, you have also -> because of the type after the definition scheme. Needless verbosity, same thing in Scala.

What about Rust unable to drop parenthesis after a function?

self.host_addr.clone()

Should I mention Rust's UFCS?

But I am nitpicking, right. This doesn't make a language bad in any way. However, as I said, Rust readability is pretty subpar in addition to already steep language learning curve.

<comment><USER36> > Subjectively, I see no point in having "val", "var", "let", "def", "fn" > symbols which bring only noise to code.

Usually, the reason is to make parsing easier. C++ is infamous for having undecidable grammar. Ruby is extremely pleasing to the eye, but its grammar is a clusterfuck. Newer languages have learned from that, so they try to have simpler grammars.

Another reason for those small syntax markers is to avoid implicit language decisions. In Rust, having to write one of "let/let mut/const" means forcing the programmer to make an explicit choice regarding mutability and memory usage. In Scala, "val/lazy val/var/lazy var/def" means having to think about mutability and evaluation times.

> What about Rust unable to drop parenthesis after a function?

In the case of Rust, the reason is uniformity. Even Scala, of all languages, is walking back on the optional parentheses, because the language allows to define functions with multiple argument lists, and optional parentheses introduce ambiguity between functions with empty argument lists and functions with no argument lists.

<comment><USER34> Yes, "make an explicit choice regarding mutability" can be done even easier by actually writing "immutable double[] arr = [1, 2, 3];", "const double[] arr = [1, 2, 3];". See, no Scala val/var which to a person who doesn't know the language tell nothing. When the language grammar is unambiguous and coherent you have faster compiling times and occasionally better readability. D hits a nice spot in here by capitalizing on C++ mistakes.

"optional parentheses introduce ambiguity" \-- true, they do. However, I am struggling to understand why it is necessarily a bad thing? For a user I see a clear convenience of being able to write "double[] zeroArr = arr.zeros;" or "double[] newArr = 6.iota.sliced(3, 2).array.reverse.dropOne.join;". And if that is not enough, you can also inject your custom method into this chain and it will just work. Don't know about Rust but Scala simply refuses to compile in such cases which for a functional language looks like a limitation.

These are the D features that I really enjoy.

</comment></comment></comment></comment></comment></comment><comment><USER37> It seems to me that D has been too many places and has too many features. My impression is that D sometimes uses a GC, sometimes not. I believe I can do many interesting things in D once I learn the language well enough to pick a certain subset of features, much like C++. In other words, if I want to write GC free code in D I have to learn what NOT to use.

If I want to pick a subset of features, I'd probably pick C++. Or, if I'm willing to use a GC and runtime, then there's lots of languages to choose from.

I use Rust if I want "safety" and no GC and that's all I get.

This is my impression. But I know very little of D so do not judge the language based on my impressions.

<comment><USER34> True. But unlike C++ or Rust, D is not a difficult language at all. You can easily understand when and how not to use GC. Which data structures require allocation and which can circumvent it. There is an ongoing work to make std a @nogc compatible. There is an excellent community of professionals to learn from. The problem is, it is small and resources are scarce. If only D had a bigger company backing it up...

</comment></comment><comment><USER38> Disclaimer: I've used D for an enormous time, and I tried Rust for about one hour for the experience.

Remarks:

\- build times are worse in Rust, but not _that_ much worse

\- with Rust error messages are plentiful and helpful to solve the error. It is a designed user experience, which is quite novel.

\- the first Rust program I built downloaded no less than 146 packages, which seems to indicate the standard library is very barebones. This was an example program. So the granularity of package seems to be smaller there. I don't really like this.

\- Rust has quite visibly a stronger open-source ecosystem, with lots of crates being built before a compiler release. Good.

\- Rust documentation is more aimed at beginner programmers, and there is more of it.

\- I just don't like to look at Rust code at all... the styling on the car is really bad

\- it seems dub and cargo are very similar. Cargo download and installs a lot more cruft inside directories. Probably there is a way to have a shared directory for that.

\- Rust libraries look a bit more systematically modular with the features tags ("configurations" in DUB parlance)

\- it seems Rust has comparatively more C bindings than C-to-D translations in the ecosystem (vs D)

So... I'm not sure I would take Rust if starting a codebase today. It just doesn't add up for me versus D.

I try to be someone practical and need actual measurable improvements in the daily practice.

For me the key take-away is the very consistent experience when interfacing with Rust tools, since this experience has been designed and fine-tuned to be easy. I think D can learn some UX tricks from it.

</comment><comment><USER34> Let me throw my uneducated and biased opinion on the table.

It's amazing how Rust development and popularity progressed over the years. Uncompromising features, no trade-offs except for complexity and compilation speed but what language is ideal, right?

For me personally, D was just easier and faster to learn than C/C++/Rust. I got basically the same speed without memory management and learning curve overhead. Coming from Python land I enjoyed fast rdmd compile-and-run times that made me feel like I am working with an interpreted language while having much more control and access to the system. Nowadays, D forum, IRC is so helpful that I get an answer within minutes. I expected quite the opposite considering how smaller the community is.

So, these are my reasons for why D. You can see that I didn't care whether the language was backed up by some global company or was trendy. I got tired of Python that fallbacks to C/C++ when performance matters and if you want some real work done good luck with C/C++. JVM based languages were also not my cup of tea due to memory appetites and being comparably slower. D came as a surprise managing to be faster both in execution and compilation. It is later that I learnt about some of the shortcomings, smaller community, fewer available libraries, etc. etc.

</comment><comment><USER39> From what I understand D ownership is based on function attributes which means it's enforced only across function calls and only as an opt-in. In Rust this is done across everything, so function basic blocks are also validated.

</comment><comment><USER40> For those you want the context of D please check its development history [1].

If history telling us something, python only take off after 20 years and now D language is around the 20 years mark. But fortunately D has passed the growing pain similar to python 2 to 3 when it transitioned to D2.

Personally I think D just need a big breakthrough in a form of a killer application like Ruby with RoR, and Go with Kubernetes to make it more popular and gets the snow ball rolling. The killer application probably involve some kind of data science or data analytics that is currently more popular now with python. But python seems starting to reach its limits and it will be good if D can take over.

For rust since it came from Mozilla team I'd expect by now Firefox is already re-written in rust by now but it seems yet to happen, and this article probably tell us why [2]. It will be wonderful to have Firefox-rust (if it ever happened) to replace Chrome that keeps eating away my quad core CPU and 16 GB ram laptop memory once opening more than 20 tabs.

[1][http://erdani.com/hopl2020-draft.pdf](http://erdani.com/hopl2020-draft.pdf)

[2][https://hacks.mozilla.org/2019/02/rewriting-a-browser- compon...](https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in- rust/)

<comment><USER41> Chrome may be using a lot of active memory, but I don't think it's a result of poor programming practices. So I don't see how switching to Rust would solve the problem. Unless Chrome has a memory leak problem.

If anything, Chrome can just offload the contents of the unused tabs to the hard drive, and reload it when it becomes active again. But this will require a massive architectural change to the core program itself.

<comment><USER42> Web pages have memory leaks, not Chrome itself.

Side note, but at least on linux, with both Chromium and Firefox, you can observe exactly this behavior- tab-based segregated memory management. The work was done on both engines over the past several years, works beautifully now.

The content of each tab lives in a separate process. Kill the process, see the tab marked failed in the UI. Reload the tab, see a corresponding process spin back up.

I keep dozens of tabs open and periodically kill the ones that creep to the top of ram use, both wired ram and virtual. Keeps me from going into swap.

</comment></comment></comment><comment><USER43> I wouldn't compare a WIP borrow checker, just added some months ago, against Rust.

However, where it's the bigger and unique thing that D haves. Fast and very powerful metaprogramming. Can do things like parsing a XML or JSON at COMPILE TIME and generate code. No body catches how powerful is this ? For example, imagine parsing a gtk-build /glade XML and generating the GUI code at compile time, instead parsing it at runtime.

<comment><USER38> This is really quite common thinking in D.

I was writing a library and a contributor popped out of nowhere. He didn't knew D. The first patch it suggested was about parsing some JSON at compile- time.

It turned out std.json the stdlib parser was able to parse at compile-time in CTFE context. So, the contributor parsed JSON at compile-time without his knowledge, without really knowing D, and the fact it worked was accidental (since the parser was n't specially designed to do that, but could).

</comment></comment><comment><USER44> D was closed source when it was in the spotlight and missed its opportunity to gain mind share.

</comment><comment><USER45> Rust enums are an amazing productivity boost because they can contain other values and data structures. This allows the type checker to help a lot more with business logic than is usually possible.

</comment><comment><USER46> I can't tell if D is supposed to be used with or without the GC. I just know Rust is pretty close to an ML, which I like, and it has this nice borrow checker and is super popular.

<comment><USER17> The language doesn't tell you what to use. You choose what to use.

<comment><USER46> for something as fundamental as garbage collection, the last thing I want is a choice.

<comment><USER47> Then use garbage collection; it's an easy default.

</comment></comment></comment></comment><comment><USER48> I tried D some years ago, my naive program crashed as it wasn't memory safe. Being used to scala this was a surprising to me, I expected "if it compiles it works" but it turns out I had to take lifetimes into account just like c/c++. Rust has this "if it compiles it works" \+ quality.

Then I needed to create a program that would work both on android and Windows. Still liking D's syntax better funding rust rather verbose I decided to give it another try, but failed, I had to jump through too many hoops to make it produce a library usable on android. While with rust the experience was effortless.

After both experiences with D, I never looked back to it and rust is now my go to low level system language, the verboseness (with lifetimes and types) has grown on me.

</comment><comment><USER28> Given the choice, I would rather use D, because experience has taught me that tracing GC are a productivy boom, even in systems programming, also D provides all the necessary tooling for doing GC free programming when required to do so.

However it lacks the commitment of a proper roadmap and big corporate support, and that sadly damages its image.

Rust on the other hand, while quite relevant for bringing affine types into mainstream, still isn't what I would like to use across the various domains I work on.

Ironically, I see Java and .NET getting the missing features (AOT, low level unsafe code, better control over memory allocation) that will eventually allow me to use them in system level programming scenarios, where I would choose D today.

<comment><USER49> Is there much choice though in terms of jobs? I mean, is it worth learning D vs rust? I'm actually thinking about that nowadays, for what to learn next..

<comment><USER28> In terms of jobs I guess Rust has the edge, including all major ones in desktop, server and mobile OSes, there are still some companies using D though.

[https://dlang.org/orgs-using-d.html](https://dlang.org/orgs-using-d.html)

So if getting a job is your major learning motivation, then I guess Rust has definitely the edge there.

</comment></comment></comment><comment><USER50> This is an excellent question!

There's an old saying about natural languages: "A Language is a dialect with an army."

I think Rust's army--the one that will invade any discussion and say "use Rust!"\--is simply better than D's "army."

</comment><comment><USER51> As a D user who never used Rust, few reasons why Rust is more popular than D:

\- better ecosystem, cargo has many more packages, almost every important C library has a binding available, also many C++ libraries like Qt, Bullet. D claims to have the best C++ interop capabilities of all languages, but it's not reflected in the amount of bindings to C++ libraries available

\- Rust has a better foundation in form of standard library and "blessed" packages. D standard library hasn't had many updates over the years. There are packages such as std.xml that are due for replacement, but no replacement exists. There is still no standard http package, serialization package.

\- adding to the above - many problems in D are solved by the way of "I made something, maybe someone will find it useful". Pieces of code are shared, but there is no organized effort to fill in the gaps, and in the effort there is, there often seems to be lack of the final push to get something included in the standard library. There has been many potential stdlib packages in form of pull requests that never get merged due to codestyle nitpicking or some design concerns, with authors never moving in to fix it.

\- more IDE-friendly environment. A lot of D code is constructed in build- time, which isn't friendly towards refactoring and code completion tools. Also, many people in D community are hostile towards IDEs, considering them as bloat and that "real programmers use Vim/Emacs and don't need those fancy syntax highlighting".

\- stretching the language too thin. D started as a mostly GC language. Now we have @nogc and betterC. But neither really work as well as going full GC. Now ownership and borrowing system is coming into play soon. Automatic refcounting might be implemented in the future. That's a lot of possible failure points, and ecosystem splitting points.

\- Lisp curse. There aren't many syntax sugars added into the language, and many language features can be somewhat implemented with templates. Things like named arguments can be implemented as a template hack, but it looks terrible both from caller and callee side. But for many people it's "good enough" and they consider the case closed and move on to other features. As a result, D offers often many half-baked solutions. Libraries that worked for someone but never really got fully implemented, language features that somewhat work as long as you don't use that other feature that they don't work with. etc.

Obviously many of those problems in D are just a matter of lack of manpower and lack of money, it's a bit of chicken and egg problem.

</comment><comment><USER52> D tried to be a bit like Java, because in the early 2000 Java was the popular language dethroning C++ and sadly, it succeeded.

The worst thing about all this legacy is Android.

I would love a phone OS in D, Rust, or other well-designed language.

</comment><comment><USER53> I love D but I think the GC is a good argument for Rust

</comment><comment><USER54> Because Rust is new and shiny.

People who use Rust aren't using it to solve real world problems, they're using it to scratch a novelty itch.

D is a tragedy in my opinion. It's an excellent language that just doesn't fit the political needs of any of the big players.

We have Swift which is a worse version of C#, we have Go, we have Java. Why don't we have a single language so that we can do cross platform development and abandon web browsers and javascript? Because politics. Every company needs to toot its own horn and suck up smart intelligent people so that they don't create a real competitor, and so we have a dozen languages that share 95% of the features and are all incompatible with one another and no one sane enough to say this is crazy, I'm going to take my FAANG money, move to a place with cheap rent and put an end to this madness.

It's only a game developer of all people, Jonathan Blow, that's doing it and his creation is a C++ replacement for games, not general purpose software. Sigh.

<comment><USER39> > Why don't we have a single language so that we can do cross platform > development and abandon web browsers and javascript?

What does that even mean? What do you lack in regards to cross-platform from Java / Rust / Nim / Go / Python / Ruby / Haxe / ...? (I'm assuming cross- platform here means desktops, not microprocessors)

Specifically, yes, there are things that you may miss in every one of them, but it's not like we don't have the option to use them. What's the point in complete unification in the first place?

<comment><USER11> He means cross platform ui frameworks. Afaik, only flutter has support for most platforms. It supports web, desktop and mobile.

</comment></comment></comment><comment><USER55> Helpful community. Healthy ecosystem (never want to write byte formatting libraries). Fun language. Good APIs.

I wasn't early to Rust and I won't be early to any other language. For PLs I'm solidly on the far end of the chasm.

</comment><comment><USER56> Its my understanding that the main reason is because Rust doesn't use a Garbage Collector.

</comment><comment><USER57> \- bad or missing tooling

\- no clear direction

\- no vision

\- no ide

\- no big company

\- bad or missing documentation

<comment><USER34> * bad or missing tooling - true, it's missing but I wouldn't say it is bad

* no clear direction - <USER3>

* no vision - there is but not well maintained unfortunately [https://wiki.dlang.org/Vision/2018H1](https://wiki.dlang.org/Vision/2018H1)

* no ide - VS Code with D plugin works pretty well these days. There is an IDE written fully in D too.

* no big company - true, but there are a bunch of successful smaller ones.

* bad or missing documentation - not true, std documentation is pretty good and is gradually improved.

And don't forget that notwithstanding the lack of people and corporate funding (D is crowd-funded), you get a language that attempts to rival the big guys and frequently outplay them. Now, imagine the results given the resources were equal.

</comment></comment><comment><USER58> d does not support ownership and borrowing "just like rust"

</comment><comment><USER59> Because there's a movement called "Rewrite everything in Rust"

<comment><USER60> If that is indeed the answer (and I don't think it is), perhaps try to answer the question "why isn't there a similar movement for D?"

<comment><AUTHOR> Because we have a movement called "Make the D compiler compatible with all C++ code" [https://wiki.dlang.org/Calypso](https://wiki.dlang.org/Calypso)</comment></comment></comment>


Why parallel programming frameworks like Apple GCD, Intel TBB, Cilk don't work? - <AUTHOR> http://www.futurechips.org/software-for-hardware-guys/parallel-programming-frameworks-solve-part-problem.html

<comment><USER2> More lousy and sensational title than the linked original: "Parallel Programming: Why new frameworks only solve a part of the problem?"

Good link, though.</comment>


Show HN: A minimal, Reddit-esque site with anonymous posts/comments. Now In Beta - cc-d https://ieddit.com/news/2019/10/21/ieddit-beta-release/ <comment> cc-d I'd like to thank HN for putting this on the front page day 1 of public alpha.

The site was bare-bones functionality at the time, now it's a little more feature complete :)</comment>


Facebook threatens to ban Australians from sharing news - <AUTHOR> https://www.abc.net.au/news/2020-09-01/facebook-threatens-to-ban-australians-from-sharing-news-content/12616216 <comment><USER2> Good to see this move from Facebook, not because Facebook is without issues, but because the proposed scheme is truly awful.

Google seemed a little hung out to dry going in hard with the messaging across its products with no announcements from Facebook.

Hopefully with Facebook's rather aggressive messaging Labor and crossbenchers will pay closer notice to the nuances of this issue.

Stratechery provided a great overview of just how bad this 'News Media Bargaining Code' is [1].

[1] [https://stratechery.com/2020/australias-news-media- bargainin...](https://stratechery.com/2020/australias-news-media-bargaining- code-breaking-down-the-code-australias-fake-news/)

</comment><comment><USER3> Link to the contentious draft law in question: [https://www.accc.gov.au/focus- areas/digital-platforms/news-m...](https://www.accc.gov.au/focus- areas/digital-platforms/news-media-bargaining-code)</comment>


Evelyn Waugh: A Life Revisited - <AUTHOR> http://www.barnesandnoble.com/review/evelyn-waugh-a-life-revisited <comment><USER2> In 2005 I set a goal to read all of Waugh's novels and travel writing that year. It was time well spent. My favorite turned out to be the Sword of Honour trilogy, but I've re-read Put Out More Flags the most, and probably thought about Helena the most. Understanding Waugh's perspective makes it easier to laugh at all the silly social movements, businesspeople and inept bureaucrats that plague us without succumbing to cynicism.

</comment><comment><USER3> His collected letters are priceless.

A close friend of various Mitford sisters, who are peerless in their own way.

<comment><USER4> His diaries have interesting bits, but as Paul Fussell remarked, Waugh wrote the diaries at night after drinking, and the letters in the morning sober. I have a volume of his and Nancy Mitford's letters to each other; I must say that her prose would look better on its own.

</comment></comment><comment><USER5> See also: [https://news.ycombinator.com/item?id=11185783](https://news.ycombinator.com/item?id=11185783)

</comment><comment><USER6> He married a woman also named Evelyn and they were known as he-Evelyn and she- Evelyn. And no, he never did kill the man that gave him that awful name.

<comment><USER4> I don't think that it was that odd a name for a man back then. And fashions change. The critic Clive James started life as Vivian Clive James, at a time when the most prominent Vivian in Australia was a (male) cricket player. Then they filmed "Gone with the Wind".</comment></comment>


Mozilla Blog: Block slow, privacy-invading content, not "advertising" - <AUTHOR> https://blog.mozilla.org/blog/2015/10/07/proposed-principles-for-content-blocking/ <comment><AUTHOR> tl;dr -

* Content Neutrality: Content blocking software should focus on addressing potential user needs (such as on performance, security, and privacy) instead of blocking specific types of content (such as advertising).

* Transparency & Control: The content blocking software should provide users with transparency and meaningful controls over the needs it is attempting to address.

* Openness: Blocking should maintain a level playing field and should block under the same principles regardless of source of the content. Publishers and other content providers should be given ways to participate in an open Web ecosystem, instead of being placed in a permanent penalty box that closes off the Web to their products and services.</comment>


Ask HN: Tell company I am getting actively recruited? - <AUTHOR> I am getting actively recruited from both large and small companies. I am not interested as a enjoy my job alot. But my yearly review is coming and I know  from others that the negotiate raises. Should I let them know about this/will that leave a sour taste with them? I don't want to threaten but also want them to knnow where Im coming from. <comment><USER2> No, don't tell them. Not because they will take it as a threat but because you will look quite silly if you do mention this. Recruiters scan LinkedIn for anybody that has even just a couple mention of the skills they are looking for and then send all the matches messages along if they're be interested in a new job.

If you had an actual job offer on the other hand then that would be a different story. Then you could reasonably say "I have had an offer for this much salary so please can you match that otherwise you are asking me to work below my market rate for you and although I like working here I don't think it's fair to ask that of me".

<comment><USER3> Good advice. Also, if you have job offerers and you are not letting them know, but your colleagues are effectively communicating job offers they have, then they will be prioritised for a raise over you.

</comment></comment><comment><USER4> I've always personally believed in the show-by-doing approach here. If you want to negotiate a raise, find a way to provide more value to your company, get feedback from your boss that it would be valuable. Then come review time, demonstrate that you've been contributing _beyond_ your current role in this capacity.

Most engineers are getting messaged by recruiters regularly. This is not a surprise to your boss if he has good engineers on the team. But I don't think that leveraging this in itself is an effective technique for negotiating a raise. In my opinion, being recruited doesn't affect the value you create in your current role unless you believe that your comp is below market, or you have grown significantly beyond the role you're officially in now. Just my 2¢.

</comment><comment><USER5> If you want to negotiate a raise, you can tell them what you did and display that you want to grow more with and in the company. Without having anything to show that is not possible.

You can also take those interviews, ace them and use a higher offer as leverage, but that can be risky, as you company might say no and you need to go to this other job.

What I recommend is that people even though that they enjoy their jobs, they do interviews for perceived good companies, that they would like to work on, and in case they get an offer, they negotiate with their own company. So if the company doesn't want to give you that raise, you go to the other company which gives you a potential good outcome for both possibilities.

</comment><comment><USER6> Would you tell your wife/partner someone is flirting with you?

We all know the job market lives crazy times right now; but if you mention you are getting recruiter calls, It might backfire.

Better use that calls to know how to advance your careeer, which skills are un high demand, and use that info wisely.

</comment><comment><USER7> You negotiate when you have leverage. Leverage is an implied threat that you will leave the company where the cost to the company of you leaving will be significant. You have to be ready to actually leave the company in order for this to work. Generally this involves having a competing offer in hand.

Since you do not have an actual offer and you are not going to leave the company, you should not try any tactics in negotiating a raise. Your best play is to make a case based on the value of your work and ask politely and hope for the best. This will not get you a big raise, but it may get you a modest one.

This is not the optimal position for you in terms of career development, but it is the position you are putting yourself in by wanting to stay in your current job regardless of potential opportunities externally.

</comment><comment><USER8> I am in a similar situation but I already put my notice. What I did was speak to my manager and then speak to the founder. Both of them agreed that I should take the new opportunity and move on. Go ahead and talk to your manager/founder. They'll not feel threatened. They will support you with good advice.

</comment><comment><USER9> In my opinion it comes down to approach.

If you hang a banner above your desk ("I'm being recruited all the time!"), yes they will have a sour taste.

If you go through your review, and you aren't making headway on negotiations without bringing it up - it might be time to approach it.

</comment><comment><USER10> > I am getting actively recruited from both large and small companies. I am > not interested as a enjoy my job alot.

If your employer is aware that you enjoy your job and are not interested switching companies, that might lead them to not give you much of a raise -- since you're already happy and not going to leave. (Not everyone would think this way, but it's a fairly obvious line of reasoning).

Suppose your yearly review does not produce a result you are happy with. What are you going to do?

Are you cultivating alternative options for employment that you could tolerate and would give you the raise you desire? I.e. are you turning the inbound interest into actual offers for jobs and packages you'd be willing to accept?

</comment><comment><USER11> Everybody gets actively recruited. So the words don't mean much.

</comment><comment><USER12> Ha. I've been getting recruiting inbound every single day for years and so have many engineers I know.

It's just largely top of the funnel spam.

Doesn't give you any leverage, unfortunately.

</comment><comment><USER13> y, I wouldn't express hey I'm being recruited.

If they value you and you are providing value use that as leverage. Sometimes no matter how good a developer you are or how valuable you are they won't give you the raise you think you deserve.

Sadly sometimes the best way to get a large raise is to change companies so keep that in mind.

Good luck.

</comment><comment><USER14> the best leverage is when you get an offer AND you're prepare to leave!</comment>


How Headphones Changed the World - <AUTHOR> https://www.theatlantic.com/technology/archive/2012/05/how-headphones-changed-the-world/257830/?single_page=true <comment><USER2> I like how the author mentions "Sound and work" in the article. I also admit being guilt to listen to my ATH m50x (reviewed here: [https://gadgetsbrigade.com/best-over-ear- headphones/](https://gadgetsbrigade.com/best-over-ear-headphones/) ) while I am writing up a blog post or working on a video editing project.</comment>


Ask HN: Wrote a small thing which grew and became very popular, and I'm sick of it - <AUTHOR> Hi HN,
I work for a (very) large company. A while back, I wrote an internal tool for some fairly specific, niche (albeit quite important) internal need.
What started as something used by 3 people blew up over the past year into something on which dozens (if not hundreds at this point) of people rely on, and that supports some critical needs inside the company. The small tool grew from a few hundred lines of code into a complete environment with tooling for non programmers, etc.
I'm currently managing 3 engineers who develop the whole thing, and I'm running around playing PM - answering emails, spec'ing out work, being pulled into meetings, and so on. (I'm not officially their manager, but my manager assigned them to me)
If this project were a startup, right now we'd definitely be into the "hockey stick growth" part of the curve.
The thing is that I completely and utterly hate it. What drives is learning, research, becoming a better programmer/designer, and working on cool things - not managing a full blown software project with all the QA, release planning, etc. that's involved. I've given many evenings and weekends to this thing over the past few months, and am nearing complete burn out (I started losing hair, actually).
I've been at the company for much longer than the lifespan of this project - I am a R&D engineer whose job is to explore various avenues for prototype hardware. I'd like to detach myself from what I've created without causing my entire management chain (this has gotten executive attention) to hate me.
Have you experienced this in the past? What is your advice for dealing with such a situation? I already have some thoughts of my own, but would love to hear external perspectives. <comment><USER2> Obviously you need to have a heart to heart conversation with your boss about the personal toll that this is taking on you and that you need to return to your first love, that is R&D.

Don't wait until you are so frustrated that you have your resignation letter already written. Start the conversation now if you haven't already. Reassure the boss that this doesn't need to happen overnight but that it does need to happen within X months. Otherwise you might get a combination of praise, bonuses and guilt that just keeps stringing you along in the same position for a couple more years.

How to minimize risk for the company while releasing you to do what you really enjoy?

My first thought is to groom someone to be the product manager. Ideally, one of the 3 engineers you are already managing. If none of them have desire & ability to PM the software then start the process to hire a replacement from elsewhere in the company or from outside.

Start to prepare for a smooth hand-off. Make sure the house is in order:

[1]solid documentation

[2] version control

[3] bug tracking and resolution

[4] comprehensive user lists

[5] mapping out of business and technical stakeholders

[6] dependencies - data, software, systems and operations

[7] engineer duties and strengths documented

[8] features both committed road map and wish list

When you feel like the house is in order start pushing the transition hard from your side to move it along. Because at that point, you can say with good conscience, "everything is ready for a smooth hand-off and I have done everything I can to minimize risk."

Finally, your boss and maybe her boss needs to understand how you will continue to contribute to the growth and efficiency of the company. You need to create a narrative that emphasizes how much value was also created by your R&D work and will be created once again when your life is not consumed by this one project that turned into a product.

Hope you are able to make the transition that you need without having to quit the company.

</comment><comment><USER3> I agree with the other comments suggesting you need to speak with your managers, but I'll go one further.

I too work for an R&D organization (CSIRO). Last year I was moved out of development into a management position by my boss because they felt I would be more useful in a Product/Project management role.

The interesting thing was during the discussion, my boss outlined how R&D people aren't developers, developers aren't managers and that managers aren't R&D people.

Your manager likely understands this, but wanted to give you a shot at running the project you created. In the early days, you may be the best person to maintain it as you saw the potential and likely had great insight and vision.

This is also seen in start-ups where many early start-up CEOs can't make the transition from discovery to growth. They can get the company to the early stage of growth, but then in comes a growth focused CEO to lead the next stage.

I also have a friend who only joins companies at this stage, and takes them from < 20 employees to > 100.

This is the same as launching a rocket. The booster that gets you to the outer atmosphere doesn't get you into space.

All of this is to say, you may have a fear that your manager thinks this is the job that you should be doing, but don't be surprised to hear management is aware of the challenges, but doesn't want to take away your baby before you're ready to give it up.

</comment><comment><USER4> I have not had this experience, so my advice is somewhat theoretical.

How is your relationship with your management? Can you tell them, "Look, I'm an R&D person, not a manager. You need to find someone else to manage this, who actually knows how to manage stuff, and let me get back to my real work." Would they listen if you said something like that?</comment>


Show HN: A Lispy, embedded Forth - <AUTHOR> https://github.com/codr4life/vicsydev/blob/master/lispy_forth.md <comment><USER2> I strongly believe concatenative languages – particularly statically typed ones – are one paradigm of programming that have not been explored nearly enough. It's good to see more activity in this area :)

Here's another interesting concatenative language in development that I'm following: [http://kittenlang.org/](http://kittenlang.org/)

<comment><USER3> I dunno, it feels like Factor kind of exhausted it several years ago? I think the problem is that concatenative programming is super elegant for some things, and then falls on its face for others.

In particular the object/class system of Factor was baffling to me. The paradigms just don't fit together well.

I also think Lisp has an awkward object system(s). If you want that paradigm, I think a dedicated language is better.

<comment><USER4> Somewhat OT, but I'm curious what you think is awkward about CLOS?

<comment><USER5> Simple member access like

        object.foo.bar

is apt to read more like this:

        (class2-bar-of (class1-foo-of object))

<comment><USER6> Why not use simpler names?

        (bar (foo object))

I mean, I understand that "a.foo" (class A) does not represent the same name as "b.foo" (class B) due to scoping rules, and so logically you would have to use (a-foo a) and (b-foo b) if you wanted to replicate the same in CLOS. But on the other hand, FOO can be generic and applied to different types of objects. You might even have a mixin providing the FOO slot, which classes A and B inherit from.

I find the notation fine, it looks like regular function application (some people prefer threading macros, I personally don't care).

Note also that CLOS allows you to add code "between the dots" by specializing accessors on qualifiers (:before, :after, :around), which can be useful to add orthogonal things like logging, persistency, ...

<comment><USER5> That could work within a single, well coordinated project. Beyond that, the Common Lisp package system doesn't cooperate the way you'd like it to, so you're back at

        (libraryA:bar (libraryB:foo object))

Since the package system is not hierarchical and doesn't allow local aliases, if you're unlucky you get fully qualified Java-convention package names and end up writing:

        (com.myfavoritecorp.dept1a.project7.subprojectX:bar
           (com.biggercorp.dept32.project2.subprojectE:foo
              object)

<comment><USER7> The CL package system allows local aliases. How do you think you can be in the default _cl-user_ package yet refer to _cl:cons_ as just _cons_?

Firstly, the exported symbols in one package can be made visible in another package through package use. Secondly, a symbol from package A can actually be made present in package B via _import_ : [http://clhs.lisp.se/Body/f_import.htm](http://clhs.lisp.se/Body/f_import.htm)

<comment><USER5> The context was: "FOO can be generic and applied to different types of objects." That only works if everybody uses the _same_ symbol FOO. Library:FOO is a different symbol and won't be combined automatically, so you must package-qualify.

(Regarding local aliases, I was talking about local package name aliases, which could make it somewhat less awkward.)

<comment><USER7> Of course. Why would LOTTERY:DRAW and GRAPHICS:DRAW be smashed together?

<comment><USER4> but now you're back to (lottery:draw x) which isn't any shorter than (lottery- draw x), so the point about names not being namespaced to the object they are applied to remains.

<comment><USER7> If I have inherited both, I cannot use the symbol DRAW to refer to both; at most one of them can be just DRAW.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> That's cool! I actually tried something like this myself, but ended up with a less conventional syntax.

I'm not really familiar with Forth, but my impression from writing a little bit of postfix code was that some pattern matching would make e.g. writing a large conditional much easier.

<comment><AUTHOR> Forth is trivial to learn but takes serious effort to master, like Lisp and C. I'm a humble beginner myself when it comes to Forth. A match operator is a possibility, but too much of that will ruin all that's good about Forth. I already added word scoped variables, and I already feel like I'm balancing near the point of negative return.

</comment></comment><comment><USER7> > _I 've been craving for a trivial, embedded scripting language that feels > just right for a long, long time; something I can quickly drop into any > project that needs scripting without too much ceremony._

How are you quickly and casually going to drop in a scripting language into any project, if it requires Common Lisp?

Maybe this means "into any CL project". But why would you need a scripting language in a CL project.

<comment><AUTHOR> The idea doesn't really require Common Lisp; the same thing could be implemented in C with a bit more effort. But for me, any project mostly means Common Lisp as that's the first tool I reach for. I need a scripting language because exposing the full host language is not really scripting, pretending so is a cop out that always comes with unintended consequences. Given the right definitions, Forth reads like the kind of pseudo code most non-programmers would write; and the lack of syntactic fluff makes it a viable alternative for scenarios involving sequential processing, templating etc.

</comment></comment><comment><USER9> So, serious question: if the property of a concatenative language is the ability to pass outputs to inputs of a function without specifying parameters, could Iolang or Smalltalk also be described as concatenative? Ie:

      Transcript show: 'foo'; cr.

In this case the output of "Transcript show:" is the Transcript object, which is used as the sender for cr.

<comment><USER10> The property of concatenative languages is not the ability to compose functions without specifying parameters, but that this in the _only_ way of building programs.

Your Smalltalk example has a lot more special syntax going on, in a stack- based concatenative syntax it might be written as

        Transcript ' foo' show cr

assuming appropriate primitive programs "Transcript", "'" (for literal quoting), "show" and "cr"

</comment></comment><comment><USER11> That is a bit too exciting this early in the morning...

<comment><AUTHOR> Sorry about that :) Time zones...I strongly prefer Lisping and Forthing after midnight, too much noise on all levels during days.

<comment><USER11> Yep, I live in the EU but I am in Cambodia now and I love three languages the most; Lisp, Forth and APL. So you know what to do to make me cry and have eternal enlightenment...

Edit; I use Lisp in the form of Clojure daily as well as Forth for embedded. When writing embedded code, instead of assembly (check my profile, the stuff we use definitely has no room for Node but often not even C) I usually port a Forth if one is not available, at least for testing but usually it is good for production too.

<comment><USER12> What resources would you recommend for getting started with Forth?

<comment><USER11> Charles Moore Thinking Forth is excellent if you want to work with resource limited systems.

<comment><USER13> The author of Thinking Forth is Leo Brodie.

From Chuck Moore, the father of Forth, "1X Forth" ( [http://www.ultratechnology.com/1xforth.htm](http://www.ultratechnology.com/1xforth.htm) ) is worth reading _before and after_ Thinking Forth.

<comment><USER11> You are absolutely right. Got my authors mixed up. Both are great reads.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> I've been wondering if they called the hp48g's forth ui lisp to avoid lawsuits.

</comment><comment><USER15> actually I'd like to see a (~16 bit) Forth backend for LLVM... so I don't have to "think RPN" myself.

just load the binary into serial flash, point the interpreter at it, and of it goes.

</comment><comment><USER16> reminds me of jvtoups emacs-lisp stacking monad (IIRC)

</comment><comment><USER17> abc</comment>


Integration Approaches for Micro Front Ends - <AUTHOR> https://martinfowler.com/articles/micro-frontends.html#IntegrationApproaches <comment><AUTHOR> This is the 2nd part of the Micro Frontends[0] article that was posted yesterday

[0] [https://news.ycombinator.com/item?id=20148308](https://news.ycombinator.com/item?id=20148308)</comment>


Mozilla's WebAPI takes shape, can now read battery state, send SMS, vibrate - <AUTHOR> http://www.extremetech.com/computing/107211-mozillas-webapi-for-firefox-takes-shape-porn-sites-quiver-in-anticipation

<comment><USER3> I wasn't aware that Mozilla planned to build some sort of OS as well. It is nice that they are pushing for a more open version of Android. Its neat to see another large organization like Mozilla bring apps from the desktop to the web.

<comment><USER4> But they're not pushing for a more open version of Android, they're pushing for a mobile version of ChromeOS.

<comment><USER5> Indeed. <https://wiki.mozilla.org/B2G>

</comment></comment></comment><comment><USER6> Cool but does Firefox have some sort of whitelist to give certain sites permissions to use these apis? I don't want random sites snapping images of my crotch.

<comment><USER7> Yes, browsers will ask permission before letting any site use these APIs, just as they already do for many other APIs like Appcache, Local Storage, Geolocation, popups, Desktop Notifications, etc.

You can see this in action by trying out any of these APIs in a browser that supports them. For example, most browsers now support Geolocation and will display a permission request when you launch this demo (unless you have already whitelisted the domain): [https://developer.mozilla.org/en- US/demos/detail/urban-arter...](https://developer.mozilla.org/en- US/demos/detail/urban-arteries)

Camera capture in particular can only be initiated and controlled by the user -- it works just like the regular file upload dialog, but instead of a file picker dialog the browser shows a camera dialog. Just like file upload, camera capture happens only if the user presses the a button on an input[type="file"] element, and just like the regular file picker dialog, the capture picker is under the user's control so you can decide when to snap the picture, and whether to upload the resulting image.

<comment><USER8> So what does a user do if he wants to upload a file from the sd-card and not take a picture to upload it!?

<comment><USER7> In Firefox there are two buttons in the file input widget (when it includes the accept="image/*" attribute): one to "browse" and one to "capture."

</comment></comment></comment></comment><comment><USER9> > _whether ARM processors will ever be able to execute JavaScript at native- > like speeds is still unknown._

Does this have a secret meaning I can't discern, or is it just nonsense?

<comment><USER10> HTML renderers often have choppy animation and transitions.

<comment><USER9> It was the bit about ARM processors that made no sense -- the author since edited it out, since that wasn't the point he was trying to make! :)

</comment></comment></comment><comment><USER11> <rant> This brings up troubling thoughts of how the web (as well as personal choice and a growing economic disparity) is being eroded by the senseless advance of technology.

Recently someone's start-up website refused to work on my Android phone because it didn't support WebSockets. I thought, "Wow, what a bunch of dicks. Now I have to get a better phone that can run Firefox Mobile or something." But I can ignore that one website.

Imagine every popular website requiring technology that only expensive cutting-edge devices can utilize. At some point you'll have to have a certain amount of disposable income just to browse the web. This should not be the case; everyone on the planet should some day be able to use the internet to the fullest given the most modest means. Even if you stick to non-mobile surfing, is your current computer's operating system modern enough to run the latest and greatest web browsing app? If you wanted to upgrade the OS, would you be able to, considering how old your computer is?

The World Wide Web is not meant to be a platform for an operating system on top of an operating system. It's meant to provide formatted data with inline images and hyperlinks. A ubiquitous, universal, cross-platform resource for information. I wonder if people consider accessibility anymore. </rant>

<comment><USER12> Wait, what? Why should we be holding back the web to satisfy your definition of what the web should be?

It's up to websites to decide what technologies to take advantage of, as it's always been. JavaScript is ubiquitous now, but it wasn't always -- some sites used it, others didn't. The web didn't die, and eventually adoption became widespread. Same goes for other advancements. If I want to browse Wikipedia, I should be able to do so without having a top of the line computer running the latest browser (although Firefox runs on just about anything). However, why should we not allow someone to create, say, a multi-user realtime image editor, merely because it doesn't run on your computer?

The irony of your rant is that these APIs are to help combat exactly what you're afraid of. In theory, these APIs will eventually work on an iPhone, WP7 or Android phone. Currently, you need to buy an iPhone if you want to use an iPhone app. These APIs were created in order to make "apps" platform agnostic, via the web.

<comment><USER11> Sure, assuming the device supports the API. We all know about Apple's fascist policies about what its apps can and cannot do. They can always choose not to support your app or your app's features if it's in their best interests.

Alas, I think you miss my point. It's not just that "the web isn't the web anymore." It's that this push for more and more technology where it isn't needed will eventually impede people's lives (and truly it is not needed - <USER2> webpage that emulates an app should just be an app). It adds to the further complexity and cost of the modern age without giving us something of fair value in return. It's an unfair tax on humanity.

I understand that somebody has a need for a multi-user realtime image editor. But that should be _an app_ , not a web page. Obviously not every device is going to be able to do everything. But in most cases they could if they were implemented the proper way.

I guess this kind of argument isn't for Hacker News. I'm the kind of guy who wants to throw his smartphone away, who doesn't own a TV, who doesn't go on Facebook. I'm not interested in giving chunks of my life over to consumerism and mindless wastes of entertainment. And i'm not interested in pushing new technology where it was never meant to be just because it _can_ be done.

By the way, JavaScript never should have been ubiquitous. It started as a hack and now it's a monster.</comment></comment></comment>


Beautify the Git commit hash (have a look at the commit hashes on the right) - <AUTHOR> https://github.com/vog/beautify_git_hash/commits/master

<comment><USER2> Interesting. This script modifies the commit timestamp until the commit object hashes to a SHA-1 that starts with a prefix specified on the command-line. It seems like it was used on the repo itself with prefixes of 0001, 0002, 0003.

        $ ./beautify_git_hash.py 0001

I wonder if this somehow increases the probability of a hash collision, if only ever so slightly? In any case, it's a neat hack!

The script prints a suggested "git commit --amend" command so don't run the suggestion if you've already pushed the head of your branch.

<comment><USER3> SHA-1 has a digest size of 160 bits. The first two bytes of these beautified hashes are predetermined, which lowers the size to 144 bits. For a more than 50% chance of a collision, more than 4 sextillion hashes[1] would have to be generated, compared to 1 septillion hashes[2] for the normal digest. A difference of an order of a magnitude, yet absolutely nothing to be worried about. Collisions are vastly more likely to be caused by a stray cosmic ray than actual chance.

[1] 2^(144/2) ~= 7e21

[2] 2^(160/2) ~= 1e24

<comment><AUTHOR> This is only true if you use the same prefix for all commits. However, the script takes the prefix as argument, which allows you to use prefixed like 0001, 0002, etc.

Apart from that, _this is a toy project and by no means meant seriously_.

<comment><USER3> I didn't take it seriously of course, I just saw this question and I was myself curious what the chances of a birthday collision actually are.

</comment></comment></comment></comment><comment><USER4> Git history is not linear, so numbering commits sequentially is meaningless.

Git already has a mechanism for naming commits, anyway. They are called "tags".

<comment><USER5> Git's going to have built-in "generation numbers" soon. [http://permalink.gmane.org/gmane.comp.version- control.git/17...](http://permalink.gmane.org/gmane.comp.version- control.git/177146)

edit: jacknagel points out that they actually didn't go with this after all. Insted: [https://github.com/git/git/commit/ffc4b8012d9a4f92ef238ff72c...](https://github.com/git/git/commit/ffc4b8012d9a4f92ef238ff72c0d15e9e1b402ed)

<comment><USER4> So imagine your history looks like this:

         __C__
        /     \
       A---B---D

A is commit number one. D is commit number three. If B is two, then what is C? Assuming you can come up with a consistent view when all the information about the branch topology is available, what about when people have disconnected branches? How do you avoid duplicate generation numbers? If you can't avoid duplicate generation numbers, what's the point of having them? "Fixed in commit 2." Great, which commit 2 did you mean?

<comment><USER5> You have duplicates, B and C would have the same generation number. It just represents length of the longest path from the root commit. This is already calculated internally to optimize several operations, so they were considering making it part of the commit data.

It often won't uniquely identify commits, but revision numbers in SVN are also sometimes used imprecisely ("oh, it was around R1500"), so I think it would have value.

<comment><USER4> Yeah, but you _know_ people want this so they can write things in their bug tracker like "fixed in r1232" instead of "fixed in 2c4d96d1dc2d12afd486561329a9a7b74d4ae110".

<comment><USER6> This will give you r/1232:

[https://github.com/stephenh/git- central/blob/master/server/p...](https://github.com/stephenh/git- central/blob/master/server/post-receive-commitnumbers)

(It makes a tag-per-commit; I'm not saying that's necessarily a good idea, but if you _really_ want revision numbers...)

</comment></comment></comment></comment></comment></comment><comment><USER7> While the beauty may be in the eye of the beholder, for X11 based systems this is actually a step back.

I used to be able to highlight and paste the hashes, now the hash string is "hidden" inside a button where text link would do. Sure, as an ugly, kludgy workaround there is the flash-based "copy to clipboard" button, but that only works with ctrl-v pasting, not the middle mouse button. Good luck pasting that into an xterm. So it's either copy-type or click on the link and find the sha in text form on the resulting page.

I found myself using git log a lot more frequently during the past few days.

<comment><USER8> It's referring the the hashes themselves (0001..., 0002..., 0003...), not the html/css GitHub uses.

</comment></comment><comment><USER9> really need this sequencing hash hack when we have date/timestamps for sequence?

<comment><USER2> Righty-o, it's purely for fun. @vog: merge my pull request, man. There's a post-commit hook in there. I think we finally solved the SHA-1 vs r#### argument ;-)

<https://github.com/davvid/beautify_git_hash/commits/master>

<comment><AUTHOR> Sorry for not having accepted your patches, but I explained the reasons in a comment on your pull request:

<https://github.com/vog/beautify_git_hash/pull/1></comment></comment></comment>


Weekly Inspiration for Designers #74 - <AUTHOR> https://medium.muz.li/weekly-inspiration-for-designers-74-f3275368e786#.byr1f6x8p <comment><USER2> I love so much Weekly Inspiration by Muzli</comment>


Ultimate Guide to Winning Your White Elephant Gift Exchange Using Game Theory - <AUTHOR> http://fivethirtyeight.com/features/white-elephant-yankee-swap-game-theory/ <comment><USER2> I played this recently and my strategy was to always steal the most desired gift (if possible). That way someone would almost always take it from me, and then I would have the opportunity to pick the item that was most desirable to ME!</comment>