Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
pkolaczk
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
56 ms
·
691.
▲
by
pkolaczk
6y ago
Rust can statically prove there are no data races, Go cannot. Rust offers statically checked deterministic destruction, which makes handling non-memory resources much safer from leaks. Failing to dispose non-memory resources properly (e.g i
692.
▲
by
pkolaczk
6y ago
While Rust may not guarantee freedom from memory leaks (probably no Turing complete language can), I find it makes a much better job on resource management than many other GCed languages. I find it is much easier to leak a file descriptor i
693.
▲
by
pkolaczk
6y ago
> there's a positive correlation between number of abstractions and code size What really matters to me is how much code I need to read to understand how it works. I prefer to work in codebases where I need to read 100 lines out of
694.
▲
by
pkolaczk
6y ago
Counter: Every failed IT project that I have worked on in the last 20 years had too much code. Code is bad. Delete code mercilessly. Seriously though, the problem are bad abstractions, not just abstractions. A total lack of abstractions is
695.
▲
by
pkolaczk
6y ago
Each test was executed twice for the same program. The caches were always dropped before the first run, but not the second run. The second run was performed immediately after the first one finished, to check how much it can benefit from cac
696.
▲
Show HN: Fast duplicate/unique file finder in Rust
(github.com)
6 points
by
pkolaczk
6y ago
|
2 comments
697.
▲
by
pkolaczk
6y ago
Allocation heavy Java is also very slow. But it is much easier to avoid heap allocations (and virtual calls!) in C++/Rust than in Java.
698.
▲
by
pkolaczk
6y ago
It is nowhere near stack allocation, please stop this nonsense. There was a paper claiming that, but the requirement was to set heap size 7x bigger than needed. Stack is also very hot in cache. Memory that GC is handing allocations from is
699.
▲
by
pkolaczk
6y ago
I wouldn't be so sure. There is no easy answer. It typically wins in trivial benchmarks, where the total heap size is small. However once you have a big heap of other long lived stuff, there is a significant indirect cost caused by sca
700.
▲
by
pkolaczk
6y ago
You can use GC to implement the persistent structure in C++/Rust just fine. But then you pay the GC cost for only that structure, not for all the other things.
701.
▲
by
pkolaczk
6y ago
Only if you write C++ like Java. But there are also coding styles heavily based on templates, and then the use of multiple, or any inheritance is rare. Rust and Go can do without inheritance at all.
702.
▲
by
pkolaczk
6y ago
Because it leads to hard to understand code. If N unrelated (or loosely related) things can mutate the same object, then you get a O(x^N) explosion of potential mutation orders and in order to understand that, you need to understand all the
703.
▲
by
pkolaczk
6y ago
I read it differently, because he started with "You(r) Rust borrow checker", making his point automatically in oposition. But now after reading without this You at the beginning, I agree it was neutral.
704.
▲
by
pkolaczk
6y ago
From Rust docs: It's important to understand that unsafe doesn't turn off the borrow checker or disable any other of Rust's safety checks: if you use a reference in unsafe code, it will still be checked. The unsafe keyword on
705.
▲
by
pkolaczk
6y ago
> Rust borrow checker requires special annotations and restrictions put on the code to do its job. This is a good thing, because it makes lifetimes and ownership explicit and visible in the code. It serves the similar purpose as type ann
706.
▲
by
pkolaczk
7y ago
Because it is simpler than Java, in particular when you limit it to the subset of features covered by Java only. Many Scala features that do exist in Java are more complicated in Java. And some do not exist at all, which means you have to
707.
▲
by
pkolaczk
7y ago
Only if you want to minimize the total complexity, which is almost never a good idea. What is more important, is the minimum amount of complexity needed to be understood in order to make a change. If you are able to test a small subset of c
708.
▲
by
pkolaczk
7y ago
The same applies to algorithmic challenges given for whiteboard coding. The fact one can reverse a linked list doesn't mean one would be a good developer in a real world project. Whiteboard coding doesn't check the basic system de
709.
▲
by
pkolaczk
7y ago
How do you avoid heap allocations in Haskell? Automated reference counting is technically a GC, but a kind of GC that can be enabled only for a subset of objects. In languages which force GC on everything (even reference counted GC) the inc
710.
▲
by
pkolaczk
7y ago
To some degree, probably. Structs have many limitations though and two different argument passing semantics in the same language mean more complexity. Also you may be lucky to eliminate allocations in your own code, but what about libraries
711.
▲
by
pkolaczk
7y ago
It is much easier to avoid malloc writing C than to avoid new in Java.
712.
▲
by
pkolaczk
7y ago
Because GC addresses only one type of resource: memory, but there exist many other types of resources, and handling them correctly is PITA in most GCed languages.
713.
▲
by
pkolaczk
7y ago
Rust doesn't have classes. It has structures (struct) and interfaces (trait).
714.
▲
by
pkolaczk
7y ago
C is far from zero-abstraction-cost. For example you can't do a generic qsort supporting user defined types with zero overhead, other than with preprocessor macros (ugly, unsafe, unmaintainable).
715.
▲
by
pkolaczk
7y ago
> Yeah, except not every business is willing to wait 25 years for Rust to achieve parity with today's Java ecosystem. Unfounded speculation. You've made this number up. > Rust IDEs can't still offer completion that work
716.
▲
by
pkolaczk
7y ago
But now you're taking about tooling and not languages. Rust will eventually get there. IDE support is already very good and better than for many popular languages (e.g. dynamic ones). Performance profiling is also better than in Java.
717.
▲
by
pkolaczk
7y ago
My point is these languages you mentioned don't offer good tools to optimize that 1% and they make the other 99% an order of magnitude slower and more resource hungry to the point where it actually matters and annoys users. Also neithe
718.
▲
by
pkolaczk
7y ago
"productivity of GC" is often offset by much harder management of resources other than memory due to lack of deterministic destruction. Also benchmarks show Swift and C# are still about 2x-5x slower than Rust and C++, and that onl
719.
▲
by
pkolaczk
7y ago
Correct, in simple cases it can do it, but you need to be very careful with computing the arguments for the logging call. Java has no lazy evaluation of args nor macros, so if you accidentally concat strings there or do something expensive,
720.
▲
by
pkolaczk
7y ago
I wonder how this works. If someone could work remotely for GitLab, they could also do another remote job for another global player, so local prices don't matter that much. Maybe this strategy can work now when there are only a few rem
More ›