The whole dictionary is loaded client-side and a lookup is performed on each keypress. Because of the search speed, it's surprisingly fun to use this dictionary to explore the language. I'd like to see such dictionaries built for other languages too.
Well, that's because threads are just first citizen in Zulip, even more than in Slack!
Basically, a thread is visible at a first glance from the UI, while that's not true in Slack. Also, you can kinda replicate Zulip structure by just using channels with naming conventions, so you have:
- generic channels, e.g. for status update for many stakeholders
- specific channels for each feature
- threads in each channel where you discuss a single point
In my experience code quality falls out from making mental simulations easier to produce. Abstraction boundaries should be drawn where mental processing starts feeling burdensome.
When running abstract mental simulations, do you assume that I/O operations succeed or fail for knowable reasons? It seems likely. If the code were expressed to match your mental simulation, for example by not performing I/O within the function, but by merely receiving I/O messages from a foreign actor, it seems like you're not far away from offloading the full mental simulation to something like quickcheck and writing down explicit invariants!
This is why I say my ADHD has made me a better programmer. I can't mentally simulate more than the most basic state interactions. I have to write code that my rainy-Monday-morning, pre-meds, pre-coffee brain can reason about. And I see that as a win/win. It means someone foreign to the codebase has to put less thought into reasoning about it. My brain handles big picture thinking super well, but I can keep about 1.5 pieces of state in my working memory.
I love my IDE. I love interfaces, type systems, and static checks. ADHD pretty much forced me into a very functional programming style, because mutation is so more to think about.
Conversely, some of the most inscrutable and buggy code I've written was when my meds were a tad high and I could easily reason about really complex interactions.
They are optimizing only for code size, so they don't need to run the code: they only count bytes emitted.
This works by changing around the order / interleaving of various LLVM optimization phases, so the learning process does not require knowledge of program timing or correctness.
I heard when they started to do this, LLVM folks were freaked out because they worried changing orders may affect correctness. But it seems to work so far :)
The parent post is objecting to a statement from Mozilla opposing "the rampant use of the internet to foment violence and hate, and reinforce white supremacy."
Google's interpretation implies their belief that if their PostgreSQL server uses AGPL code, then every service using that PostgreSQL server must also be AGPL.
The article points out that that is not the case.
If you are using AGPL code as a library, however, then your application as a whole must be under an AGPL-compatible license. It's just that connecting to a server does not constitute linking in the GPL, and the AGPL doesn't change that.
The article points out that Drew believes it isn't the case. Until this stuff is tested in court, there isn't a lawyer worth the name who would guarantee that. The language isn't precise enough to be 100% sure how courts will interpret it, and the downside risk is monumentally huge for a company like Google if the ruling goes against them.
> downside risk is monumentally huge for a company like Google if the ruling goes against them
The downside risk is damages. Those usually aren't monumentally huge. There's a calculation, but they're based on how much damage was done:
1) How much did Google profit from the code?
2) How much did the other party lose?
3) Are statutory damages greater?
Pick the highest of the three. If it's intentional -- and in this case it isn't -- you triple it. You might toss in legal fees.
#1 is the relative cost to going with an alternative solution (build in-house, license, etc.). #2 is usually zero for AGPL code. #3 is pocket change for Google. So you're likely to go with the cost of not having gone with AGPL in the first place, twice (once in damages, and once for the migration).
I don't think that's a fair interpretation of what Google said. Their reference to "accessed over a remote network" is about triggering the virality provisions in the first place, since the AGPL doesn't require you to distribute anything if you're just running a program by yourself without sharing it.
JIT engines like this one don't receive much benefit from being rewritten in a memory-safe language. Errors typically occur in the generated machine code, not in the compiler itself. The benefit would be small.
There's more benefits to Rust than just it's memory safety. It being a non-GCed language with ADTs is a big one, and that's been nice for the couple JITs I've written in Rust.
And the partial memory safety over the metadata around the actual JITed code is a big win as well.
Yes, Rust doesn't get you there 100%, but IMO it gets you closer than C or C++.
Having used both (and in the space for writing JITs particularly), C++'s support is very weak in the space of ADTs. Like most things in C++ you _can_ reach it with straight jacketing yourself in a particular way, with 80/20 static analysis rules backing that and 20% manual code review, but it's difficult to maintain.
Rust gives you that more or less by default and for free wrt tooling. It's sort of the classic "Rust makes you write the C++ you should have been writing all along", which makes it a net win IMO.
Given the fact that Mozilla is the primary sponsor of Rust, and Rust has been sneaking its way into Chrome as well, I'd say the authors of those browsers disagree with you.
I'm not them, but I suspect that they're slowly switching not because of its slightly better abstract data types but because it offers better memory safety.
Those are one and the same. The ADTs are how the shape and validity of the data is described to the compiler in a lot of cases. Rust wouldn't be able to be memory safe without it.
C++'s ADTs are easy to subvert even accidently; Rust's can't be without explicitly calling it out as unsafe.
It allows you to describe transformations of state in a formal set theoretical way. You should check out formally verified software like CompCERT and sel4 and their heavy use ADTs internally to achieve that. Rust obvs isn't full formally verified but it's a neat 80/20 in that direction.
That's exactly the point I wanted to make (but failed to) a couple months ago [1] - that for the (few) tasks you'd use C for (such as writing language runtimes) Rust might not be a good fit. If it isn't a good fit for regexp, it might not be a good fit for JavaScript either.
It’s not that rust wasn’t a good fit. It’s that writing a regex engine from scratch in rust to be integrated into their c++ code base wasn’t the right choice for them when compared against integrating an existing c++ solution.
1. Without wondering if you sincerely mean it, make a point to say "thank you." Typically if you are depressed you will be alone, and so it is possible to recognize situations where you took an action now to make something easier for yourself later: for example, doing the dishes now instead of waiting for them to pile up. When that happens, verbally thank yourself on behalf of your future self. If you're capable of doing this, it jump-starts gratitude after a while.
2. Instead of feeling gratitude for things you perceive as positive, look for things that you perceive as neutral. The majority of your sensory experience is neutral. If your emotions are very negative, instead of looking for a dichotomy between negative and positive, look for a dichotomy between negative and neutral. You will perceive that neutral is not-negative. Because neutral is not-negative, increased perception of neutral sensations is a positive. If you perceive neutral sensations as positive for long enough, it jump-starts gratitude after a while.
The problem with that though is I perceive nuetral as negative. Neutral is registered same as negative because it's not positive. This is why gratitude is hard because people like me can't find the positives nearly enough to start recognizing and changing how I think.
In fact, I find it difficult to think that people are okay with neutral because how is that any better? You arguably still failed at whatever you were trying to do, just the results weren't as harsh. I dont know. I think I might just be really far gone at this point.
I'm talking about neutral perceptions, not thoughts. An example would be something like the visual perception of a sidewalk. Presumably you don't get an emotional reaction about the sidewalk one way or the other, it's just a sidewalk.
The majority of your sensory experience is neutral perceptions like that. Once you notice them, negativity seems small in terms of proportion of sensory experience. What actually happens is that negativity occupies the majority of attention, meaning that your mind is latching onto things you perceive as negative. Broadening the scope of awareness to include neutrality means that definitionally the mind is not as latched-onto the negative, therefore negative things seem smaller, therefore they are slightly more tractable to deal with.
The whole dictionary is loaded client-side and a lookup is performed on each keypress. Because of the search speed, it's surprisingly fun to use this dictionary to explore the language. I'd like to see such dictionaries built for other languages too.