pkolaczk

57 ms·

751.
by pkolaczk 7y ago
Event driven concurrency is not really easier than threads with primitive blocking synchronisation. Races are still possible, instead of deadlocks you can have livelocks, resource control and backpressure are non-trivial etc.
752.
by pkolaczk 7y ago
They both made billions DESPITE their technology choice, and both systems had to undergo a serious rewrite later. There are dozens of other projects out there almost noone ever hears of because they turn out to be a disaster and are cancell
753.
by pkolaczk 7y ago
Yet they often choose wrong tool for the job. We often see games written in Java, big websites created in PHP, or processing huge amounts of data in Python. Here someone wants to do embedded in Haskell. These are not technical reasons. The
754.
by pkolaczk 7y ago
In C++ lifetimes are not encoded in types. Therefore I seriously doubt it can do the lifetime analysis with such accuracy as Rust can, particularly if the whole source code (e.g. libraries) is not available.
755.
by pkolaczk 7y ago
If performance doesn't matter, then most likely this is a sign of using too powerful hardware for the job. This is ok in a hobby project, but if you wanted to produce and sell these on mass market, then your competitor would get a smal
756.
by pkolaczk 7y ago
If a developer wants to use a hammer for everything, because everything looks like nails to him, then I doubt in his professionalism. Sure, dev preferences matter, but only within the space dictated by the client requirements. Customers do
757.
by pkolaczk 7y ago
Not for all the things that Rust catches. And not for the most important things. Static analyzers typically catch trivial stuff like returning a pointer to a stack from a function. Which is easy to spot during code reviews. But they don&#x2
758.
by pkolaczk 7y ago
Swift and Kotlin are used for application programming there, not systems programming. Also, Google does Rust as well. And Microsoft is slowly switching some pieces to Rust as well. These are big companies with many teams and use many differ
759.
by pkolaczk 7y ago
> Indeed many in Rust community do not realize that the LLVM infrastructure they use for Rust to make its code executable by real hardware is itself written in C++. And the operating system is written in C, and the CPU in VHDL (or sth si
760.
by pkolaczk 7y ago
Template Haskell is not standard Haskell, it is an extension. But even with it, Haskell type system can't reason about lifetimes of objects. It doesn't give any guarantees about object destruction nor even object construction, du
761.
by pkolaczk 7y ago
Kotlin and Swift fall short on memory management and both need runtime and GC. Currently Kotlin native is an order of magnitude slower than Rust, and Swift is also losing in benchmarks sometimes by 10x (although, not always - purely numeric
762.
by pkolaczk 7y ago
Rust is very strong in its ability to build extremely powerful abstractions. With built-in compile-time procedural metaprogramming I could risk a statement that in some domains it may be actually even higher level than Haskell. Maybe its ty
763.
by pkolaczk 7y ago
> I mean I don't see people complaining how you don't need to manually manage memory in SQL expressions. Well, they don't complain about not having to manually control the low-level bits of query execution, but later they
764.
by pkolaczk 7y ago
Sure, I didn't say "useless". The post I was responding to was worded in such a way as if FP was the only suitable paradigm everybody should be using. FP is a nice and useful abstraction, but in some areas it is just too inef
765.
by pkolaczk 7y ago
Swift is not a competitor for Rust. It may be a competitor for Scala/Kotlin native or Go, but definitely not in the same performance league as Rust or C++. > Hopefully FP (functional programming) becomes more mainstream and take awa
766.
by pkolaczk 7y ago
> I think Rust gets a lot of hype because it's syntax is complex Rust syntax is simpler than C++. Rust is a much smaller language. To me it appears much more like a mixture of C and Haskell, rather than C++.
767.
by pkolaczk 7y ago
> Kotlin ability to idiomaticaly reuse the multi billions of value JVM ecosystem make this language outclass all others "modern languages This is simply a large overstatement. There are many other modern popular languages on JVM th
768.
by pkolaczk 7y ago
Looks like the language you wanted to mention is Scala. Pragmatic and has all the things you mentioned.
769.
by pkolaczk 7y ago
There exist libraries for native memory pooling in Java as well, and we're using them. I'm not saying low allocation code can't be done in C# or Java. But these languages don't give some nice tools that are present in C+
770.
by pkolaczk 7y ago
IMHO PyCharm is good among dynamic languages, but it's still far from the level of IDE support you get for statically typed languages. It is very conservative in the number of bugs it highlights. Same problem in VSCode and JS. While au
771.
by pkolaczk 7y ago
While I agree they can sometimes compete in numerically heavy tasks, the place where they fall behind is memory management. Systems like databases need very careful memory management and GC is not always your friend there. I'm still ho
772.
by pkolaczk 7y ago
Having written lot of Java, Scala and C++ (and recently some Rust), I must say it is much easier to avoid heap allocations in C++ and Rust than in GCed languages, thanks to explicit allocation on the stack and pass by value + move semantics
773.
by pkolaczk 7y ago
Easier to learn != easier to write. For a person like me who has learnt a few languages with static type systems like Scala or C++ first, which are also arguably harder to learn than Python, it is easier to write and read Scala or C++ than
774.
by pkolaczk 7y ago
I disagree. Type inference in statically typed languages (e.g. auto or var) does not weaken static typechecking guarantees. So it is not the same as writing type annotations only as much as you want. It is stronger.
775.
by pkolaczk 7y ago
I've heard about whiskers, but isn't it a mostly solved problem now with low Ag alloys like SAC0307?
776.
by pkolaczk 7y ago
I don't get this lead-free hatred on internet forums. People say they can't solder with lead-free, and that it is terrible, and that joints look dull. So much hatred that I actually tried it out. And I found the process is basical
777.
by pkolaczk 7y ago
Scala and Rust are not competitors. They solve different problems and are designed for different kind of software. Rust will never be in the same league of productivity / abstraction as Scala is. There is a huge mental overhead of manu
778.
by pkolaczk 7y ago
This has nothing to do with languages. I saw the same happening in a company writing pure Java, JS or Python. Doing a project with people who don't have command of whatever stack they are using is asking for trouble. On the flip side,
779.
by pkolaczk 7y ago
Will take years to get there, if they even get there at all. This is a single-man side project now. Also benchmarking something that has 1/100 of the original functionality and is not production ready is very unfair. It is much easier
780.
by pkolaczk 7y ago
Yeah, Jetbrains marketing wants you to think it is the other way round, but actually tooling support for Scala is ahead of Kotlin by far, except maybe Android. Scala is not tied to a single IDE, it works great in VScode, Eclipse and Intelli

More ›