pkolaczk

17 ms·

181.
by pkolaczk 3y ago
4. Ignoring the fact that not only language but also tooling is a significant factor affecting developer experience. Extremely long compile times, weird build system, lack of good IDE support. 5. Breaking backwards compatibility with each r
182.
by pkolaczk 3y ago
Fair point, but in order to make a deadlock, you need a reference back to the object that holds the lock. And back references in Rust are hard to make. Most of the time if you unlock too late, you get a performance problem, not a deadlock.
183.
by pkolaczk 3y ago
> They are error prone, you can forget to unlock That's not a problem with mutexes but with resource management in some languages. In Rust mutexes use RAII and unlock automatically - you cannot accidentally forget to unlock.
184.
by pkolaczk 3y ago
The later versions (somewhere after 2005) were also very buggy and sluggish. They produced fast code, but you really needed a powerful workstation.
185.
by pkolaczk 3y ago
Putting electronics in a fridge may work sometimes, but it may also cause irreversible damage if you're unlucky. The biggest threat to electronics is not just temperature but also moisture. Cooling the air captured inside a laptop may
186.
by pkolaczk 3y ago
Taking it up for no visible performance gain is wasting, not utilizing.
187.
by pkolaczk 3y ago
I guess that's the reason why most Java programs I use cannot do proper user-facing error messages. Because it is so easy to just ignore error handling. The exception will be caught by the top-level, right? This is how almost every Jav
188.
by pkolaczk 3y ago
Both Java checked and unchecked exceptions are inferior to signaling errors by return values like Go/Rust/Haskell do. Exceptions are not composable, cannot be generic, and it is not visible in the source code which lines can throw
189.
by pkolaczk 3y ago
How many independent things do you need to access the config? A dozen? Then there is a dozen calls to inc the RC at startup, but there is no later cost to read from object behind Arc. So you may read your config a million times and Arc chan
190.
by pkolaczk 3y ago
Go binaries are traditionally statically compiled.
191.
by pkolaczk 3y ago
The solution with sealed classes also allows anyone to extend the code, but in a different dimension than the solution with an interface method. The solution with interface method and virtual call is very inflexible when you want to add new
192.
by pkolaczk 3y ago
> 1. Write a test first so that its failure state is proven. This is useful for to me only when fixing existing code but not when writing new code. Before I write the implementation, it is obvious the test would fail. By not having to co
193.
by pkolaczk 3y ago
Rust has it. Just annotate your code with `#[cfg(test)]`.
194.
by pkolaczk 3y ago
> I've never understood why anyone would choose to debug by printing and logging if they have a good debugger available to them. Because logging provides a different experience and can be sometimes much faster. I can run the code on
195.
by pkolaczk 3y ago
Ok, in a very, very rare case (so far never happened to me) when I really need to await an async operation in the destructor, I just define an additional async destructor, call it explicitly and await it. Maybe it's not very elegant bu
196.
by pkolaczk 3y ago
You need to `block_on` only if you need to block on async code. But you don't need to block on order to run async code. You can spawn async code without blocking just fine and there is no risk of deadlocks.
197.
by pkolaczk 3y ago
> Go's design has more overhead but, by virtue of not having colored functions, is simpler for programmers to write code for. Colored functions is a debatable problem at best. I consider it a feature not a bug and it makes reasoning
198.
by pkolaczk 3y ago
> Golang supports running asynchronous code in defers, similar with Zig when it still had async. So does Rust. You can run async code inside `drop`.
199.
by pkolaczk 3y ago
The whole point of abstraction is to replace the need of understanding all the details of the implementation with a more general and simpler concept. So while the abstraction itself may have a non zero cognitive cost for the end user, thi
200.
by pkolaczk 3y ago
> and iterate 5x as fast as Rust. I've been involved in Java, Python, PHP, Scala, C++, Rust, JS projects in my career. I think I'd notice a 5x speed difference in favor of Python if it existed. But I haven't.
201.
by pkolaczk 3y ago
> The huge majority of allocated objects gets garbage-collected after a very short time, when they leave the context (similar to RAII). Those objects are also virtually no problem in languages like Rust or C++. Those are local objects wh
202.
by pkolaczk 3y ago
> Managed-memory languages don't require you to even think about lifetimes, let alone write them down. Memory is only one of many types of resources applications use. Memory-managed languages do nothing to help you with those resour
203.
by pkolaczk 3y ago
> even if it's still very un-productive next to productivity-oriented languages (e.g. Python). The thing is, for many people, including me, Rust is actually a more productive language than Python or other dynamic languages. Actuall
204.
by pkolaczk 3y ago
That's a fair point, but we really don't know if Rust was added to the company or only to this project. Big companies often use multiple tech stacks anyway. In my experience the language was never a bottleneck at onboarding new pe
205.
by pkolaczk 3y ago
Did you actually test it? Some time ago someone at another forum made a similar claim that returning an Optional from a method in Java will be surely optimized as we well, but it turned out that it wasn't ( https://pkolaczk.g
206.
by pkolaczk 3y ago
In languages like JS, Java, Python is trivial to accidentally make an object escape the scope by storing a reference in a field of another object that outlives the scope. And it can be another developer 3 months later that can introduce a
207.
by pkolaczk 3y ago
It is easier said than done, when the whole ecosystem is based on libraries and frameworks that allocate like crazy. Preallocating and reusing introduces complexity and increases likelihood of bugs. And at least in Java you can run into sur
208.
by pkolaczk 3y ago
Line is a string. It allocates a fresh one on each line even if the variable is reused.
209.
by pkolaczk 3y ago
They debugged the problem to be excessive allocations in the tight loop of the TSV parser. If you allocate a separate object per each field, I can imagine how it can result in throughput counted in kB/s instead of GB/s. We have ha
210.
by pkolaczk 3y ago
Setting to null doesn't release the memory. It only erases the reference. You still need to wait for the GC to complete.

More ›