[vips7L]

Dart is an amazing and underrated language too. It compiles to native assembly, has pattern matching, async/await, and null safety. The only thing it's missing in my opinion is some form of checked errors, currently they only have unchecked exceptions.

[kiawe_fire]

Oddly, I’m conflicted on Flutter so far, but I have loved working in Dart.

So much so that I ended up writing a queueing app for scheduling batches of sequential tasks on the server in Dart just to see how it could work as a NodeJS replacement, and thought the whole dev experience was great.

[NeutralForest]

I just don't trust Google with a programming language. I feel like Golang has escaped the orbit of Google and could survive without it (I might be wrong). But for Dart I'm pretty sure it would die fast and I don't want to invest time into it as a result.

[vips7L]

I read that AdWords is built on Dart’s JS transpiler so I wouldn’t expect for them to just get rid of it. I really wish they would have pushed it over Go tbh. I’d love to use it for back end services.

[NeutralForest]

It looks cool ngl and I might get around to try it out but I wouldn't bring it at work for example.

[geodel]

> The only thing it's missing

I think biggest thing it is missing is any kind of Google commitment on its long term usage.

[tadfisher]

The modern language landscape is backing away from checked exceptions. Funnily enough Kotlin eschewed them as well, converting checked to unchecked exceptions on the JVM.

[vips7L]

The modern language landscape has not backed away from checked errors. Rust is praised for its checked errors, countless posts on this forum praise Result<T> in multiple languages. Swift has checked errors and Kotlin is implementing them via union types in the near future.

Checked errors, via results or exceptions have never been the problem. It has always been Java the language that hasn't provided the syntax sugar for handling checked errors effectively.

There is no difference between:

    A doIt() throws B
    fun doIt(): Result<A, B>

It all comes down to what the language lets you do once you encounter that error.

[tadfisher]

There is a huge difference: the first is an _exception_, which:

- Unwinds the stack to a try/catch or exception handler, making exceptions practically difficult to deal with in concurrent programming.

- If unchecked, can be ignored, silently propagating during stack unwinding.

- If checked, infects the call stack with 'throws' annotations.

The second is a normal return value, with no try/catch needed, handling the error case is mandatory in order to handle the success case, and there is not a separate execution regime occurring whenever an error case is encountered.

[vips7L]

I genuinely disagree. There is no difference between a checked exception and a Result.

- In concurrent programming uncaught exceptions won’t leave the future. Both values are available to you just like Results. I also don’t think arguments for concurrent programming are valid though. 99% of all code is single threaded.

- It is checked.

- Result infects the call stack as well.

- handling the error case with a checked exception is also mandatory with handling the success case. There is no separate “execution regime”. What is the difference here:

    val a = try {
        a();
    } catch (b) {
        onB();
    }
    
    val a = match (a()) {
        Success(a) => a
        Failure(b) => onB()
    }

[tadfisher]

The difference is you can just call

    val a = a();

And start the stack unwinding. The `try/catch` is not mandatory to call a().

[vips7L]

You definitely just don't know how checked exceptions work. This is not true at all. The compiler will not let you call a(); without handling the exception or checking it up the stack. The same way results work.

[billllll]

Is Rust praised for its checked errors? I've personally found it extremely verbose since there essentially is no possibility for unchecked errors.

Also, external crates like "anyhow" are required if you don't want to account for literally every single possible error case. Really seems like a pedantic's dream but a burden to everyone else.

Effective Java recommends checked exceptions only in the case where the caller may recover, but in practice you're usually just propagating the error to the caller in some form, so almost everything just becomes unchecked runtime exceptions.

[vips7L]

I'm only saying what I've seen here. I typically see praise for Rust's checked errors. Especially since they provide ? to panic and uncheck them. Personally I disagree with Bloch, if you are the thrower you can't possibly know if the caller can or cannot recover from your error so in my opinion its best to check it. If you are not the thrower and you can't recover from it I prefer to uncheck them, because if I can't recover my caller most likely can't either.

The issue really just arises with Java not giving you the capability to uncheck that error easily if you can't recover from it. For example, you need a ton of lines to uncheck:

    A doIt() throws B {
       throw new B();
    }

    void usingIt() {
       A a;
       try {
           a = doIt();
       } catch (B b) {
           throw new RuntimeException(b);
       }
       
       a.woohoo();
    }

My ideal situation would be for some sort of throws unchecked operator (or whatever syntax we want to bikeshed over) that turns them into unchecked exceptions.

    void usingIt() throws unchecked B {
        var a = doIt();
        a.woohoo();
    }

[ninetyninenine]

Have you heard of the language elm? The language elm is so safe that it is literally impossible to crash the program short of a memory error.

That's essentially the direction of modern programming languages. It's part of that feeling you get when programming haskell. Once you get it running, it just works. It's very different from the old paradigm where once you get it working, it can crash and you have to debug and do more to get it working better.

[ninetyninenine]

Looks like a huge difference to me. The first function throws an error. The second function may not even return an error.

[vips7L]

The first function may not return an error either.

[rizzaxc]

i find its biggest problem is its json ecosystem; very clunky and boilerplate-y