I think I just read about 10 versions of this comment on this page, and definitely not a single response to the criticism that could be described as incendiary. I don't think I even saw a single comment just now that fundamentally pushed back on the premise of this article, let alone in an incendiary way. It's early yet, and maybe this thread will look very different in a few hours though?
The author maybe somewhat hit on the reason for this in the article, where they mentioned that they're already seeing some of the rabid, toxic, Rust proponents already moving onto the next "hot" thing and doing their thing there. So maybe after a few years of Rust we've arrived at the turning point now where enough of those types of people have finally moved on and the Rust community has significantly changed.
I don't think that's the case. N=1, but I'm usually a quite staunch, and occasionally incendiary, proponent of Rust, because the arguments against it / criticisms of it I usually see seem fundamentally misguided or even disingenuous to me — whereas in this thread, I've been only agreeing, because the criticisms are fair (I agree Rust isn't built for, and is quite bad at, prototyping, fast iteration, flexible code, etc), if I think a bit overblown (I think many of the patterns the author complains about being forced to use like command lists and generational arenas are very good). That could be the difference you're seeing, IMO.
Perhaps because the article is about how Rust isn't the magic bullet to everything, and a few people have commented agreeing with the article, others feel more willing to comment their own Rust isn't perfect opinion as well.
If you go into the comment section of a pro-Rust article, where the first few top-level comments are also pro-Rust, the responses to people expressing a negative attitude about Rust tend to (in my experience) be different.
This phenomenon certainly isn't exclusive to Rust (or HN). It happens all the time, especially when a prolific commenter is among the first few comments. It can set the tone for the entire comment section.
I assure you it happens, but the people targetted this way usually quickly learn what is ok and what isn't to say, especially on rust's reddit. If you wanna see examples, look at my reddit profile (same username). I dared to say bevy was full of hype and false promises and tat the money they get would be better spent elsewhere. And look at the hate i received.
One way i've seen to reduce this is prefixing any posts with "I am not criticizing any engine in particular" even if it's blatantly obvious because the criticism only applies to one.
I guess I interpreted the comment as meaning that the incendiary responses were going to be seen here. I would expect incendiary responses to anything I post on reddit...
Based on what I've seen, various forms of censorship and suppression are often employed in such cases, rather than outright "flaming" or other discussion-based approaches.
It really depends on where and how the discussion is taking place, and what censorship methods the website/platform/medium involved offers.
Sometimes users are just outright banned or shadow-banned, if those happen to be options.
Sometimes forum threads, bug reports, or comments are deleted.
Sometimes the discussion remains accessible, but is stifled in some way. This includes closing/locking forum threads or bug reports, or otherwise severely limiting participation in such discussions to a very small and isolated group of people. If down-voting/reporting systems are present, sometimes they're used to limit the visibility or prominence of such discussion.
I haven't rigorously tracked all of the instances I've seen of this happening over the years, but I've tried to quickly find some more prominent examples for you.
This bug report, for example, has various "This comment has been minimized.", "rust-lang deleted a comment from ...", "rust-lang locked and limited conversation to collaborators" interference:
When Rust is discussed here, it's common enough for reasonable and relevant Rust-related comments to be voted down, sometimes severely. These threads have some examples I quickly found via a search of high-activity Rust submissions:
Here's an example of a recent submission on this site for an article very reasonably and thoroughly questioning Rust. It got some attention, and now it's currently marked as "[flagged]":
Keep in mind that strict "moderating" (ie, censoring) has been an integral part of the Rust community's identity for many years now via its Code of Conduct and Moderation Team -
I'd go read their mailing list and Reddit forms; especially when people run into issues doing stuff that's very simple in other languages. Never seen a more toxic programming community.
Hopefully they calm down, or really get drown out, once there are a real number of jobs for people using Rust. Right now the evangelists outnumber the rank and file who are just using a language to get work done.
I'm active on both and have not seen this behavior.
In fact, my experience has been the polar opposite, the rust community has been very friendly and accepting of critique.
So again, I'm going to ask for an example of rust language fanatics frothing at a criticism. If it's such a community problem this should be easy to find correct?
Here's the OPs article on /r/rust and it's both got a fair number of up votes and the top comments are all really positive towards this article. That's what I've seen at typical in the rust community.
It may not be flaming, but the author brings up a particular quote repeatedly. "You just don't get it/have enough experience with it yet."
I've seen this everywhere. This is an obnoxious, lazy thing to say to someone. It's a go to for many "enlightened" languages that have small ecosystems and something to prove. The only response is to ignore it entirely or, like the author did, dedicate years of your life just to see if there's something to it. This is not okay. Life is short, and we lean on other developers experience to keep us from wasting our time.
If someone posts a topic wondering if X language is bad for something, it's an earnest question. Not a time to flex your dedication to the cause.
If it helps, they can't possibly be as toxic as Lisp programmers used to be, where more or less any online conversation would start with someone new asking a question and Erik Naggum replying that they were a moron who should die.
Probably because there's so many more of them. Maybe because being called not a real UNIX programmer feels different from being called a Blub programmer.
Maybe I should ask: why should someone interested about Lisp today have to hear stories about some Erik Naggum who posted to a Usenet newsgroup, and died 15 years ago?
Let's assume that the newsgroup is important. Legendary Lisp hacker Alan Bawden posted there just last week or so. Nobody ever mentions him.
Every other one I've met in my life was nearly as unpleasant. Fewer death threats but they clearly all thought they had 200 more IQ points than you because they could write a macro. Thus the term "Lisp weenie".
In this case I think people should learn from history and that specific examples are the best way to do that. It's, like, effective pedagogy or whatever.
You were flagged for a pointless quip about "woke"ness. Other people repeated more civil and reasonably argued forms of your same point about the language and its community and received no such downvotes.
If you blame the wrong reason for downvotes, expect to be corrected. Your complaint here is invalid.
Try criticizing Rust next time, if you want to demonstrate that criticizing Rust gets downvotes. You were throwing out insults in your very first comment.
This is a textbook example of poisoning the well. [0] We see it used in every discussion about pros and cons of a language on HN.
It's some variation of "People who like this language can't handle criticism/are part of a cult/etc." The idea being that this will preclude anyone from responding to a criticism, because that would confirm the comment.
Like many things in Rust vs C/C++ comparisons, it’s about defaults: Rust has dedicated syntax and everyone uses it, in C and C++ it’s more manual and not everyone does.
But C/C++ pointers don’t. You can add bounds checking to all C/C++ pointers and there are many projects that do that (CCured, SoftBound, CHERI, Fil-C, CheckedC, -fbounds-checked) but they all come at cost (new hardware, language changes, or reduced perf).
The second biggest is the missing need: Most people don't have any advantage of using crypto. They go to work, get a salary, buy/sell things and thats it.
If you don't need to buy something illegal or really believe that there is still a soviety left to take some crypto in worst case scenario, fiat is great.
I have this pet theory that the idea of decentralized currency is a bit ahead of its time, and the best consumer use case is for frequent travelers since you could more easily sidestep foreign exchange issues, and hassles.
There's a bunch of backend and b2b use cases to be explored but those also take time.
> frequent travelers since you could more easily sidestep foreign exchange issues
I don't travel internationally very frequently, but whenever I do my credit card handles currency exchange for me automatically. Perhaps I'm not getting the best exchange rate, but the difference is minimal enough that looking into alternatives isn't worth the hassle.
A paragraph from the previous essay by the OP comes to mind:
> Less sardonically, there is a lesson here: systems which intermediate between cultures are useful. Intermediating between cultures is a thing the world urgently needs and is extremely prepared to pay for.
I don't think decentralized currency will actually solve the issues travelers have with this, at least without reproducing much of the infrastructure already in place for traditional currencies.
In a quasicapitalist utopia, crypto would be a very convenient way to enable the government to set a stock value for a universal cryptocredit and make that credit its default method of value transfer.
They could do something like pin the value to 1 credit = 1 hour of unskilled menial labor, and strictly control the supply.
With appropriate software monitoring and a lack of other methods of direct wealth transfer, it would make it impossible to not properly pay your taxes and vastly more difficult to exchange wealth without government oversight, and make money crimes vastly more difficult, from hiring criminals to do crimes to purchasing drugs and weapons for illicit purposes.
It's the perfect system for a dictatorship as well.
Crypto is complex but I don't think very many people could explain how Visa's merchant payment network functions. It just does, and no one has to think about it.
Yes and thats not the case for crypto. For crypto you need to choose a cryptocoin, need to understand what a wallet is, best case install a secure wallet from the internet etc.
You don't need to know how visa works as long as you know how to register for a cc and know how to put that card into a device when paying.
>Why would you spend crypto when you could get more for it if you wait a week?
that never stopped capitalist from spending their money even if they make profit from their investment. If your logic was true, no one who has access to investment opportunities (eg. the stock market) would ever spend any money.
I think you're taking a stronger interpretation than what I wrote.
I'm not saying no one ever spent any crypto.
I'm saying that because it was deflationary, people tended to spend less than otherwise. This was so bad with bitcoin that it failed to be usable as a currency.
If my logic were true, then when interest rates were higher and people could make more money doing nothing, then people with access to investment opportunities would tend to spend less money.
Visa/Mastercard have settlement times of over 24 hours.
Meanwhile, for over a decade now, Litecoin has had a settlement time of 2.5 minutes. And, for tiny (sub $100) transactions, it’s totally reasonable to just look up the wallet’s holdings in an instant.
For online transactions, you can always let the customer go immediately. Just wait 3 minutes before you ship :P
You are comparing apples to oranges. Settlement times in traditional credit card transactions are not felt by the customer, and provide safeguards for fraud prevention and charge backs. Furthermore, transactions are easily reversible through a claims system. Guess what crypto doesn't have?
This is exactly the apples I’m talking about. Merchants eat much higher fees on behalf of the customer so they can hide the much longer settlement times from the customer and accept that they’ll also have to just eat the occasional fraudulent chargeback from the customer. They put up with all this hassle because “That’s just how it’s always been if you want to do business.”
And, yet people say crypto can’t work because the fees are too high (they’re lower) and the settlement times are too slow (they’re faster).
Dealing with merchant fraud is a legit call-out though. I don’t know what a good crypto solution to that is. I can imagine replacing that department with a smart contract. But, I’ve haven’t looked around to see what’s been tried.
Alternative take, scheduling a rejection meeting without providing any indication about the meeting agenda creates an unrejectable obligation without any consideration for the candidate.
I usually pay about the equivalent of a few dollars to send Bitcoin transactions.
This system works cross borders, any time of day all days of the year.
Bitcoin may not be useful for everyone, but it is available for everyone in a way that traditional banks are not. And this is a far greater strength than a lot of people realize.
Bank transfers are free in my country even cross country.
So cost is more convenient for normal bank accounts.
Yes, speed is a factor if there's a weekend in the middle, but this is a non issue. I literally never ever had a need to pay someone or send someone money they needed in the very moment as I was sending it. It's really a non-issue.
Another few bonuses for bank transfers:
- are reversible in many cases
- you can't lose any money if you misdigit a single character or send the money to the wrong account you have still time to revert or contact your bank and sort it out
- they are simple to use. You can go in person and tell the cashier of the operation. You can use your application or website
- as with your bank account is tied to your person, not to whoever holds some cryptographic key. Nobody can really point a gun at me and tell me I ahve to give him what I have in my bank, we all know it doesn't work. But a secret key to a wallet? Good luck holding it.
- if I die my family will get the money. This is much more complex to handle with Bitcoin if not borderline impossible. Whoever holds his password can do what he wants with that.
> Bank transfers are free in my country even cross country.
So why do people pay so much money for wires?
Your entire post basically boils down to "Bitcoin does not provide any advantages for me". Hey, good for you then! Recognize that there are billions of humans that are not you and move on.
Perhaps one day, you will need to make a one time transfer with Bitcoin and you'll be glad that there's no way to censor you for your past Bitcoin-doubting ways, by design.
> Bank transfers are free in my country even cross country.
Try any fancy private bank or a bank on the other side of the world and you'll see.
Even national interbank transfer are generally complicated and slow and the complexity of the system is just well hidden mostly by low rate lending guaranteed by central banks.
I'm very familiar with congestion trading and was in that industry at one point, but cmon, this is a bad crypto talking point. It's already quite apparent that bitcoin mines actually destabilize grids just as much while driving up electricity prices for local consumers far more than any positive net effect from an energy perspective.
In Dear ImGui for instance, you can get the size of view containers and go as far as placing your UI elements at absolute positions (and also use a lower-level ImDrawList for custom rendering - which is also how you can extend Dear ImGui with your own custom-rendered UI elements, and all that absolute positioning and custom drawing is compatible with the automatic layout system).
The common misconception is that immediate mode UIs don't persist state between frames, but they absolutely do (it's just hidden from the API user). The 'immediate mode idea' is only about the public API, not the internal implementation (e.g. internally there could even be a traditional retained mode widget tree that's only modified, but not rebuilt each frame).
Err.. but I'm not talking about placing entities at absolute positions. egui supports that - that's how we get one widget in the center of the screen :)
I'm talking about having two labels in the center of the screen, making them full width, making the text word wrap, and having each label flow properly when resizing the window. That requires calculating word wrap for each label plus knowing where labels visually higher on the y-axis have decided to place themselves after considering word wrapping. Labels beneath other labels should get pushed downward when word wrapping occurs.
That seems really hard to achieve in immediate mode libraries without effectively recreating retained mode functionality yourself.
A layout engine is required in both cases. It's not necessarily more difficult in immediate mode than retained mode.
TFA demonstrates this exact functionality without "recreating retained mode". Check out the "Layout" section and note that the button is shrunk to the label, all of which is centered. The layout engine becomes an emergent property of the widgets rather than an algorithm evaluating a tree. Here, the code is the tree.
> That seems really hard to achieve in immediate mode libraries without effectively recreating retained mode functionality yourself.
The purpose of an IMGUI is to handle whatever data retention will simplify user's life. If you want to extend the IMGUI in some case it's perfectly adequate to do some that work yourself. Ideally the IMGUI infrastructure would make it as painless as possible.
Erlang's processes might have similar semantics to Go's goroutines (green threads) but Erlang is a much simpler language, because it doesn't have shared state.
A lot of work went into optimizing Go's GC to be able to cope with concurrency.
Aside from template based code, this is a disadvantage in my book usually
reply