654 karma · joined June 19, 2018
For new code, I would not use Fil-C. For kernel and low-level tools, other languages seem better. Right now, Rust is the only popular language in this space that doesn't have these disadvantages. But in my view, Rust also has issues, specially the borrow checker, and code verbosity. Maybe in the future there will be a language that resolves these issues as well (as a hobby, I'm trying to build such a language). But right now, Rust seems to be the best choice for the kernel (for code that needs to be fast and secure).
Yes.
There is some psychological advantage. These ideas might make the overland options more acceptable for the population.
Switzerland and other countries have nice looking (and sometimes expensive) sculptures in traffic roundabouts. For transmission lines, it might make sense, even if it is more expensive. Sure, it depends on the price. But it is much, much cheaper than burring the cables: underground transmission lines are roughly 10 times more expensive, due to cooling mainly (and sometimes this would require converting to DC). So there are three options: traditional (cheapest), such designs (more expensive), or hidden (10 times the price of traditional).
I worked on Rubik's cube solving instructions for beginners [1] (for my children initially), but then I found it would be so much better if the instructions are IKEA style. (Then I vibe-coded a Rubik's cube 2D and 3D model, and now I stopped working on this. Something for later.) For the cube, I want to implement the algorithm, and then from the program create IKEA instruction (or a mix of IKEA and railroad diagram). That way I can be sure I didn't skip any steps in the instructions.
[1] https://github.com/thomasmueller/rubiks/blob/main/README.md
To detect this at compile time, you would need either min and max to be known at compile time, or a type system that supports value-dependent types. None of the popular language support this. (My language named 'Bau', which is not popular of course, support value-dependent types to avoid array-bound checks.)
[1] https://github.com/thomasmueller/bau-lang [2] https://github.com/thomasmueller/bau-lang/blob/main/src/test... [3] https://www.reddit.com/r/ProgrammingLanguages/
Well, when using a bitmap (as they seem to do in the article), then multiple subsequent dead objects are considered to be in the same range, because multiple subsequent bits in the bitmap have the value zero. There is no need to visit each zero bit in the bitmap separately.
But the malloc library could be fully integrated into the GC mechanism. In this case, there is no need. That's probably much easier, and faster, because the malloc can be simplified to bumping a pointer.
The challenge is things that don't _obviously_ need cryptographically secure generators. For example, do you need a secure generator for the seed of a hash table, or a sorting algorithm? (For those that do use a seed). Some will argue that yes, this is important. Until a few years ago, the hash tables used static hash algorithms without any randomization, but "hash flooding" changed that. I think that nowadays, still many hash table implementations don't use secure generators.
Then, there's secure and insecure hash functions. Secure hash functions like SHA-256 are (compared to non-secure functions) specially slow for short keys. There are "somewhat" secure hash function algorithms like SipHash that can be used for this purpose.
Basically.
In Fukushima, TEPCO was required pay $1.5 billion. But the real cost is / was around $150 billion. So, the bulk of the disaster was not covered / covered by the taxpayer. So: the public.
The main reason for negative electricity prices are inflexible generators, eg. nuclear and coal, because they can't easily (cheaply) ramp down or shut off. Sometimes it is cheaper to let prices go negative than to use emergency mechanisms (that do exist).
Negative prices are not all bad: they are an incentive for storage / flexible demand to step in. Specially, a negative price does not mean the grid is melting.
Nuclear has its own failure modes. In Switzerland, one of the nuclear plants will be offline for winter (!) due to "unplanned repairs". This will cost the owners of the plant millions.
Yes! But I am arguing that this prevents having multiple mutable references
> My Java knowledge is quite rusty > Also because Java is a GC'ed VM ...
Your Java knowledge is fine :-) But I'm arguing that you don't strictly need a GC'ed, or RC'ed language: if done "correctly", multiple mutable references are possible. Just not with fat pointers! The programming language I'm building allows this even today. You can try it in the playground [1]:
fun main()
list := List+(int[4]) # <<= owned list
borrow : &list # <<= mutable borrow
for i := until(4)
borrow.add(i)
list.add(10 * i)
for i := until(8)
println(borrow.array[i])
type List
array int[]
size int
fun List+ add(x int)
if size >= array.len
n : int[array.len * 2]
for i := until(array.len)
n[i] = array[i]
array = n
array[size] = x
size += 1
> A language without realloc sounds painful. Any growing container would lead to stale data.
I think it's not so much about realloc, but about whether it's a fat pointer or not. (I could imagine that Java uses something like realloc for the array, if there is only one pointer to the array for sure).
Fat pointers have some advantages and some disadvantages. Rust chose fat pointers, I assume for performance reasons. That's fine. Java doesn't. But I don't think that's a _huge_ performance disadvantage for Java. What I'm arguing is not so much that one is better and the other is worse, just that there are advantages and disadvantages. Rust might be slightly faster, but a language without (this kind of) fat pointers could potentially be easier to use.