aiono

Because software is rarely done. Also you will likely to write newer programs with the same but improved language that doesn't have the warts in the earlier versions. Isn't it worth paying a small price for the improvement you get in the future?

First issue it makes killing people easier. We already see it in IDF soldiers feeling less guilty because in the end decision is made by AI-assisted targeting systems. Secondly it automates killing people. Now a soldier doesn't need to use the weapon himself, he just oversees them and the killing itself is automated. Imagine how much more deaths it will lead to.

Modern culture seems to encourage "hacking" more than cultivating self-discipline.

I think treating AI as the best possible field for everyone smart and capable is itself very narrow minded and short sighted. Some people just aren't interested in that field, what's so hard to accept it? World still needs experts in other fields even within computing.

Or if everyone depends on another maybe we will not go into a war with each other.

> 1. If the code implementing the module API is private, it must all be colocated in one package. If it is public, then anyone can import it, breaking the module boundary. You need a visibility system that can say "this subtree of packages can cooperate with each other, but code outside the subtree can only use the top-level package."

This is easily achieved in Scala with a particular use of package paths. You are allowed to make some symbols only visible under a package path.

A lot of criticism of Rust (not denying that there are also a lot useful criticisms of Rust out there) boils down to "it requires me to think/train in a different way than I used to, therefore it's hard" and goes on to how the other way is easier which is not the case but it's just familiar to them hence they think it's easier and simpler. More people should watch the talk "Simple made easy" https://www.youtube.com/watch?v=SxdOUGdseq4

In practice yes, so when you try to execute the function that accepts `Void`, that will error out. But there is no reason to not compile it because it will never actually execute. This may sound unpractical but quite the contrary it's very useful. For instance, it's used to model functions that panics in Rust (https://doc.rust-lang.org/reference/types/never.html). That way you can have a function called `todo` which fails when executed, but keeps the type checker happy until you actually implement it.

Void in Haskell is not the same thing as `void` in C, C++, Java or similar languages. If you return `Void` in Haskell, you will get a runtime error but `void` returning functions in C-like languages don't fail. It's not a type that doesn't have any value, rather it's a type that has a single value (normal return). Therefore it's more similar to `unit`.

That's the point I tried to make. All my bachelor education there was no single mention of sum types even though we learned about the visitor pattern. Instead of having to model sum types with object hierarchies, the language should provide a straightforward way to represent them since it's a very basic concept. I think that while things have improved a lot compared to past, sum types concept is still not known as much as objects for instance. Today all mainstream languages added direct support for sum types but awareness of it lacks.

> With Monday’s announcement universal child care will be extended to every family in the state, regardless of income. This amounts to an average annual family savings of $12,000 per child.

I think you conflate happiness and pleasure. Maintaining a family surely not always pleasant, but for the most people it makes you happier than being alone.

Do you mean native compilation instead of bundling the jar with a JRE?

This hits the nail for my sentiments about the matter. Good that someone who was actually in the business confirm it.

I think solution is neither. Such apps are now as much as essential as schools, hospitals and public infrastructure. Hence governments should build them with tax money.

I agree with the last paragraph about doing this yourself. Humans have tendency to take shortcuts while thinking. If you see something resembling what you expect for the end product you will be much less critical of it. The looks/aesthetics matter a lot on finding problems with in a piece of code you are reading. You can verify this by injecting bugs in your code changes and see if reviewers can find them.

On the other hand, when you have to write something yourself you drop down to slow and thinking state where you will pay attention to details a lot more. This means that you will catch bugs you wouldn't otherwise think of. That's why people recommend writing toy versions of the tools you are using because writing yourself teaches a lot better than just reading materials about it. This is related to know our cognition works.

While I am AI skeptic especially for use cases like "writing fixes" I am happy to see this because it will be a great evidence whether it's really providing increase in productivity. And it's all out in the open.

Looks really neat. But it also seems a bit heavyweight (for the client). Is it the case compared to https://readeck.org/en/ ?

Siemens and Bosch are also not "large startups" because they aren't startups.

The core problem is media being a for-profit organization. As long as the primary goal is profits it will be focused on extracting as much as attention as possible. It's an insignificant issue that it also ruins our attention, spreads misinformation etc. as long as profits go up.

> It's a real shame OpenAI didn't succeed with their core and most fundamental mission of being open and improving humanity as a whole

You frame it like they sincerely had this mission at all. Which I doubt seriously. Why would anyone who funded them have such aim?

> The first rule of network transparency is: the network is not transparent.

That's precisely why current request model is painful.

Very cool! This is exactly the topic I will probably be working in my Masters thesis. I am curious if you done anything about linearity and concurrency in the type system. Can one send files across threads for example?

I am from Turkey and this really concerns me. If we don't protest this in the streets and fight back I am afraid we don't have any kind of law anymore.

Software is complex and our memory is bottleneck to create software. We can only remember so many things therefore anything that we can make computer to "think" instead of us we have more memory to use for other work. In this case, instead of worrying if you are accessing some random global variable by accident is unnecessary cognitive work you. Why not just let computer do it while you think for actual things?

Can I pirate books to train myself?

I like many aspects of Rust's error handling, but I think it still lacks the composability part. Its not straightforward to compose two functions that return different failure sets. One thing you can do is to merge enums for both functions, than you lost what failures each individual function can have and having to do that is a lot of unnecessary work. Other option is you can return a boxed trait then you no more encode what errors are return from each function. User has to rely on reading the documentation for what kind of errors can occur.

In practice people catch runtime exceptions all the time so it's treated more as a recoverable error than a bug. Java let's you recover from runtime exceptions as easy as checked exceptions which blurs the distinction.

> And if you are only writing a prototype, declare that it throws Exception, or if you can't, a catch (IOException ex) { throw new UncheckedIOException(ex); } really isn't that bad.

The problem with that is when you go back to do proper error handling you can't easily find all those places where you did this. For instance in Rust, you can find those by searching for `unwrap`.

> I see parallels between the debate about typed vs. non-typed errors and the debate of static typing vs. dynamic typing in programming languages.

Author of the post here. I also see this parallel in error handling discussions. But seems like it's much harder to sell error handling than static typing. Static typing was also much more debatable in the past then now so maybe same can happen to error handling mechanisms in the future as well.

Your project seems very interesting! Typescript is sophisticated enough to model complex Result-like types that can narrow-widen error cases throughout the code. I will check it more if I find the time.