Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
K0nserv
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
10 ms
·
151.
▲
by
K0nserv
2y ago
As another sibling comment pointed out there are many tools that enable local reasoning, encapsulation is one such tool. I'm not claiming the idea is novel, just that I haven't encountered a name for it before.
152.
▲
by
K0nserv
2y ago
I split local reasoning into horizontal or vertical. Vertical reasoning is reasoning inside a module or function. Here information hiding and clear interfaces help. Horizontal reasoning is reasoning across the codebase in a limited context;
153.
▲
by
K0nserv
2y ago
Statically typed code definitely requires more effort to read, but this is not cognitive load. Cognitive load is about how much working memory is required. Statically typed code requires less cognitive load because some of the remembering i
154.
▲
by
K0nserv
2y ago
An interesting point. Would there be any benefits to this non-local reasoning?
155.
▲
by
K0nserv
2y ago
Comments are decent but flawed. Being a type proponent I think the best strategy is lifting business requirements into the type system, encoding the invariants in a way that the compiler can check.
156.
▲
by
K0nserv
2y ago
Tests are good but moving left by lifting invariants into the type system is better. Compare fn send_email(addr: &str, subject: &str, body: &str) -> Result<()> to fn send_email(add: &EmailAddr, subject
157.
▲
by
K0nserv
2y ago
I've been thinking about the notion of "reasoning locally" recently. Enabling local reasoning is the only way to scale software development past some number of lines or complexity. When reasoning locally, one only needs to un
158.
▲
by
K0nserv
2y ago
Core properties of well functioning markets is information symmetry and transparency. I don't think this describes a lot of consumer goods. Even consumers who want to do their research will find that there isn't enough information
159.
▲
by
K0nserv
2y ago
Simple for users is not the same as simpler for developers, WebRTC definitely is a beast.
160.
▲
by
K0nserv
2y ago
It's a fundamental limitation of P2P that you need NAT hole punching. If you use IPv6 it's truly peer to peer since you can generate ICE host candidates directly. Also, you don't actually need NAT hole punching if you use fix
161.
▲
by
K0nserv
2y ago
Sure race conditions in general, but the subtlety that it can cause memory unsafety, not something I recall being mentioned.
162.
▲
by
K0nserv
2y ago
I believe UB without unsafe is considered a bug by the Rust language team. I should’ve said in my original comment, but I don’t mean to dunk on Go. In practice the issues illustrated in the blog post I linked seem unlikely to cause problems
163.
▲
by
K0nserv
2y ago
Somewhat related, I learned a surprising fact recently: Go is not actually memory safe. In particular because atomicity is only guaranteed for word size values, double word values(interface pointers, slices) can introduce memory unsafety in
164.
▲
by
K0nserv
2y ago
> dreadful concurrency model (I will never voluntarily go back to async/await after working in Golang) With the exception of having to write out `async`/`await` the dominant concurrency model in Rust is mostly the same as Go(wo
165.
▲
by
K0nserv
2y ago
What an excellent project and idea. Accessibility is always a big gap in these cross-platform, lowest common denominator frameworks, glad to see someone is trying to tackle it.
166.
▲
by
K0nserv
2y ago
Rust has the same problem. Files are closed in `Drop` when the value goes out of scope, but all errors are silently ignored. To solve this there's `sync_all`[0]. Generally, relying on defer in Go or Drop in Rust for anything that can f
167.
▲
by
K0nserv
2y ago
It depends on the axis you are considering. Swift might be slower than Rust, but it has an equally powerful type system. Swift and Go are much less similar than Swift and Rust in this regard.
168.
▲
by
K0nserv
2y ago
I love both Rust and Swift, they have their respective strengths. I would say Swift has a less noisy surface syntax, but instead uses more dedicated keywords and compiler magic. This is nicer, but means some areas are "compiler only te
169.
▲
by
K0nserv
2y ago
Sort of, this API enables static dispatch, but it could also have been written as pub fn read<P: AsRef<Path>>(path: &dyn P) -> Result<Vec<u8>> In which case the size of `path` is always the same(two wo
170.
▲
by
K0nserv
2y ago
That's orthogonal. If the type was `&[u8]` instead of `Path` the type signature would be: pub fn read<P: AsRef<[u8]>>(path: P) -> Result<Vec<u8>> The reasons for it to be generic and us `AsRef` r
171.
▲
by
K0nserv
2y ago
Rust needs to know the exact size, layout, and alignment of every argument passed to a function to determine how it gets passed(register(s) or spilled to stack) and used. For example PathBuf and String can both be turned into a reference to
172.
▲
by
K0nserv
2y ago
What are some examples of the complex semantics? The things I can think of(lifetimes, generics, traits) exist and are modelled in C too, but just with less(or no) support from the language and compiler.
173.
▲
by
K0nserv
2y ago
> My personal opinion is that Rust is a bit too lengthy to keep everything in your head I'm curious what you mean by "lengthy" here. The reason I say Rust lets me keep fewer things in my head is because something like this
174.
▲
by
K0nserv
2y ago
Is it? I don't know if keeping Rust's syntax C++-like is a stated goal of the project, but okay sure we can add that caveat to my question. The big problem I see is that people will say "Lifetime annotations are ugly and nois
175.
▲
by
K0nserv
2y ago
> That's why so many useful things start with a single person or *a very small team*, You subtly shifted the goal posts here. But even if you start out with a single person you eventually have to have new maintainers, if only becaus
176.
▲
by
K0nserv
2y ago
The more interesting follow up question is: "How would you express the same semantics with a different syntax?" Too often discussions about Rust's ugly syntax lack this crucial component.
177.
▲
by
K0nserv
2y ago
The author makes the best argument for Rust in the linked post[0] Rust is great for teams because it removes many things that make working on team code dangerous. The items mentioned above are some. I work alone, however, because
178.
▲
by
K0nserv
2y ago
Fun game, I got 76 and forget a bunch of common tags in the process: noscript, title, address, source(but I did get picture)
179.
▲
by
K0nserv
2y ago
People are stressed, get distracted, are tired, don't have complete knowledge etc. This is kind of like arguing that null pointers aren't a problem, you "just" have to check all usage of the pointer if you make it null.
180.
▲
by
K0nserv
2y ago
You don't have to add a catch-all arm, you can still explicitly match i.e match value { A => { do_stuff() }, B => { unreachable!("B is not applicable here because <reason>") }, } now when
More ›