I built a DIY license plate reader with a Raspberry Pi and machine learning - <AUTHOR> https://towardsdatascience.com/i-built-a-diy-license-plate-reader-with-a-raspberry-pi-and-machine-learning-7e428d3c7401 <comment><USER3> "Machine Learning" is the wrong tool for the job here.

Tesseract OCR can do this, using only the Raspberry Pi, at a "good enough" framerate for any real driving situation.

<comment><USER4> Tesseract only does well if the input is clean, aligned, two tone image, already cut down -- but LPR images you get from a moving camera are anything but.

Machine learning is a fine tool for this job. The specific machine learning setup is an overkill, though.

<comment><USER5> Most of these problems are much easier to solve by simply picking a better camera. Moreover license plates are specifically made to be easier to read (ie reflective).

<comment><USER4> No they are not. Converting a semi-shaded black-on-yellow to clean black-and- white is _not_ a matter of picking a better camera. Aligning it into am axis aligned rectangle form (from whatever angle you managed to capture them) is _not_ a matter of picking a better camera. Tesseract is _really_ bad unless your input is _really_ clean.

Reflective helps you only if you actually shine light from the direction of the camera. which you can't practically do from within a car (the setup described in the post), and in most jurisdictions cannot legally do at all.

</comment></comment></comment></comment><comment> semi-extrinsic The solution described in the blog uses 12 Nvidia T4s, which are basically specialized RTX 2080s. Depending on what vCPUs etc. get used, it's running 1000-1500 W of computing power continuously.

If their car was electric, this project would be increasing the power consumption of the vehicle by around 10%.

<comment><USER6> I may have missed something, but I believe the T4s are running in the cloud, so it wouldn't have any effect on the car's power consumption.

<comment> semi-extrinsic To clarify, I mean indirectly the power consumption. I guess this will become an important point of discussion soon-ish, as we get more and more electric cars and ML stuff in them.

My view is, if your car uses electrons, and some of those are for compute, and you just offload the compute to the cloud, you haven't actually reduced the total electricity consumption.

Similarly here, the total "footprint" of the car is increased by adding this feature.

<comment><USER7> Whether the car uses electrons or fossil fuels is pretty irrelevant, right?

<comment><USER8> I think the comparison with an electric car is to illustrate that this cloud solution is a waste of energy.

</comment></comment></comment></comment></comment><comment><USER9> The video referenced in the blog: [https://www.youtube.com/watch?v=gsYEZtecXlA](https://www.youtube.com/watch?v=gsYEZtecXlA)

mentions that they used 20 K80 instances to get real time inferencing. That seems a bit excessive IMO for an object detector.

<comment><USER10> I'm the creator here. Yeah, 20 K80s is a bit excessive. That's because cortex (cortexlabs), which is the ML-model-deployment platform didn't initially have multiprocessing on each of their replicas - so I was bound to using just one CPU per GPU. AWS has instances with 4, 8, 16 vCPUs and so on.

Once cortex started supporting gunicorn (still yet unreleased but present on their master branch), I was able to reduce the number of GPUs significantly. Finally, the detector only needs 2 T4 GPUs and the identification part is the most expensive one (10 T4s GPUs) for a grand total of 12.

Converting the models to use single-precision could further reduce the need to about 1.5 GPUs for T4s or just 1.2 GPUs for V100 - which in both cases it would still mean using 2 GPUs.

<comment><USER9> Consider using a smaller, lighter-weight network (e.g. TinyYOLO) and object tracking (instead of running inferences on every camera frame) for faster throughput -- I imagine you should be able to get through with <1/4 of a V100 and still real-time for all practical cases.

You can also customize the network to your use case, e.g. you don't need YOLO's default 5 anchor box sizes if you know the thing you're detecting is a license plate.

Also, profile your code and see where your bottleneck is. If your bottleneck is at NMS for example there are things you can do to speed it up. I've seen a lot of cases where the neural network runs fast but there's a lot of Python bloat for pre/post-processing -- not sure about yours without seeing code.

You really should be able to run a license plate detector/reader on something a _lot_ smaller than a V100. A Xavier or quite possibly even a Jetson Nano would very likely be good enough if you use it well.

<comment><USER10> I like all of your suggestions. I've been thinking about using TinyYOLOv3 as well. Provided the training set is considerably bigger than my own (I've created about ~550 samples and fine-tuned the model with them), you could end up with a very capable detection system that uses very few resources.

Object tracking is yet a very good idea. I will consider it. Anchor-box tuning is another very good idea.

Also, the CRAFT text detector that I'm using should IMHO be removed. Instead just use a very well trained text recognizer (like the CRNN I'm using). The text detector is expensive computationally since it's based on the VGG-16 model.

Then convert the models to use mixed-precision.

All in all, I think the performance improvements can be anywhere between 1 and 2 orders of magnitude.

</comment></comment></comment></comment><comment><USER11> Plenty of room for optimization. Raspberry PI has enough power to detect license plate numbers on its own, offline.

</comment><comment><USER12> The obvious question is why not use a local accelerator?

Either the Neural Compute Stick or the Google Coral both have more than enough grunt to run real-time object detection models. Both will run on USB2 power. I don't know the overhead of good OCR, but license plates are a very standard format so perhaps you could train a second detector to extract the letters?

Even if you do OCR in the cloud, local bounding box extraction would save a huge amount of bandwidth.

<comment><USER13> Hey, founder of a relevant startup here. Just wanna chime in on OCR + bounding boxes performance. We offer text recognition with bounding boxes as a service. Our average processing duration, between reading bytes off the wire and writing the JSON response, is just under 3 seconds on average. Obviously that throws it out the window for frame-by-frame applications, but I think it's still worth mentioning. The recognition is just as accurate as Google Cloud Vision —- it can handle human handwriting and even cursive, in most cases.

If you're interested in trying it out: [https://siftrics.com/](https://siftrics.com/)

<comment><USER14> Off topic: great video, love it how you explain what it is about. Good luck!

</comment></comment></comment><comment><USER15> I really do appreciate the effort and the quality of the writeup, but this approach is a very inefficient and round-about way of going about things.

You can do real-time number plate recognition on a Pi3/4 with a Coral TPU or Movidius 2. Both of which costs ~US80. It's probably got a lot to do with hammers and nails. Not everything needs to be 'web-centric' or 'cloud based'

</comment><comment><USER16> Surprised by the negativity in the comments. This is an extremely impressive presentation of ability to put together current technologies and get the thing working front start to finish.

A+, would hire.

<comment><USER17> The reason for the negativity is that this demonstrates the "Design by StackOverflow" mentality where the solution is like swatting a fly with a sledgehammer and no real domain knowledge. Plus the author didn't even train the neural nets: it's just a LEGO project. I'd higher this person to be a lab intern, but nothing above that. The fact the author couldn't solve it locally and had to invoke the CLOUD is... laughable. This problem has been solved for over two decades on lesser hardware.

<comment><USER18> TL;DR: reinventing wheels is a good way to learn a lot.

For trying out something in a few hours, of course you don't want to spend hundreds of hours setting it up, by definition. Yes, the result is "just about works, but doesn't scale" \- but that's the point of _experimenting_. Sure, this _is_ a LEGO-style experiment in reinventing the wheel, but exactly for that, an excellent way to start learning about this problem domain: power consumption? Latency? ML basics? Sure. That's hacking at its core - <USER2> though the project is rudimentary.

<comment><USER19> > Sure, this is a LEGO-style experiment in reinventing the wheel

If I'm not mistaken Larry Page used to be praised some time ago for building a printer out of LEGO pieces (that may just be an urban legend, I admit I never verified this information).

</comment></comment></comment></comment><comment><USER20> Would be interested in the $/hr cost to run something like this OP, 4G data & AWS bill combined.

</comment><comment><USER21> Ok, I have a use case for this. If you could figure out how to get it off the cloud and low power, it would be awesome to have one of these on the gates to my house, so when I drive up the plates are automatically recognized and the gates open to my car.

<comment><USER22> The best password is the one written in plaintext on the outside of your car.

<comment><USER18> Don't rely on garage openers for security, either: the door relies on a rather simple password scheme. In other words, treat it as a garden fence, not a blast door.

