HN user

zerodensity

106 karma
Posts0
Comments76
View on HN
No posts found.

I don't think this is true either - a large part of the Rust community seem to think that it's as complicated as it needs to be. As a beginner/outsider, I found it kind of cumbersome to get started with, but that's certainly not everyone's opinion.

Personally I feel it's not complicated enough. Where is my function overloading, variadic templates and usable compile time reflection? (Sure you can sometimes use macros but ew macros)

If you care very much about not ever ending up in a bad state (which it seems that you do). Then just functional programming with immutable state is not going to cut it. In this realm you should look into methods of formal verification to prove that your code does what you want it to do.

That being said, functional verification is a huge time sink and is really only economical if it's very important for the code to always be correct. That is, people die if your software has a bug. A few examples would be pacemakers, aircraft autopilots or your car brakes.

If your not working one of these domains then maybe immutable and pure functional code can save you a few bugs? I have not read any peer reviewed study that shows this is the case. But if you have any such paper i would be happy to read it.

Immagine a world where every framework / API / database had its own incompatible UUID format. Without a standard specification that's where we would end up. Do you want to live in such a world?

Well I mean in many countries, blocking the surveillance agency from listening in on your calls/texts/chats is illegal. So making an app that interferes with the agencies ability to "listen in" is infact a criminal enterprise.

Don't have to like it but the law is the law.

I have heard this before but never really understood it.

Take this:

```

int bar(int arg); // May throw

int foo(int arg) {

    int b = bar(arg);

    return b * 5; 
}

```

VS:

```

Error<int> bar(int arg); // Uses error type

Error<int> foo(int arg) {

  auto b = bar(arg);

  if(b.ok()) { // Happy Path

    return b.unwrap() * 5;
  }

  return e; // Exceptional Path
}

```

In the happy case (no exception) how can the first version be harder to optimize than the second one? In the exceptional case exceptions will probably be slower. You trade fast common case for slow exceptional case so it makes sense to me. Is the slower one the one that is hard to optimize? Is this what we are talking about when optimizations are harder to reason about? Or are there some other things that become harder because of exception? Things like RAII, defer, goto stuff?

If only this was how it worked :(

From my experience a substantial fraction of programmers learn the absolute minimum to get a job.

Then they either learn on the job or ask the same questions over and over again, never learning. The latter being the really annoying people to work with.

For a start, String objects are going to be different everywhere. Even in C++, one library's String object isn't going to be binary compatible with another. How is the data laid out, does it do small string optimisation, etc? Are there other internal fields?

I don't really think anyone expects a c abi to have multiple implementation defined string types. They want there to be a pointer + length string interface removing the use of null pointer style strings alltogether.

If this new style ABI returns a 'string' (pointer and length) of some sort, you have to package it up in your own object format

A c function with proper error, (that is something you want to have for all your interface functions). Normally looks something like this.

int name(T1 param_1, T2 param_2, ..., TN param_n, R1* return_1, R2* return_2, ..., RN* return_n);

Where the return int is the error code. param_1-param_n the input parameters. result_1-result_n the results of the function.

When writing these kinds of functions having an extra parameter for the size of the strings either for input or output is not a huge complexity increase.

Will you need an extra object type to represent 'string I got from an ABI, whose memory is managed differently'?

Which memory management system you use does not impact if you use null terminated strings or a pointer + length pair. Both support stack, manual, managed or gc memory. It's just about the string representation.

For example:

I use a gc language.

I call a c library which returns a string that I get ownership of.

Now I want to leverage the gc to automatically free the string at some point. What I do is tell the gc how to free it, I have to do this no matter how the string is represented.

Or take the inverse.

I send in a string to the c library, which takes ownership of it.

Now the library must know how to free the memory. Typically this is done by allocating it with a library allocator (which can be malloc) before sending it to the function. Importantly the allocator is not the same as the one we use for everything else.

What I am getting at is that if you are not using the same memory system in the caller and the calle you have to marshal between them always. No matter if you are using null terminated strings or a pointer + length pair.

Am I? I think not.

You are saying that you would rather live a shorter time in good health than a longer time being unhealthy at the end.

I am saying that the day will come when you start to deteriorate, get aches, getting slower, maybe even critically ill. During all that you will most likely still not want to die.

People suffer in every age group most of them don't want to die. Why do you think you would?

Hard does not matter. If it takes the new life 100k years to go from agricultural to the industrial revolution rather than the 10k years it took us they will still get there. What I am saying is that it's not impossible to have an industrial revolution without coal. Not that it's not hard.

Having excess energy is great!

We can use it for alot of useful stuff. For example to:

- Recycle waste products. Most (not all) things are recyclable you just need the energy.

- Grow food vertically so more land can be nature.

- Siphon greenhouse gasses out of the atmosphere.

- Desalinate Water

Maybe nuclear will make a comeback once the now installed wind/solar plants reach end of life and need replacement, but before that it is just too slow and uncertain to be effective tool (with our current engineering/construction capability!) to combat climate change imho.

If we do not start working on brining nuclear power online now it will not be ready when the current generation of renewables needs replacement.

We will also require wast amounts of power just to undo the damage we have already done. Capturing CO2 is practically a must if we don't want the permafrost to melt and release the up to 1,700 billion metric tons of carbon stored there.

Will we have enough renewables to run our society and extract the required CO2? Maybe, will nuclear help while using 1/1000 land yes.

Does it matter if nuclear takes 15-20 years to build? No, it does not matter. When it's built it will help out.

They will adapt or die and something will replace them. Diversity will go down for a while and then back up again. It's almost impossible to sterilize Earth and as long as something lives on it will eventually flourish again. It will never be the same but something else will flourish.

It's only the engineers problem if the engineer has signed a contract specifically stating that they have to work overtime in emergencies. If not then it's the company's problem.