Hirrolot

13 ms·

91.
Barebones Lambda Cube in OCaml(gist.github.com)
3 points by Hirrolot 4y ago|0 comments
92.
Checking Dependent Types with Normalization by Evaluation: A Tutorial(davidchristiansen.dk)
4 points by Hirrolot 4y ago|0 comments
93.
by Hirrolot 4y ago
From "A Philosophy of Software Design" [1]: > Ideally, when you have finished with each change, the system will have the structure it would have had if you had designed it from the start with that change in mind. [1] https:&#x
94.
by Hirrolot 4y ago
> Trying to get a feature stopped after they've built it is soul crushing for them. That's why I suggest first filing an issue, discuss a design, and only then actually implement the feature. Will save you many hours.
95.
by Hirrolot 4y ago
There's also an interesting programming language called Neut [1]: > A dependently-typed programming language with compile-time malloc/free determination. Also related "ASAP: As Static As Possible memory management" [2
96.
by Hirrolot 4y ago
Nice reference but with some strange bits: > Algebraic data types are usually represented using a heap. Because of their non-uniformity, algebraic data types are more difficult to scan. Using a heap??? We can represent ADTs using stack a
97.
by Hirrolot 4y ago
What software do you use to visualize the graph like this?
98.
“Lambda Calculus” by Carl Burch, Hendrix College, September 2012(cburch.com)
2 points by Hirrolot 4y ago|0 comments
99.
Some Internet Architectural Guidelines and Philosophy (2002)(datatracker.ietf.org)
1 points by Hirrolot 4y ago|0 comments
100.
by Hirrolot 4y ago
I had C programming experience before touching Rust. I may be biased, but I think this is the right way to understand how computer systems work. Otherwise, Rust's design choices will make little sense to you.
101.
by Hirrolot 4y ago
I am the author of the original post. Unfortunately, before publishing anything, it's very hard to predict all possible misinterpretations of my text. > I really wish the author clearly pointed out that they write the article from a
102.
by Hirrolot 4y ago
I think Rust will eventually repeat the story of C++. 1) There will emerge more ergonomic languages that solve real-world problems that Rust attempted to solve. 2) Rust's issues with type system and async will be largely resolved, so i
103.
by Hirrolot 4y ago
How then people write high-performance servers in JVM?
104.
by Hirrolot 4y ago
Quoting one publication about MISRA [1]: "From the data obtained, we can make the following key observations. First, there are 9 out of 72 rules for which violations were observed that perform significantly better (α = 0.05) than a ran
105.
by Hirrolot 4y ago
Well, the dispatcher problem is applicable outside of messenger bots too. But your point is right. I think it was a mistake that teloxide is written in Rust. I just wanted to learn a new language so I was like, why not writing such a librar
106.
by Hirrolot 4y ago
Completely agree! When you need to compute numbers or deal with raw bytes, you have C. When you need to be high-level, you have Python, Java, C#, etc. Rust is applicable only in areas where you need both a high-level and systems language. E
107.
by Hirrolot 4y ago
Hide memory management under a language runtime. Make a single Fn trait/string type instead of multiple ones. Add effect polymorphism to deal with function colours. Remove async/.await and express it using algebraic effects, do th
108.
by Hirrolot 4y ago
I agree; if you use dynamic `Arc`s almost everywhere in your code, what's the point in a systems PL whose essence is in managing static lifetimes? Sometimes people use Rust just because many other languages suck; they are choosing betw
109.
by Hirrolot 4y ago
async/.await in Rust is a perfect example of "code duplication" in the language core. Okay, you have a nice syntax for performing do-notation on futures, but what about iterators, streams, etc? We have generators in nightly a
110.
by Hirrolot 4y ago
> Rust is like C++ in the following way: it has many features and a complex type system, but that doesn't mean you should use all its features all the time! ... Until third-party libraries push you to use specific features.
111.
by Hirrolot 4y ago
I do completely agree with your advice of using `Arc`s. But unfortunately, sometimes it gets very tedious to deal with all these `Arc`s: https://github.com/teloxide/teloxide/blob/ec1d41220c51872cf9... . It als
112.
by Hirrolot 4y ago
Personally I avoided async and macros when I was learning Rust. Perhaps this is an advice I would give to new Rustaceans.
113.
by Hirrolot 4y ago
True about 'static. Sometimes I think I need an IDE shortcut for `Send + Sync + 'static`. Like `if err != nil`, you know :))
114.
by Hirrolot 4y ago
> Rust can work this way, but mostly doesn't by default. It's like you were programming in C++ but instead of normal copies and references, almost every single variable use was a std::move. Profoundly unintuitive. I just used t
115.
Go Type System Overview(go101.org)
1 points by Hirrolot 4y ago|0 comments
116.
SmolRTSP: A lightweight real-time streaming library for IP cameras(github.com)
18 points by Hirrolot 5y ago|0 comments
117.
by Hirrolot 5y ago
+1
118.
by Hirrolot 5y ago
Nice point, didn't know about that. My fail.
119.
by Hirrolot 5y ago
> This article spends many words to say, “there is no silver bullet”. Rather "I believe there is a silver bullet, but I don't know where yet". Probably I am too naive!
120.
Why Static Languages Suffer from Complexity(hirrolot.github.io)
3 points by Hirrolot 5y ago|0 comments

More ›