[https://www.geek.com/gadgets/a-32-hacking-tool-can-open- your...](https://www.geek.com/gadgets/a-32-hacking-tool-can-open-your-garage- door-and-unlock-your-car-1630657/)

(Perhaps recognizing the car's license plate plus MAC address would be more secure...? Many cars use BT/WiFi nowadays.)

</comment></comment></comment><comment><USER23> This is nice from an academical standpoint since it can scale to track the cars, infer speed of the cars, track lanes, signs maybe experiment and try to do some predictions(...) But, if the target is just to find plates and recognize the letters I've seen this being done with only a RPI. (I am actually considering to do it just for fun :))

</comment><comment><USER24> What are the privacy implications of this? For example, in the EU under GDPR, would you really be allowed to collect information on, for example, license plates, time and location? It seems to me that you could argue that license plates are "personally identifiable information" and collecting this type of data could, with or without intention, mean that you are collecting data on people's whereabouts.

<comment><USER25> Not every plate may idenfity a person (cars can be owned by companies and used by different employees and so on), but a significant number of cars is owned and driven by a single private owner. You can't easily discern if a license plate does or does not map to one individual, thus if you can't prove that the license plate does not map to a specific person, you should assume it does.

Thus the license plates can easily be argued they are PII.

</comment></comment><comment><USER26> So now medium is straight up not letting people read an article unless they're logged in ... Disgusting.

<comment><USER27> Disgusting, indeed. But as long as these links are accepted here, nothing won't change.

Take this in the meantime: [https://outline.com/qsv7ab](https://outline.com/qsv7ab)

<comment><USER28> Would be great if we could have built-in Outline support on HN, or some kind of bot commenting a link automatically when someone posts a story with a paywall. Just throwing an idea out there. :)

<comment><USER29> That's a great idea actually! @dang are such bots allowed in HN? I can roll it out pretty easily with Monitoro ([https://monitoro.xyz](https://monitoro.xyz)) and would be happy to cover the costs.

</comment></comment></comment></comment><comment><USER30> It's just a question of time before people can hack their own similar facial recognition system. The new glasses from Bosch, with a projector straight on to the retina, is an obvious choice for displaying personal info about everybody in reach of the camera. With 5G, everybody has a reliable access to all the computing power needed.

<comment><USER31> Link ?

<comment><USER32> They are probably talking about these: [https://www.bosch- sensortec.com/products/optical-microsystem...](https://www.bosch- sensortec.com/products/optical-microsystems/smartglasses-light-drive/) The full video looks neat [0], but like all AR concepts it's made with CGI.

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

<comment><USER30> According to this article, the image quality on the new glasses from Bosch, should actually be very good: [https://spectrum.ieee.org/tech-talk/consumer- electronics/gad...](https://spectrum.ieee.org/tech-talk/consumer- electronics/gadgets/bosch-ar-smartglasses-tiny-eyeball-lasers)

It is easy to imagine someone with these glasses from Bosch, walking around in a bar. Personal information about other people would projected right to the retina.

</comment></comment></comment></comment><comment><USER33> Interesting that in EU such project just illegal from start

<comment><USER34> It's not.

</comment></comment><comment><USER25> Last I knew Romania was in EU, thus posting other people's personally identifiable information on internet should be covered by GDPR and thus be legally technically illegal.

<comment><USER35> licence plate numbers are not PII

</comment></comment><comment><USER36> Epic work, well done!

What FPS you getting out of it?

<comment><USER10> Creator here. I get about 30FPS. The more compute power you throw in, the higher the framerate.

It's really buttery smooth if I disable the recognition part and just leave in the detection. Since it's demo project (something I just wanted to experiment with), my focus hasn't been on optimizing it. Lots of improvements could be brought to it.

</comment></comment><comment><USER37> Cool!</comment>


Using tame() in userland - <AUTHOR> http://marc.info/?l=openbsd-tech&m=144070638327053&w=2 <comment><USER2> For those wondering what this is about: [http://marc.info/?l=openbsd- tech&m=143725996614627&w=2](http://marc.info/?l=openbsd- tech&m=143725996614627&w=2)

         The current process is forced into a restricted-service operating mode.
         A few subsets are available, roughly described as computation, memory
         management, read-write operations on file descriptors, opening of files,
         networking.  In general, these modes were selected by studying the
         operation of many programs using libc and other such interfaces.

Sounds pretty interesting.

<comment><USER3> It seems really interesting, and a good idea.

What I don't understand though is the incentive, what motivates a program- author to "[b]e careful writing such diffs; you need to fully understand the program and handle all cases"?

<comment><USER4> In addition to the other fine replies, I'd observe this falls in the set of things that are pretty easy to use if you start with them from scratch, but are hard to retrofit on to existing code. To retrofit requires the mentioned extensive knowledge of the target codebase... to use it on a new codebase just requires you to do any sort of testing at all, note the new thing you wrote is a security violation, then think about what that means and what you should do about it at precisely the point in time you have all the relevant context loaded in your brain.

At the moment the motivation is to armor existing code, but the general case for tame across its entire lifespan is to be used in new code. In that case the motivation is the same as any other security practice... not to see your code be fingered as the vulnerability that let $BAD_THING happen.

<comment><USER5> i think the recent hiding of unused libc symbols is related to the tame effort.

<comment><USER6> No, entirely unrelated.

</comment></comment></comment></comment></comment><comment><USER7>
      --- bin/echo/echo.c	14 Dec 2014 16:55:59 -0000	1.8
      +++ bin/echo/echo.c	26 Aug 2015 22:07:37 -0000
      @@ -30,6 +30,8 @@
        * SUCH DAMAGE.
        */

      +#include <sys/tame.h>

MUCH TAME!

</comment><comment><USER8> Hooray simple security hacks!

....and booooo simple security hacks.

In the previous thread, someone says _" I really like this solution. Far better than pissing around with SELinux configuration and it's well contained."_ Which is a little bit like saying, "I really like these airbags. Way easier than using a seatbelt."

<comment> vezzy-fnord It's actually a consistent mechanism for doing privilege dropping on a whitelist level. The same cannot be said for an API like POSIX capabilities.

<comment><USER9> My initial reaction was that it didn't match my use. It doesn't seem possible to do what my use would require, which would be things like dropping specific identified privileges without affecting what other privileges the process might currently have. This would need some way for reading the process's current restrictions. The current API is write-only.

Moreover none of the privilege sets seemed to allow the possibility of chain loading once privileges had been dropped, as none of them allow execve(). OpenBSD tame() is, as its blurb states, not designed with the model in mind of programs where initialization parts (consider UCSPI servers, for example) are in a separate executable that then chain loads through common privilege dropping tools to the main part of the program.

It's not as easy to wrap tame() into some shell-level composable tool as it is to wrap jail() into the jexec tool.

</comment></comment></comment><comment><USER10> Would that work for tools like busybox? I guess it'll work as long as it's set only once, but doesn't busybox has a mode where one command can call internally another, and then it'll have to set tame() again, or maybe even restore it?

<comment><USER11> The docs say you'll get EPERM for trying to increase permissions, so I'd guess there's no way to restore it.</comment></comment>


You're using RSS wrong - <AUTHOR>

If you have a mountain of unread feeds in your RSS reader you are doing it wrong.
RSS works best if you subscribe to a large number of blogs who post rarely. Then you'll only have a few hundred posts per week, most of which will be high quality.
Then follow ~150 selected people on Twitter and you'll never miss out on an important story from one of the big blogs. <comment><USER2> Ha. Good one. And eminently practical advice, too.</comment>


Microsoft unveils $40bn stock buy-back - <AUTHOR> http://news.bbc.co.uk/2/hi/business/7630508.stm

<comment><USER2> If I were Microsoft, I'd much rather spend that money to buy Microsoft stock rather than Yahoo stock. I actually don't think MS stock is a bad buy right now - they're not in debt (never have been in their history) and they're a year or so out from the next versions of their flagship products (Windows and Office), which have historically given their stock a little boost.

</comment><comment><USER3> Why don't they wait 5 months? They'll be able to buy back twice as much stock then.</comment>


China's Great Famine (2013) - <AUTHOR> https://www.theguardian.com/world/2013/jan/01/china-great-famine-book-tombstone <comment><USER2> I think this is one of the biggest thing people forget about China. Their wealth is extremely new found. A lot of people alive today still had some sort of relative that has starved to death, particularly in the same age as our baby boomer generation. That's why the Chinese government is extremely strict and the citizens are willing to be "subjugated". Time were extremely tough for them not even two-three decades ago.

Side note, I believe most historians will agree that any modern famine within this past century is man-made. They are either created or mitigated poorly because of ignorance.

<comment><USER3> This explanation sounds nice until you start thinking about other countries which experienced famine in the last century and don't look anything like china...

<comment><USER4> What famines were there where not either the government caused or ignored the problem, a colonial power ignored or caused the problem or a war was going on?

<comment><USER5> [https://en.m.wikipedia.org/wiki/Famine](https://en.m.wikipedia.org/wiki/Famine)

Here's a cut n paste

Chinese scholars had kept count of 1,828 instances of famine from 108 BC to 1911 in one province or another—an average of close to one famine per year.[50] From 1333 to 1337 a terrible famine killed 6 million Chinese. The four famines of 1810, 1811, 1846, and 1849 are said to have killed no fewer than 45 million people.[51]

Japan experienced more than 130 famines between 1603 and 1868.[52]

<comment><USER6> That's not even close to answering the question. People dying in a regional famine is the fault of the government.

More widely crop failure and famine are very different things. Consider, Ireland was exporting food during the Irish potato famine.

</comment></comment></comment></comment></comment><comment><USER7> "Hungry Ghosts: Mao's Secret Famine" is a great book on the subject of the Chinese famine.

</comment><comment><USER8> very similar to the great famine in USSR in 1932-33

[https://en.wikipedia.org/wiki/Soviet_famine_of_1932%E2%80%93...](https://en.wikipedia.org/wiki/Soviet_famine_of_1932%E2%80%9333)

One can only wonder why ... Or just look at Venezuela and North Korea today.

From that time we have an expression "like a hunger-stricken from the Volga region" ("golodayuschiy s Povolzh'ya", the region among the most affected by the famine) meaning like a completely debilitated by prolonged hunger and by overall extremely bad conditions person.

<comment><USER9> The main idea of communism is to kill «bad» people («Bourgeoisie and Intelligence», i.e. richer and smarter people), to grow «soviet people», which then build communism. Initial estimate in 1918 was to kill 10% of population. To do that, secret police created to spy on people minds, to find bad ones. Secret police reported that majority of Ukrainians are anti-communists. So, idea was simple - communists need to kill majority of «bad» Ukrainians, then communism will happen.

You may want to read [0] or similar documents for more information.

[0]: The new Soviet archival sources Hypotheses for a critical assessment Andrea Graziosi, 1999

<comment><USER10> >The main idea of communism is to kill «bad» people («Bourgeoisie and Intelligence», i.e. richer and smarter people), to grow «soviet people»

No modern Communist academic nor Marx himself spoke in these terms. You're projecting history onto ideology, which doesn't always work. The Marxist students being persecuted by China this year would very much disagree with your analysis, even having experienced this 'communism'.

<comment><USER9> First, you are mismatching communism ideology with transition from capitalism to communism. If somebody want to rule a country, he must use violence to beat previous government, no matter what is said in a book.

Second, you are mismatching theory with practice.

<comment><USER10> All revolutions are structured like that, from the German to the French to the American to the Russian to every war of independence. Violence is an unfortunate effect. Practice is informed by theory, and theory is informed by practice. A glance at Marxist literature would show this.

</comment></comment></comment></comment></comment><comment><USER11> The famine itself was, of course, unimaginably terrible. I feel that another terrible thing this article highlights is the sad reality of political parties, systems and organizations in general:

 _" The root problem is the problem of the system. They don't dare to admit the system's problems … It might influence the legitimacy of the Communist party"_

</comment><comment><USER12> The same happened in Europe in the 1930s: [https://en.m.wikipedia.org/wiki/Holodomor](https://en.m.wikipedia.org/wiki/Holodomor)

</comment><comment><USER13> China gov't still deny this history, many people still deny believe this history, if you talk about this in China, they may think you're a spy.

<comment><USER14> This history is well known in China and part of the history curriculum.

</comment></comment><comment><USER15> > "The Chinese people were cheated. They need real history."

Can someone fwd this to Sundar Pichai in re: Project Dragonfly?

</comment><comment><USER16> Why is this being dug up from 2013, and not even marked as such?

<comment><USER17> Sometimes we miss the year of an article and need users to point it out to us. I've added it now.

Historical material is always welcome on Hacker News. Dig away!

</comment></comment><comment><USER18> Do you think it's debatable to compare the deaths of concentration camps in Germany, and the deaths of the great famine?

You often see this comparison being made (whatever the reason is), to me those deaths are different because the intention was different.

The shoah was aimed at certain people, while the great famine killed indiscriminately.

<comment><USER19> The Holodomor was aimed at Ukrainians by Russians.

The Great Famine was aimed at every commoner by the Politburo.

<comment><USER8> Anybody who care to open wikipedia would see straight through that propaganda about Ukranians and Russians. [https://en.wikipedia.org/wiki/Soviet_famine_of_1932%E2%80%93...](https://en.wikipedia.org/wiki/Soviet_famine_of_1932%E2%80%9333)

Note: my mother side of the family were generational peasants in the Kiev region, the families of 5 siblings of my grandfather lived there through that time (the granddad took his family to look for better life elsewhere several years before that)</comment></comment></comment>


Show HN: 50M stock photos for $12.95 a month - <AUTHOR> https://www.canva.com/photos/ <comment><AUTHOR> Hello HN!

Our team at Canva have been working on this project for over a year now and it's so exciting to finally show it to the world.

There are plenty of stock photography sites in the world, but all of them are way too expensive unless you're some big corp. We've managed to work with our contributors to offer unlimited access to premium stock photography photos, many of which cost hundreds by itself, into a single subscription.

We'd appreciate any feedback and constructive critique you have! This is our MVP, after many late nights and Uber Eats in the offices, so flows might not be the most optimal yet, but really keen to get your thoughts :)

<comment><USER2> This looks fantastic and great value. Is their an API? We're heavy users of the other sites you mentioned in that way.

While I have you, what's the ETA on the Canva button?</comment></comment>


Design Systems Handbook - <AUTHOR> https://www.designbetter.co/design-systems-handbook <comment><USER2> I'm on the team that helped produce this book, as well as the other books on the DesignBetter.Co site. Happy to answer questions.</comment>


Cooles guitar game for iPhone by Ronald - <AUTHOR> http://www.kickstarter.com/projects/iphoneairguitar/air-guitar-move-for-iphone

<comment><USER2> This is awesome--can't wait to get one (disclosure: I am an investor).</comment>


To install on "Other Distributions" you need to install apt-get - <AUTHOR> http://support.typora.io/Typora-on-Linux/ <comment><USER2> Not uncommon with proprietary software.</comment>


Chipotle's Mandatory Arbitration Agreements Are Backfiring Spectacularly - <AUTHOR> https://www.huffingtonpost.com/entry/chipotle-mandatory-arbitration-agreements_us_5c1bda0de4b0407e90787abd <comment><USER2> They could pay their workers and not have this problem.

<comment><USER3> That'd require not thieving from workers. Wage theft is the most common crime committed in the USA, yet we don't see managers and owners that commit this crime prosecuted in any meaningful way, at most they'll be asked to pay back wages: [https://www.epi.org/publication/wage-theft-bigger-problem- fo...](https://www.epi.org/publication/wage-theft-bigger-problem-forms-theft- workers/)</comment></comment>


Looking back at how Signal works - <AUTHOR> https://signal.org/blog/looking-back-as-the-world-moves-forward/ <comment><USER2> I love Signal and use it as much as I can, but I'm thinking of switching to Matrix solely because the desktop client is pretty bad. It won't show me messages until it syncs everything (so I can't even see old messages while things sync), and, what's worse, it skips messages, and multi-device just doesn't work. My laptop just shows "Message could not be decrypted" until I delete everything and reset.

I'm not sure why it works so poorly after years of existence, but unfortunately I'm losing hope that it'll be fixed. I sometimes feel like the Signal team doesn't use their product, or they would have noticed this. Meanwhile, yes, Matrix took years to add encryption, but it works much better than Signal, even with quite a few small bugs.

<comment><USER3> But they have stickers! Who needs good sync when you have stickers! Oh, and arbitrary emoji reactions!

Seriously... I do not understand how they keep investing in this gold-plating when the plumbing keeps getting clogged up.

<comment><USER4> Signal doesn't have arbitrary emoji reactions, that is one feature I do wish it had. Though obviously I'd prefer a better desktop client first.

<comment><USER5> They're coming, currently in beta (source: am using the beta, it's public, check the play store page)

</comment></comment></comment></comment><comment><USER6> > how we think about concepts like privacy, security, and trust

I was disappointed to see that a mobile number is needed and that this number is shown by default in groups. Mobile numbers are much more trackable then email addresses in my opinion. And I do not understand at all why others should be able to see them so easily.

So I now prefer Telegram because at least it hides numbers in groups by default.

<comment><USER7> Burner sim to setup and throw away addresses this concern.

Telegram, messages in plaintext on the server? Encryption that isn't open? Yeah telegram is a bit of a non-starter if you have these kinds of concerns as far as I'm aware.

<comment><USER8> In most European countries you need to submit your ID to get any sort of working SIM card.

<comment><USER9> If that's the case doesn't it matter even less that signal requires it since it's already known anyway?

Signal's use of phone numbers as IDs means they don't have to have any of your contacts sent to their servers.

As shown in the article they have no metadata and nothing to reveal beyond your phone number and when you signed up.

These other apps send your social graph to their servers, track and store metadata, don't have encryption on by default, roll their own cryptography, or some combination of all of these things.

The phone number obsession on HN seems dumb to me - a meaningless thing for people to repeat and complain about that doesn't actually matter so they can sound like they know what they're talking about.

I don't get it.

The only real criticism I have for signal is that they're not federated so they're vulnerable to shutdown. I think that's okay though because we have Matrix working on that problem and having both is probably a good thing.

It's also a thoughtful and intentional choice: [https://signal.org/blog/the- ecosystem-is-moving/](https://signal.org/blog/the-ecosystem-is-moving/)

The response from Matrix: [https://matrix.org/blog/2020/01/02/on-privacy- versus-freedom](https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom)

<comment><USER8> Assuming you're using Signal for organizing something the government doesn't want you organizing, if one member of the group gets rubber-hosed into unlocking their phone, the govt instantly gets a list of verifiably correct names of people involved. In contrast, with a service that lets you use usernames that maneuver would reveal nothing but those usernames (which are as pseudonymous as it gets).

<comment><USER10> One of the other problems with using phone numbers, is that it provides an opening for adversaries. Now they know your phone number, which can be used for social-engineering attacks to attempt to bypass 2FA for any other online services tied to your phone number. Either for 2FA or for account- recovery/i-forgot-my-password functionality. 2FA by SMS is wrong and broken and nobody should use it, but they do.

Adversaries will attempt to social engineer customer service for your phone carrier into issuing them a new SIM or porting out the number, so they can receive verification SMS and phone calls.

<comment><USER11> Signal uses a registration pin to prevent that exact attack.

<comment><USER12> Maybe I misread, but the GP doesn't seem to be talking about impersonating a user on Signal, but rather impersonating that user on other websites that depend on SMS 2FA sent to their phone number that is now visible through Signal.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> What happens to Signal when the EARN It Act passes? I assume that eventually the Apple App Store and Google Play Store will just stop allowing it to be downloaded if they do not add the backdoor in? Is there a workaround that will allow people to use it still? I've heard people mention locating the servers in other countries, but wouldn't the various App stores be bound by US law and still not allow them?

<comment><USER14> Signal's official statement on the EARN It Act is here: [https://signal.org/blog/earn-it/](https://signal.org/blog/earn-it/)

<comment><USER15> Thanks for the link. There's a subtle threat in there, that they'll move out of the country if they have issues which I think a lot of tech companies would.

This bill is so stupid in that tech companies can relatively easily move.

<comment><USER16> The legal entities can move to other jurisdictions, sure, but it doesn't matter because app distribution still occurs primarily through USA-based Google Play and USA-based Apple App Store—both of which can easily geofence apps as they please (or as they're required).

This is one of the reasons I've started to appreciate Matrix a lot more lately.

[https://matrix.org/blog/2020/01/02/on-privacy-versus- freedom](https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom)

<comment><USER14> Putting aside Signal officially declining to the add option to discover or manually add a server via the client, theirs nothing stopping anyone from going to GitHub, downloading the code for the server and client, editing the code however they see fit as long as it follows the legal guidelines.

<comment><USER17> > long as it follows the legal guidelines.

So like, as long as they add in the backdoor?

<comment><USER18> Nope. But following GPL open source license guidelines and releasing your changed codes. And not using signal name and their copyright materials.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> I'm glad to see the discussion about what privacy should look like progress, with increasingly big actors treat data as something too delicate to play warden until the next breach.

But it just feels cheap and detrimental to LARP as a tool for revolutionaries. I want a clear concept of privacy for a stable society to rely upon. That even the most trustworthy authority be kept out by design as a security principle. I don't want my messaging app to be opinionated, pick sides or declare themselves part of the ongoing "progress". Will they sing the same tune when it's other group taking the streets? Because everyone has a different idea of the kind of revolution that is needed, and certainly my phone should not have a say.

<comment><USER20> > feels cheap and detrimental

Cool, pick a new app.

It's naive to think a small group will work against very powerful forces and against all odds and not be ideologically driven.

<comment><USER19> I'm talking about the discourse sorroundig privacy, not literally specifically about my phone. I hate to see it marketed as a tool of revolution instead of just common sense practices.

Your use of "ideologically driven" is confusing. Of course they should be driven, by their ideology on how a messaging app should be. But how could their opinion on the protest drive them? Just some weeks ago a whole different crew was taking the streets fighting for their own "freedom reasons". Some years ago there was the sad tiki parade.

It's like setting up a gun shop in Syria and claim your guns kill "the bad guys", whatever that means to the customer.

I'll choose the app that works best for me, and will call it out when someone feeds the meme that privacy is for rioters, unwittingly even.

<comment><USER20> > how could their opinion on protest drive them?

Some people believe in first and fourth amendment rights.

Moxie, one of the original developers of the Signal protocol:

 _Tracking everyone is no longer inconceivable, and is in fact happening all the time. We know that Sprint alone responded to 8 million law enforcement requests for real time customer location just in 2008. They got so many requests that they built an automated system to handle them.

Combined with ballooning law enforcement budgets, this trend towards automation, which includes things like license plate scanners and domestically deployed drones, represents a significant shift in the way that law enforcement operates.

Police already abuse the immense power they have, but if everyone's every action were being monitored, and everyone technically violates some obscure law at some time, then punishment becomes purely selective. Those in power will essentially have what they need to punish anyone they'd like, whenever they choose, as if there were no rules at all.

Even ignoring this obvious potential for new abuse, it's also substantially closer to that dystopian reality of a world where law enforcement is 100% effective, eliminating the possibility to experience alternative ideas that might better suit us._

[https://moxie.org/2013/06/12/we-should-all-have-something- to...](https://moxie.org/2013/06/12/we-should-all-have-something-to-hide.html)

ACLU: _For more than a decade now, Americans have repeatedly encountered illegal and unnecessary spying by local, state, and federal law enforcement on lawful and peaceful protesters._

[https://www.aclu.org/issues/free-speech/rights- protesters/sp...](https://www.aclu.org/issues/free-speech/rights- protesters/spying-protesters)

EFF: _Theft, damage, confiscation, or forced deletion of media can disrupt your ability to publish your experiences._

[https://ssd.eff.org/en/module/attending- protest](https://ssd.eff.org/en/module/attending-protest)

EFF: _Here is a review of surveillance technology that police may be deploying against ongoing protests against racism and police brutality._

[https://www.eff.org/deeplinks/2020/06/how-identify- visible-a...](https://www.eff.org/deeplinks/2020/06/how-identify-visible-and- invisible-surveillance-protests)

> feeds the meme that privacy is for rioters

Ok, I get it. You're upset about the "rioters". Choose your new app and carry on.

<comment><USER19> But I am not upset in the least about the rioters or anyone else, I can assure you.

Guarding people's privacy and rights to a voice (during protests or otherwise) is a good use of the first and fourth amendments. But let's not confuse form and content. The protests are not advocating privacy, and I'm not even going to voice my opinions about them. There's a difference between backing the content of the protests, and defending the rights that incidentally enable them. The blogpost in question ended with "it's your powerful voices that are out there organizing and advocating for change". I can only construe that as either explicitly siding with whatever ongoing protest there is, or an empty general statement (I assume it's the former though, but makes little difference to me).

I think my point got side-tracked by fault of my own. I don't require every single thing I use not to have ideologies attached, because it's simply impossible. And everyone has every right to voice their idiotic opinions, God knows I'm doing that. But it saddens me that more often than not people who could choose to be content-agnostic instead leverage their position to fight the good cause. And there's a thousand conflicting good causes.

Thanks for the links, btw.

</comment></comment></comment></comment></comment><comment><USER21> I love Signal. I've convinced a multitude of people to switch and some use it day to day currently, but mostly to talk to me. So i feel my contacts do it out of respect and `compatibility` of communication.

What baffles me is the the incompatible feature matrix.

First of all, for some reason iOS users get the updates faster than the Android. I was exploring emoji reactions yesterday while my Android contact admitted the feature was not yet available for his device. I had to double check with Play Store to confirm.

I've found peace with the sync issues for the desktop client though, it got much more stable compare to 8 months ago. What still feels like a massive UX problem is inability to forward messages on the desktop. Given, i have lots of people coming from different places that do not know each other but share same interests it's just painstaking to copy/paste the same URL five time in a row.

And at the same time, there's no support for the Android tablets as secondary devices.

For a person deep in Apple ecosystem it felt weird to learn that Android users don't share the same experiences i do. That makes the sales pitch to try Signal way less appealing for the Android folk.

<comment><USER22> Never tried Signal, but from what you're telling, it seems that they redevelop the core functionalities for each platform.

That's interesting, because i've been looking for a way to share core logic code across platform (mobile & desktop at least), and still haven't found something really user friendly. From my brief lookup (rust & gomobile are the ones i've looked at), it seems that most dev environment seem to support some kind of C-style interfacing, but it becomes much more clumsy as soon as you're trying to have it run on java.

Has anyone found a solution that he's comfortable with and would recommend ?

<comment><USER23> Honestly there are no perfect solutions to this. There are cross platform frameworks (React Native, Xamarin etc) that you can try but you'll definitely hit the wall when trying to access low level native APIs. Kotlin Multiplatform seems to be the step in the right direction. It has first party support on Android and works seamlessly for Android apps, but it's too early to tell for the other platforms. In an ideal scenario, you can share the core business logic using Kotlin Multiplatform and then implement UI and platform specific stuff using native APIs (or something like Flutter (again, not production ready)).

<comment><USER22> I've heard of people running all the logic in a self-contained local http server (developped in whatever language) then rely on local socket connection + protobuf for communicating between the native and the cross-platform codes.

i had hoped some people here would chime in with this trick, but it doesn't seem like it

</comment></comment></comment></comment><comment><USER24> Lately I've been wishing Signal had a bridgefy type mesh mode that enabled operation peer to peer over wifi direct or bluetooth, either directly or via a mesh of such devices.

First I think it would be useful at protests, to preserve privacy (and whatever side of the political divide you are on, I hope we agree that covert government surveillance and tracking of people at a protest is wrong, here, in HK, or wherever).

But it would also be nice to have when outside the reach of cellular or wifi internet. Think camping, traveling, people living with intermittent power, or those who lost power in some sort of disaster or emergency.

I'm honestly not sure if this would be feasible, as I don't grok the signal protocol fully, but the signal protocol does support async messaging.

<comment><USER25> You're looking for the [https://briarproject.org](https://briarproject.org)

<comment><USER24> Unfortunately Briar only handles direct connections, and doesn't work on IOS.

</comment></comment></comment><comment><USER26> The only reason I don't use Signal is because it still uses your phone number for ID. What is even the point of verifying by number?

<comment><USER27> I suspect you are massively outnumbered by people who _do_ use it because it integrates with their existing phone book, and is a drop-in replacement for the default SMS app. Without those things it'd be just another niche app for weird nerds.

<comment><USER28> there is a difference between making it possible to use phone numbers and making it a hard, unavoidable requirement.

<comment><USER29> The fact that you can reliably add Signal users using only their phone number is a feature for the users who don't care about that level of anonymity, though apparently not a feature the developers care about preserving.

</comment></comment></comment></comment><comment><USER30> Is it worth trying to move my friends from WhatsApp to Signal? As I understand it, they're both e2e encrypted.

I'm also trying to move my chats from SMS and Gchat to something encrypted, but am torn between WhatsApp and Signal. The former has more of a buy-in with my contacts already.

I realize WhatsApp is owned by Facebook, but isn't the whole point of e2e encryption that you don't have to trust the intermediate infrastructure? And if you enable the setting to warn if the key changes, there's no danger, right?

<comment><USER31> > As I understand it, they're both e2e encrypted

The important distinction here is that WhatsApp uploads your entire contact book to Facebook. They have up-to-date information on your entire real-life social graph (including people who are not on Facebook and/or never shared their phone with Facebook) and the groups you belong to. If you don't believe me, request a copy of your data in WhatsApp and see for yourself.

So, by using WhatsApp, you are basically snitching on your friends and uploading their data.

Think about the implications — one day, you or one of your friends will add a phone number to Facebook (of course, "for security purposes only, to recover your account". From that moment, Facebook will be able to link an online identity to an offline one, and mine a trove of data: friends, groups, locations.

If you want a different way of looking at it, Facebook paid $19 billion for WhatsApp. That's how much it was worth to them. You don't spend 19 billion dollars just to watch e2e encrypted messages fly by.

I admire the way WhatsApp markets itself as the "encrypted" communications app, somehow hiding the whole problem with groups and contacts as insignificant. Another frequently seen spin is on Signal: that it "only hashes" the phone numbers and that it's "effectively the same thing". Good PR moves, both.

<comment><USER32> It is possible to use WhatsApp (on iOS, at least) without giving it contact access. I do this and it isn't too bad—you still see people's WhatsApp nicknames, so it's not like you're just looking at phone numbers. Of course, that does nothing to stop them from tracking who you actively communicate with.

</comment></comment></comment><comment><USER33> I want to love Signal, but it's just so meh.

* Message sync is like non-existent. Messages on my phone or laptop aren't kept in sync at all. Delete one one place, they don't delete in both.

* Let me edit messages, like every other message platform. I also want to be able to delete messages from the group. When I delete it deletes locally but not for the group, not even between my own devices I don't think. This sucks because deleting the message implies to anyone who has used a message system that the messages are deleted from everyone, but they aren't. Oof.

* When you set messages to expire, you can't make them expire. It only applies to future messages. I want to set this at the conversation level, not on a weird message-by-message basis with no way to change it globally after.

* I want to be able to sign in without using a cell phone number. Let me sign up with anything else, don't tie it to a cell phone line that can be hijacked.

* Let me add emoji responses to messages. Like every other message platform.

* Bonus, be peer-to-peer somehow. Dunno, like Blockchain magic it or something. Don't make me rely on some server somewhere. Just makes me feel uneasy that there's a middle man with all my messages.

How unrealistic is all this? (=

<comment><USER34> you are just using the wrong tool

</comment></comment><comment><USER35> I appreciate this, even fighting the gag order. Thanks @moxie0!

</comment><comment><USER36> Anyone have information about how/where they get their funding and/or income?

<comment><USER37> They are funded by the Signal Foundation: [https://signal.org/blog/signal- foundation/](https://signal.org/blog/signal-foundation/)

"...Today, we are launching the Signal Foundation, an emerging 501(c)(3) nonprofit created and made possible by Brian Acton, the co-founder of WhatsApp, to support, accelerate, and broaden Signal's mission of making private communication accessible and ubiquitous. In case you missed it, Brian left WhatsApp and Facebook last year, and has been thinking about how to best focus his future time and energy on building nonprofit technology for public good.

Starting with an initial $50,000,000 in funding, we can now increase the size of our team, our capacity, and our ambitions. This means reduced uncertainty on the path to sustainability, and the strengthening of our long-term goals and values. Perhaps most significantly, the addition of Brian brings an incredibly talented engineer and visionary with decades of experience building successful products to our team."

<comment><USER38> Yep, originally the Open Tech Fund was a big funder. They funded apps like our own Umbrella App and also lots of Guardian Project and Tor etc

</comment></comment></comment><comment><USER39> matrix and riot is awesome open source alternative. Awesome API too.

<comment> false-mirror They pair really well together too.

At the moment Signal really thrives at replacing texts (ephemeral one-to-one chats), while riot excels at team communication.

<comment><USER34> actually Riot is not worse at replacing texts..

</comment></comment></comment><comment><USER40> Somewhat tangential, I got into an argument about Signal last night. The other guy claimed that Signal was insecure because:

* It's "Custodial E2EE"

* Needs a phone number

(I'm not going to bother with his complaints about the crappiness of the desktop client or convenience of the design because those are non-sequiturs to the security of the app)

I asked him to define "Custodial E2EE". His words: "They have ownership of my keys, use phone number auth to access them and I cant expatriate them"

I managed to suppress my xkcd-386 instinct and go to bed, but my intuition is still that he's quite wrong about that. I may or may not resume my arguement with him; I got the impression that his disagrements were rooted in a Matrix fanboyism, but I'd like to be equipped to refute such arguments in the future.

I can somewhat sympathize with the phone number argument, and I think it comes from a concern about metadata leaks or opsec. I think that concern ultimately stems from a wrong threat model, but I'm not sure how to refute that. I have however, come across a number of tutorials which cover how to register a Signal account without using your phone numbers, so I feel confident I can refute the argument that signal must have _your_ phone number, even if I can't refute the underlying wrong thinking.

Regarding the "Custodial E2EE" argument, I'm not sure where to begin. Anyone have any suggestions?

<comment><USER41> On the first point, their understanding of Signal's key management doesn't seem to be correct. The private key is held only by the client on the mobile phone, which is one of the reasons that the desktop client is rather clumsy - it is dependent on the mobile app for initial key setup. It's also just very slow compared to the mobile app.

On the second point, I think they are quite correct. Yes, this depends on your use-case, but I consider the ability to have multiple and disposable identities to be somewhat critical to any messaging system calling itself suitable for security-sensitive use. Unfortunately, Signal is designed explicitly to make multiple or disposable identities impractical. Above and beyond their desire to be a drop-in replacement for SMS, a reason for this is almost certainly to reduce spam, as the need for a valid phone number makes it difficult to register accounts en masse.

In general, this method to mitigating abuse means that Signal cannot practically be used anonymously, which somewhat conflicts with the popularity of Signal as a mechanism for e.g. contacting journalists.

In the vein of criticizing Signal, I would also throw out that it largely abandons the problem of key distribution, effectively implementing a TOFU model that is lightly enforced at that, with "safety number changes" being pretty much normal. It is possible to verify Signal identities out-of-band but not common, and the Signal app does not really provide much tooling to make it easier.

I wouldn't say that Signal is bad, it does a great job of implementing effectively the identity semantics of SMS (including the shortcomings) but with the addition of E2E encryption and TOFU. I would stop short anyone who claims Signal to be a "perfect" or "complete" solution for encrypted messaging as there are common use cases that it has actively decided not to address.

I'm also, to be honest, somewhat baffled that your starting position seems to be that no criticism of Signal could possibly be valid, when attributing the other's viewpoint to fanboyism. Don't take that too seriously, it just stood out to me on reading. :)

<comment><USER40> >I'm also, to be honest, somewhat baffled that your starting position seems to be that no criticism of Signal could possibly be valid, when attributing the other's viewpoint to fanboyism. Don't take that too seriously, it just stood out to me on reading. :)

Touche. That wasn't my position, but re-reading what I posted, I agree that's it unnecessarily implies that position. Part of me wants to correct that, but I think I'll own my words and leave it there.

</comment></comment></comment><comment><USER42> Been a big fan of whisper systems since the redphone project. Great to see them maturing.

However, given the topic title it would have been nice to see some actual documentation on how signal actually works rather than just claims that it doesnt work like the others.

<comment><USER43> Does this help?

[https://signal.org/docs/](https://signal.org/docs/)

<comment><USER42> It seems to be about the clients rather than the server.

A level deeper than "how signal works" and more "how signal is made"

For example, I'd expect a "how signal works" article to explain why they even need when an account was registered and when it was last used.

"this phone number is using signal" is still a pretty large metadata leak.

Especially when state actors and probably a fair few non state actors can remotely compromise devices via the stuff in the baseband processor.

<comment><USER11> >"this phone number is using signal" is still a pretty large metadata leak.

>Especially when state actors and probably a fair few non state actors can remotely compromise devices via the stuff in the baseband processor.

A more accurate phrasing would be "this phone number was used to activate signal". If you only care about messaging other Signal users, you only need to have a baseband connection exactly once, when you receive the text message to confirm the number. After that you can toss the sim card and put in a different number, or run without a sim card at all and just use WiFi.

You don't even need to have the sim card in the same phone you will use with Signal when you receive the confirmation text.

<comment><USER42> wifi is still in the baseband processor.

There have been mutiple baseband RCE exploits published in the literature and demonstrated at blackhat - and they dont include any that were put there intentionally.

If you are not using a sim smartphones are pretty useless.

Im a long way from convinced that centralised servers have any role to play in reasonably secure e2ee, they certainly are not a requirement for other services such as firechat used to use before they got shutdown and bridgefy is making use of.

<comment><USER11> > wifi is still in the baseband processor.

> There have been mutiple baseband RCE exploits published in the literature > and demonstrated at blackhat - and they dont include any that were put there > intentionally.

You can't target a WiFi exploit against a phone number though, so that's irrelevant to the Signal situation.

>If you are not using a sim smartphones are pretty useless.

Maybe I spend too much time hanging around places with WiFi, but I almost never need to have a sim card. I don't even have data on my current plan.

</comment></comment></comment></comment></comment></comment><comment><USER44> Signal is open source; I'm wondering, has anyone here ever built the service and one or more clients and run it on-prem, or even as a white-labelled competing service?

<comment><USER18> Yes there are forks/clones you can search that on signal community website.

</comment></comment><comment><USER45> The anti-Signal rhetoric has already started. News articles about Antifa specifically mention that they communicate via Signal.

If Antifa is designated as a terrorist organization, then we'll see all the counter-terrorism tools brought to bear against them. If the state can't break Signal encryption, then you'll see renewed energy for anti-encryption / anti- privacy policies.

<comment><USER46> Why would antifa result in anti-signal rhetoric?

Genuine question because antifa is a mixed bag - there isn't really any consensus on whether what they do is good or bad. Seems to be all over the damn place.

<comment><USER47> There is no consensus on wether being against fascism is good or bad? Being against fascism is not a group or organisation. It's like calling bird watching an organisation. Yes, there are bird watching organisations, as there are antifa organisations, but neither bird watching nor antifa is an organisation.

<comment><USER48> This is like asking if there's no consensus on whether "all lives matter". Or no consensus on being "pro-life". Phrases often have context that mean more than their literal dictionary definition.

Edit: The comment I replied to originally asked "There is no consensus on wether being against fascism is good or bad?"

<comment><USER49> Well, there isn't. "All lives matter" and "pro-life" represent specific political views, but they don't represent any specific groups or organizations. Just like antifa.

<comment><USER50> You're being obtuse for no reason. This is like saying ISIS isn't an a specific group because it is comprised of transregional autonomous cells instead of any specific group. Sure, maybe in the most literal application of terms, but it's obvious what's being discussed from context clues. Decentralized movements are the status quo of activism these days, that doesn't mean you can't reference the movement as a collection when discussing how to combat it or or if it should be combatted.

<comment><USER46> Thanks for this, but it's not worth it to get into a spat on HN over this to be honest.

It's clear from the downvote brigading that this isn't a thread for discussion.

</comment></comment></comment></comment></comment></comment></comment><comment><USER51> Signal is a walled garden. They refuse to allow federation and even prohibit any modified client to use their servers.

It's the least open "open source" model, and once (if) they gain significant market share they can easily close down the app and lock-in the users.

Please use and spread federated alternatives. Donate and contribute.

<comment><USER52> What alternative would you recommend?

<comment><USER53> I'm surprised Briar isn't coming up more in these discussions. Maybe it's locked down too tight for everyday use, but for protesters and individuals at risk it seems ideal.

I admit I could be missing something though, as I've not used it heavily.

<comment><USER11> Briar doesn't have an iOS version, making it useless if you want to communicate with more than 50% of the population in the US.

</comment></comment></comment></comment><comment><USER54> Really nice design, in the future I see a market for "privacy tools that also happens to ..." kind of software, for example a Privacy tool that also happens to browse websites, or a Privacy tool that also happens to help you to send messages (like Signal); in summary, privacy aware services.

</comment><comment><USER55> iCloud contacts is not e2e encrypted. Apple, as well as FBI/DHS and the US military intelligence apparatus can access your entire contacts list and infer your whole social graph.

This is why a messenger needs an e2e contacts sync, whether Moxie wants to be responsible for it or not.

</comment><comment><USER14> Anyone have a link to Signal's 2019 IRS Form 990?

Most recent I was able to find was this 2018 version: [https://news.ycombinator.com/item?id=23431076](https://news.ycombinator.com/item?id=23431076)

<comment><USER37> The 2019 filing deadline (including Form 990) was extended to July 15, 2020 so it may not be published yet.

<comment><USER14> Thanks, makes sense, though guess I would expect a non-profit to communicate this; don't believe Signal even links to the 990 I linked to on their own website; possible they don't want the public to (easily) know salaries, assets, etc - but unclear.

<comment><USER37> True, but remember that Signal (the app developer) is an LLC. The 990s may eventually be posted on the Signal Foundation website if they ever finish it: [https://signalfoundation.org/](https://signalfoundation.org/)

<comment><USER14> Thanks, good point, was aware of that, but others might not be; never seen a good explanation for their legal structure, both as it relates to the present & future.

I have checked both URLs for 990s, only way I found it was via a link in the footer of Signal's Wikipedia page.

<comment><USER37> ProPublica's database is my go-to for 990s. Only the 2018 form so far: [https://projects.propublica.org/nonprofits/organizations/824...](https://projects.propublica.org/nonprofits/organizations/824506840)

</comment></comment></comment></comment></comment></comment><comment><USER56> They need to allow us to not reveal phone numbers in a group, especially now.

</comment><comment><USER57> "Secure" messengers which use google play services sucks.

</comment><comment><USER58> Or use something that you (or someone you trust) can self-host, so then even the company/CEO/TLA-with-subpoenas are out of the picture.

Not only do I get to get Moxie out of the picture, I also get my phone and the phone companies out of it.

</comment><comment><USER59> All encryption is broken wrt a quantum cracker. How will, say, the future look at these Signal uses?

<comment><USER60> You are wrong that all encryption is broken with a quantum cracker. But as far as I know Signal is not quantum resistant. It's certainly something to keep in mind - that whatever you say might resurface later.</comment></comment>


Tell HN: Here's how my team got to the YC interview stage - <AUTHOR> http://trevorburnham.com/2010/03/15/how-theoryville-reached-the-yc-interview-stage/

<comment><USER2> That's a great story. You guys are obviously smart and have a good idea. Your weak points would be here:

\- Have you fought with your co-founders yet to find out if you could survive such a fight? If all you've been in civil and polite, then you don't really know each other yet

\- You have 'options'. Will you have the drive to really push through if things do not go initially as expected?

The impression I am concerned about is that you seem a bit soft and nice, if I may use those word. If I were you, I'd focus on making sure in conveying that you have the capacity to be tough also.

<comment><AUTHOR> We've fought pretty hard over design details—we're all very passionate about design and perfectionistic when it comes to the user experience, and sometimes our aesthetics conflict. I don't anticipate any more serious fights, but I've read enough startup stories to know that such things are always possible. I'm not sure that what you're suggesting is right, though. Are you saying that a startup that's been torn asunder by internal conflict and reunited by the founders' convictions is stronger than one where work has proceeded smoothly and uneventfully?

And yes, I do have that drive to push through. It's not every day that you get the chance to change the world. I'm not throwing that away, no matter how difficult things might seem.

As to "soft and nice"—well, thanks! I get what you're saying, but my impression is that knowledge >> toughness in the startup world. Being tough is mainly about understanding that you have other options, that you don't have to accept everything that's put in front of your nose.

<comment><USER2> When multiple intelligent people work together, there will be fights over totally uneccessary things. With time, either the fights will get worse, or there will be some type of resolution where everyone realizes that the fights are hurting and compromises are reached to ensure that there are no more fights.

Some people get to that compromise point, but some can't. If the fights are resolved in a bad manner and resentment continues to brood, when money arrives and people get greedy, those fights will come back, and this time they will be worse.

So you have to get the fights over with at the start and everyone has to accept their position and their status. Then you can work in a focused fashion forward.

Changing the world is great, but I can likely do that by planting a bunch of trees in the amazon. Very few business get to change the world - most just get to make money. Would just making a lot of money also be enough for you, even if you don't get to change the world?

<comment><AUTHOR> Yes: Making a lot of money => Ability to change the world. The converse is not true. :)

</comment></comment></comment></comment><comment><AUTHOR> Thought I'd share the story, especially for those who are outsiders to the startup world, like myself. Please feel free to contact me if you have any questions or, better yet, interview advice.

</comment><comment><USER3> Their idea reminded of a similar concept I heard once: open source scientific papers.

It works like this: you put up the .tex source, the data files, the R, Octave, etc. scripts, and if people download and run the scripts, they get the exact paper as a result, including all the graphs. This way one can check that the graphs really show what is claimed in the paper and that there has been no bug or "polishing" of the results.

<comment><AUTHOR> That would be absolutely _awesome_. Of course, in principle, there's nothing preventing researchers from doing that now. I think that being able to actually manipulate things on the same website that the data exists on will be key to bringing "open source papers" into the academic mainstream.

<comment><USER3> Yeah, I like the outline of your product idea. Looking forward to trying it out.

</comment></comment></comment><comment><USER4> Congratulations Trevor. Generous reflection you've shared. Much appreciated.

</comment><comment><USER5> Interesting idea. I wonder though, how big is the potential market, money- wise?

<comment><AUTHOR> That's a good question, and figures are hard to find. Statistical analysis is a huge market; SPSS, for instance, was recently bought by IBM for $1.2 billion, and SAS made $2.3 billion in 2009 alone. But while those companies started out as humble makers of academic software, and continue to make significant revenues that way, they both found the business analytics market to be far more lucrative, so those figures largely reflect their sales of large enterprise solutions. Companies that primarily sell to academics (e.g. Stata, Minitab) are private and don't publish sales figures.

We think our most promising immediate markets are social scientists (of which there are about 25,000 in the United States) and stats/science classrooms. While the original concept was mainly aimed at researchers, we've been shifting more toward classrooms recently, based on the feedback we've been getting. The two products we envision—the research product and the educational one—share the same core, as far as the interface and computational backend. So, we believe that we can pursue both markets, much as Lingt (YC S09) has both an individual product and a classroom product.

I should emphasize that my blog post is in no way intended as a pitch for Theoryville reflecting our most up-to-date thinking about our product or our business model.</comment></comment>


Dye kills malaria parasites at speed not seen before - <AUTHOR> https://www.sciencedaily.com/releases/2018/02/180205195624.htm <comment><USER2> There is going to be a lot of blue-bloods now. Nice discovery, lets see if this is widely safe to humans.

<comment><USER3> Blue metylene is already widely used in medicine, nowadays almost only to cure Methemoglobinemia:

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

Though it has some possible side effects:

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

it is "safe", or at least "widely tested".

<comment><USER2> Thanks! I had no idea. I was thinking that its intended use was only limited to add color to visualizations, like a contrast.</comment></comment></comment>


Why nerds will rule the world. - <AUTHOR> http://mustafabei.tumblr.com/post/62056753054/why-nerds-will-rule-the-world

<comment><USER2> Based on that, I guess Alexander The Great was a nerd.

<comment><AUTHOR> Indeed he was for his time.</comment></comment>


Writing Rules to Disregard - <AUTHOR> https://www.theparisreview.org/blog/2019/02/01/three-writing-rules-to-disregard/ <comment><USER2> The (funny) classic reference being:

[https://news.ycombinator.com/item?id=16422686](https://news.ycombinator.com/item?id=16422686)

[https://news.ycombinator.com/item?id=16429640](https://news.ycombinator.com/item?id=16429640)

</comment><comment><USER3> I've rarely seen those three rules followed by anyone in normal writing.

Usually when I see someone strictly adhering to those rules (particularly not ending a sentence with a preposition), it sets of a warning flag that the writer is trying too hard to follow imaginary rules, and maybe isn't someone whose opinion I want to take much stock in.

</comment><comment><USER4> Wonder what the equivalent "Coding Rules to Disregard" might be.

<comment><USER5> If you know of any coding rule that is universally true, I'd like to hear.

Maybe... Don't use goto to jump to the middle of a different block of code? I don't know any exception to this one, but it's also prohibited on all modern languages, so I don't think it's a "coding rule" anymore.

<comment><USER6> Oftentimes if you have some hairy code, the best option is to use a goto, make a commit or leave a note, and then clean it up later, in a separate commit. It's more bisectable and leaves a more readable diff. I'm pretty sure I've had occasion to jump into the middle of a loop as the point of entry. Duff's device is a case of this.

</comment></comment></comment><comment><USER7> My favourite wikipedia rule: _Ignore all rules_.

"If a rule prevents you from improving or maintaining Wikipedia, ignore it."

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

Some explanation of what it's meant to mean, with a selection of quotes about breaking rules:

[https://en.wikipedia.org/wiki/Wikipedia:What_%22Ignore_all_r...](https://en.wikipedia.org/wiki/Wikipedia:What_%22Ignore_all_rules%22_means)

I really like that page - so well-written. "Use common sense. ...There is no common sense." In fact, the wikipedia pages about rules are much better written and more enjoyable to read than the average article is - which seems odd, but I guess is how it should be. There are a lot of very funny pages about the rules.[0] Many essays, on every aspect of wikipedia, here:

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

(A lot of the titles and short explanations on that page are fascinating/funny, a great intro to wikipedia culture...as it should be.)

[0] e.g. [https://en.wikipedia.org/wiki/Wikipedia:Essay_directory#Humo...](https://en.wikipedia.org/wiki/Wikipedia:Essay_directory#Humorous_material)

</comment><comment><USER8> This is an example of how the HN rule about stripping out the "Three" in the title has resulted in ambiguity: I thought the term "writing rules" was present-participle verb + object, but it turned out to be gerund-as-adjective + noun. (I might have the grammatical labels wrong.)

<comment><USER7> True - you were hoping for advice in the construction of rules that everyone would ignore. (A bit masochistic.)</comment></comment>


The Hidden Racism of Children's Literature - <AUTHOR> https://www.theatlantic.com/education/archive/2017/08/reading-racism-in-dr-seuss/536625/?utm_source=atlfb&single_page=true <comment><USER2> >The emotional experience of dealing with racism is tough, especially if you're the target. I think what's worse, though, is not dealing with it and not being given any tools for dealing with it—to experience the injury and then not know how to deal with it.

This. I am of mixed South/Southeast Asian descent, but I frequently get confused for being Hispanic. Growing up in SoCal, one would think this is not a problem. My best friend was a Persian-American Jew, and my first crush was a Japanese-American boy. Ironically, the times when I felt most out of place were when I was around either side of my parents' relatives who were not mixed, and more culturally homogeneous.

And yet, I will never forget the summer I spent on Catalina Island, during the early 1990s and the heyday of Gov. Pete Wilson and the anti-illegal immigrant rhetoric of Prop. 187. I wandered into a gift shop, and was just walking around looking at items, and the white store owner's first words to me were, "If you're just browsing, please be aware that we have cameras all around."

I remember not knowing how to process what she said. It was only later that I realized that she had misjudged me. It was deeply hurtful, but I swept it under the rug, not knowing how to deal with it. 10 years later, I would experience the same type of hurt in my high school geography class, hearing my classmates mimic South Asian accents and ridiculing the names of places like Lahore. And I still did not know how to deal with it. Sometimes, even growing up in an ethnically diverse environment is not enough to steel one's self against the insidious nature of racism. Thanks for posting this.

</comment><comment><USER3> These are the sort of absurd conclusions people draw when they allow their worldview to be dominated by a single theme. In fact I'd argue all extremism derives from a conception and understanding of the world which bends around a single theme, so that even things which in reality have nothing to do with that theme are assumed to have a connection to it.

Look at the ugly era of McCarthyism in 1950's America. McCarthy saw Communists everywhere because he wanted to see Communists everywhere. Were there Soviet style Communists in America? Certainly so. But not to the extent that he believed.

Remember: history doesn't repeat itself, but it does rhyme.

<comment><AUTHOR> These are not absurd conclusions. You're just a massive racist.</comment></comment>


Go memory ballast: How I learnt to stop worrying and love the heap - <AUTHOR> https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2/ <comment><USER2> I think the takeaway here is not that some corners of Go are not performant (and should be swapped for C++/D etc.), but that there are tools in the Go ecosystem that help you figure out what the issue is.

Until Twitch hit the bottleneck with their service, they were reaping multi- year benefits of faster development using memory-safe language (huge gain for security).

Their short- (or mid-) term solution seems decent and more importantly Go core team is working on addressing this particular issue (which given the Go 1.x backward compatibility promise makes it really easy to reap all the benefits with each Go release).

</comment><comment><USER3> "Only if we attempt to read or write to the slice, will the page fault occur that causes the physical RAM backing the virtual addresses to be allocated."

Tiny nitpick. On Linux at least you can read from the slice. New memory allocations are given a copy on write zero page (full of zeroes). So you can easily read that 10GB worth of zeroes out and still memory consumption wouldn't increase.

Only when you write a pagefault is issued and you'll get real backing for it.

</comment><comment><USER4> I'm really surprised there are no flags to configure GC behaviour in Go. This is fairly standard performance tuning stuff on the JVM which provides a number of options to control GC behaviour, minimum and maximum heap size being some of the basic ones.

<comment><USER5> Isn't it great? You don't need a degree to operate the thing. When there are esoteric conditions like the one described in the post, the team is usually super responsive to fix them if they're bugs, or give you reasonable and lightweight workarounds when they're not.

<comment><USER6> You always have to tune GC if you're pushing the limits of the machine. If you can't do it by turning knobs, you have to do it by rewriting code.

<comment><USER5> It's Go's position that the language (and/or runtime) should make this unnecessary for the vast majority of use cases, I'm not sure what they're targeting exactly but I'm sure it's 99% or more. The resulting _lack of knobs_ is actually a feature, and one I'm very glad to have.

I'm also happy to make my code less allocation-happy or more GC-friendly in the extremely rare circumstances when it matters. Like this article!

But I think we probably just work in different environments.

<comment><USER6> I would much rather make the concise and clear implementation perform better, than take the readability hit and risk of mistakes from rewriting it (probably more than once).

<comment><USER5> This is sensical for application code, but I think a bad compromise for a language runtime.

</comment></comment></comment></comment></comment></comment><comment><USER7> This is a pretty hilarious hack. I'm surprised there's no way to do this within Go runtime.

</comment><comment> brian-armstrong So, isn't this a strong argument against Go? At the point that you need to start devising clever workarounds to stop bad behavior from your runtime, it's time to find a new language.

<comment><USER8> If you know of a language that has absolutely no unexpected behavior in its runtime under any workload, please let us know what it is!

<comment><USER9> Baremetal assembly

<comment><USER10> Counterexample: [https://en.wikipedia.org/wiki/Pentium_FDIV_bug](https://en.wikipedia.org/wiki/Pentium_FDIV_bug)

<comment><USER11> Bugs are unintentional and can (and are) fixed.

</comment></comment></comment></comment></comment><comment><USER12> FWIW, there's a related open issue about adding a minimum heap size for situations like this, where you don't care about wasting a bit more RAM but do care about the GC work: [https://github.com/golang/go/issues/23044](https://github.com/golang/go/issues/23044)

It references a patch to add a SetMaxHeap call, which could help in these kinds of situations too.

<comment><USER13> Yes, it is a bit strange that you cannot tell the GC a few more things about your requirement. The default setup usually works quite fine for me, but I would like to be able to tell the GC to have a certain minimum memory size. If I absolutely know that an application is going to need a certain memory size, the GC doesn't need to to any work before that is reached. Furthermore, I would like to set the GC percent quite low, if I don't have many allocations beyond that size - but that is less optimal, if the heap has to grow to that size.

<comment><USER12> And there are other situations where if you _overshoot_ some memory limit, you get killed or the OOM killer kills some random thing (ugh) or you just have performance degradation (swapping, crowd out caches, whatever). Often better to suffer n% more GC CPU usage than to deal with that. So min/max heap are both important in different scenarios.

A blog post from someone working on .NET suggested "the user shouldn't have to know about GC internals" as the heuristic for when you have too many knobs, which I like. The user knows some things that the runtime does not about their needs in terms of RAM vs. CPU use, and it seems reasonable to have ways to communicate that.

(One other thing the user knows is their relative priorities for having a consistent level of CPU used by the GC vs. minimizing the absolute amount of CPU used. I think Go is hard-coded to target about 25% CPU use during a collection right now. Not sure we're ever getting that knob, though.)

</comment></comment></comment><comment><USER14> I'm confused. They say "above code" and whatnot, but I don't see any code is this article. Is this the same for everyone?

How did they allocate that 10GB byte array?

<comment><USER15>
        func main() {

            // Create a large heap allocation of 10 GiB
            ballast := make([]byte, 10<<30)

            // Application execution continues

        }

<comment><USER16> 10<<30 is a lot. Perhaps you meant 2<<30?

<comment><USER17> Are you confusing shifting with exponents? 10<<30 is exactly five times bigger than 2<<30.

<comment><USER16> Yes, I did.

</comment></comment></comment></comment></comment><comment><USER18> Has there been any discussion or proposals to Go to simply provide a free() function? This could recursively GC up all objects starting with the given root pointer. The idea is to avoid hacking around the GC system and instead give some hints to the runtime to better optimize GC - without penalizing folks that don't care about this level of performance.

<comment><USER19> If you free something that has a reference to it still what would be the effect? Can GC still free and then fault out on the reference, or does the free throw an error (and you do a check while GCing?). If the later, can you do a free starting anywhere or do you need to have a good global state?

<comment><USER20> What's wrong with the first option? Runtime invalidates the pointer, and then just segfault on use and be done with it?

It seems to me that if you're going to play with memory directly, it's reasonable for the generally-memory-safe runtime to throw out its guarantees on memory-safety

<comment><USER21> I think it's reasonable to want that in principle, but in practice it gets really messy. What if I use a library which returns me a manually-mis-managed pointer (either due to a library bug or me not setting up manual memory management correctly when initializing the library) which segfaults on read or write? That's kind of spooky behavior in a language that prides itself on simplicity.

There are ways that could be done (for example by making the type system aware of whether or not something is hand-managed and potentially unsafe) but not without adding considerable complexity to the language and, presumably, the implementation.

<comment><USER22> Doesn't your scenario essentially amount to asking what happens if you use a poorly written library that does bad things and it breaks your program in unexpected ways? That can happen in every language I'm aware of, regardless of safety guarantees. For Go, consider the unsafe.Pointer type.

This commonly recurring idea that we need to somehow banish all insecurity and risk is flawed in my opinion. When safe is the easiest and most convenient way of doing something, it will generally be used. What we need are sane defaults, combined with explicit and unambiguous interfaces for when we do choose to take manual control. The real issues start to arise when a language exhibits unexpected behavior, when automatic memory management is opt-in instead of opt-out, and similar.

</comment></comment></comment></comment></comment><comment><USER23> Sounds like go is missing the Java equivalent of -Xms which sets the minimum heap size before GC is necessary

<comment><USER24> > Sounds like go is missing the Java equivalent of -Xms which sets the minimum > heap size before GC is necessary

-Xms sets the initial heap size, but GC happens before the heap is exhausted, in most GC configurations. There is a smaller eden in the heap, and GC is needed to evacuate objects out of the eden into the main heap.

</comment></comment><comment><USER25> > It turns out that for modern operating systems, sweeping (freeing memory) is > a very fast operation, so the GC time for Go's mark-and-sweep GC is largely > dominated by the mark component and not sweeping time.

That paragraph got me interested. A lot of stuff in this article is based on this statement. Where can I read more about this? By intuition I would have guessed that the process of marking is the smaller portion of work ...

<comment><USER26> The author didn't mention what percentage of objects is getting sweeped at every GC stage, but it might be a small percentage of the total heap if the application is complex.

Sweeping, in typical implementations, also requires locking/unlocking mutexes and sorting/combining freed memory chunks to combat fragmentation, and that can be slow.

My hunch is that sweeping is fast because there isn't much garbage (meaning distinct allocations, not megabytes) per sweep cycle to start with.

Edit: the talk referenced in the article ([https://blog.golang.org/ismmkeynote](https://blog.golang.org/ismmkeynote)) provides a hint. Go has lightweight threads, and if you have many of them you have to walk all stacks, closures, and all registers of all threads in order to determine which objects are live. If they are processing millions of requests per second, they might have a goroutine for every request, and that might explain why sweeping is (relatively) expensive in his benchmarks.

</comment></comment><comment><USER27> Great one, I must say I have laughed quite hard at solution, it is logical and simple. Good work.

What does annoy me is that GC languages doesnt provide option of allocations that are not handled by GC but still uses language primitives and/or privide option to deallocate them manually. Dev. could decide should they leave alocation to GC or handle them on their own. I would certanly love it, in most programs that I write I know exactly what the lifetime of objects is and I am leaving them to the GC just due to missing any other option.

<comment><USER28> I think you might want to try modern C++ (C++17 and the soon to be released C++20), if memory allocation and lifetime is your major concern.

The language has improved itself so much that it's now a better syntax and verbosity

<comment><USER29> I think he wants a GCed language that also allows manual memory alloc/dealloc. Doesn't D offer both?

<comment><USER28> yeah but what's the point of a GC when you want to do manually the operations?

<comment><USER17> So that you can put the hottest 5% under [semi-]manual control and let the GC do the rest.

<comment><USER27> Exactly this. :) I am quite familiar with c++ (no expirience i D) but for fast little projects go is great, I wouldnt mind having more control over GC.

</comment></comment></comment></comment></comment></comment><comment><USER30> > the Visage application which runs on its own VM with 64GiB of physical > memory, was GC'ing very frequently while only using ~400MiB of physical > memory

Why would you provision a 64GB machine if you only need less than 1% of that?

Especially given earlier:

> One approach to handle this is to keep your fleet permanently over-scaled, > but this is wasteful and expensive. To reduce this ever-increasing cost, > [..]

This already was over-scaled.

<comment><USER31> There aren't any cloud instances of anything with 32 cores but only 4 GB of RAM. I've got some similarly lopsided systems, because I don't need the RAM.

Even if you physically deploy them, that would be a silly loadout. Take the bit of insurance out and stick some RAM in it. The cloud providers don't offer these instances because if you run the numbers they don't really make sense.

</comment></comment><comment><USER32> So the solution the article suggesting is to "Use a big buffer (and later slice it for each client(????)) instead of create buffer for each client"?

If above is true, then I have one question: What if some where down the line, somebody calls append on that buffer?

        bigBuffer := make([]byte, 1024)
        clientABuffer := bigBuffer[:512]
        clientBBuffer := bigBuffer[512:]

        clientABuffer = append(clientABuffer, []byte("Hello Client 2")...)

        // clientBBuffer will now be [72 101 108 108 111 32 67 108 105 101 110 116 32 50 0 0 .... even we didn't directly modify it.

Could be a downside.

[https://play.golang.org/p/JiVKypGHQdR](https://play.golang.org/p/JiVKypGHQdR)

<comment><USER31> "So the solution the article suggesting is to "Use a big buffer (and later slice it for each client(????)) instead of create buffer for each client"?"

No, it's actually just "create a big buffer and don't drop the reference". It's never used for anything except changing some numbers the GC uses to do its logic. Since it doesn't actually end up in physical RAM, it's doesn't consume significant resources either. It's just a funny-looking way at the Go- languange-level to twiddle some numbers to make the GC act differently.

Allocating a big slice and handing out chunks of it does have its uses, basically, arena allocation flavored by being used in a GC'd language. But that's not what this is.

<comment><USER32> Oh I got it finally. I was wondering why the article does not mention how to actually _use (read/write)_ that buffer after it's been allocated other than just keeping it alive (and do nothing else).

Thank you for sum thing up.

</comment></comment></comment><comment><USER33> A) This is from April. It's being resubmitted because the URL changed.

B) In a non-memory managed language, wouldn't you just run into the same problem except it's called "heap fragmentation" instead and malloc has to do an unreasonable amount of work to find free blocks to use?

<comment><USER16> B. no, it's quite subtle but this is just tweaking a housekeeping parameter inside the garbage collector.

</comment></comment><comment><USER34> If you're using less than 1% of the physical RAM in the server, and 30% of your CPU on GC, you might be optimizing for the wrong thing.

<comment><USER35> They effectively did exactly what you're implying by letting the heap grow more in exchange for lower GC CPU usage.

</comment></comment><comment><USER36> Or you could use Rust and avoid having to use "tricks" like this at all.

Go is chock full of "what were they thinking?!" decisions.

<comment><USER37> Can you name a few examples?

<comment><USER38> Garbage collection, lack of proper generics except for standard library collections, interface{} and the weird way of distinguishing visibility via capitalization, and comments that affect code generation. Oh, and blowing the cobwebs off some archaic plan 9 assembler instead of using LLVM.

That's not to say it's all bad, far from it, but these were my wtf moments exploring the language.

<comment><USER39> > Garbage collection

This is hardly a weird choice. Garbage collection gives you the highest productivity while being memory safe out of the three options (manual, GC, static).

> lack of proper generics

They are working on parametric polymorphism, since a while now. It is hard to get right in a language which has readability and simplicity as a main focus.

> interface{}

I certainly agree on this one. It is a weird feature and often a 'smell' when found in Go code.

> the weird way of distinguishing visibility via capitalization

It is weird syntax choice in the sense of being unique/uncommon but fits very well into the readability focus of Go.

> comments that affect code generation

I agree that they should have introduced syntax for this, assuming you mean compiler flags (or w/e they're called).

> archaic plan 9 assembler instead of using LLVM

One of the goals of the language is to compile really fast, which they certainly succeed at.

<comment><USER31> "> interface{}

I certainly agree on this one. It is a weird feature and often a 'smell' when found in Go code."

The feature itself is not a problem. Every major static language has the equivalent. It's often called something that involves the word "dynamic".

Having programmed in Go for many years now, I don't find myself using it very often in my own code. I've come to think of this as something said by either people who have never used Go at all, or people who used Go briefly but insisted on programming Javascript-in-Go or something. The latter is definitely a Bad Time... but it's always bad to program X-in-Y. If your code is shot through with interface{}, you either chose Go for something _way_ outside of its domain, or you are not using it correctly.

"> comments that affect code generation

I agree that they should have introduced syntax for this, assuming you mean compiler flags (or w/e they're called)."

This is another criticism that I think mostly comes from people with a checklist criticism set of Go, because in practice, this is of negligible concern. It doesn't come up often, it isn't proliferating (i.e., it's not like with every point release we get another two or three new kinds of comments), it's literally never been an issue of any kind for me in the last six years. It's a complete non-issue. I am _far_ more annoyed by, say, the fact godoc doesn't give me basic markdown than comments affecting compilation has ever annoyed me, and that's just an occasional minor annoyance.

<comment><USER13> I think interface{} is a great feature, when you want to write code that safely handles any type. fmt.Printf is a great example for this. As type information is attached with the value, type safety is fully maintained when casting the contained value back to its right type.

Where it is appropriate, it is a very cool thing that you can have fully dynamically typed variables with all safeties in place. Of course, it shouldn't be used in place of better abstractions, like specific interfaces or properly factored code.</comment></comment></comment></comment></comment></comment>