Earlier quoted context omitted.
It's not there yet, is it?
Pattern matching and exhaustive switch expressions are in preview.
Let's hope it comes soon then! But right now, I think Java can't be counted in.
Why Rust?
271–280 of 294 posts
Re: Why Rust?
#272As someone who's not the biggest fan of Rust because of its complexity. There is a big reason to use it today. If you need to use something that has safety guarantees where it's possible to achieve acceptable performance in certain classes of programs where languages like golang, nim or crystal have trouble achieving then I just don't see any other options out there certainly not one with as many libraries available…
IMHO the biggest reason for Rust is that developers NEVER get enough time to write perfect code. All this takes time and management usually doesn't grant you that allowance. In a perfect world where developers could tinker with the code until it's perfect we wouldn't need Rust. This is not that world.
Not even that. Because if your language isn't expressive enough, you can't make code perfect. Or rather, "perfect" in one language is than worse than "good" in another language.
Imagine big but perfect Assembly codebase against an okay-ish Rust codebase. Which one would you prefer to maintain?
Re: Why Rust?
#273Earlier quoted context omitted.
Except Emil is talking about "Java exceptions", not "Java runtime exceptions". Because Java's checked exceptions have the exact same good qualities that Rust's question mark operator offers.
Agreed, checked exceptions surface potential errors to the caller. In that regard Java fares better. However, handling exceptions still require a separate catch clause rather than being part of the normal flow. Furthermore, it is nigh impossible to rely on checked exceptions alone, most Java code may throw RuntimeExceptions such as NullPointerException or ArrayIndexOutOfBoundsException and there is no way to know it…
> However, handling exceptions still require a separate catch clause rather than being part of the normal flow
Only if you want to catch (handle) it. If you don't want to do that, just declare it in your "throws" clause and enjoy writing your code with the (guaranteed) assumption that you are using a valid value.
> Furthermore, it is nigh impossible to rely on checked exceptions alone, most Java code may throw RuntimeExceptions such as NullPointerException or ArrayIndexOutOfBoundsException and there is no way to know it by just looking at the calling code.
That's a bug, not a feature. These errors are often unrecoverable, hence why they are runtime and not checked.
Re: Why Rust?
#274Re: Why Rust?
#275Earlier quoted context omitted.
> It's a bubble, 99/100 crypto companies are going to crash and burn, or already have. I'm sure this is the 990th time that I have heard this. The fact is, it isn't going away and it seems even more crypto companies have taken interest in using Rust and that is good. Even some (crypto) companies are sponsoring the Rust Foundation as silver members. Nothing wrong with that. [0] [0] https://foundation.rust-lang.org/mem…
What are crypto companies doing that I should care about? Give me something I could go check out and use that is: (1) Not speculation, gambling, or some variation thereof. (2) Useful for something other than crypto itself. (3) Actually works and can be used today. (4) Continues to make sense even in a crypto bear market. (In other words: I will still buy milk even if the US dollar is falling because the point is the…
Arguably Brave.
Re: Why Rust?
#276Earlier quoted context omitted.
> 4) Dependency injection. Can you explain why DI needs an entire framework/libary? When I was taught DI in school, I was given the impression that DI was a $1000 term for a $5 concept in that without DI, you write code like this: class Foo(object): def __init__(self): self.bar = GetBar() whereas with DI, you write this: class Foo(object): def __init__(self, bar): self.bar = bar Obviously, I'm grossly misunderstandin…
What you say is dependency injection, but what people usually mean when they say a "dependency injection framework" is the bits of managing the creation of dependencies and getting them into the class's scope without having to add it as a parameter to every upper scope class's argument list.
Ah...
Do you know any good references for describing DI frameworks more? Because right now, my cynical take based on your description is that it's a TON of over-engineering and an absurd amount of complexity being added just to avoid a couple extra lines of code.
Re: Why Rust?
#277Earlier quoted context omitted.
I think you're failing to address the elephant in the room: The browser is simply the single best application distribution method humanity has ever created. Full stop. There are literally no other tools that give anywhere close to the same benefits. So 200kb of scripts might seem "HUGE!" to someone who's thinking about the web as a tool for distributing static information (blog distribution). But in the context of ap…
For blogs, sure, JavaScript is "fast enough". But in the context of applications , JavaScript is slow as dog shit . It takes "seconds" to open my spreadsheet? That is an absolutely deplorable regression. Personally, I'm fine with 200KB initial downloads, sure that's great and I don't mind repeating them. (But, also don't care about 50MB or even 500MB downloads that I only do once.) But for the browser to really becom…
> it needs to be capable of delivering software that executes efficiently or else it is regresssion to barbarism by a thousand cuts.
WebAssembly executes efficiently, it keeps its overhead within a small multiple of natively compiled binaries which is totally par for the course for any JIT-compiled intermediate code. You can write slow and inefficient code in any language, but Rust makes it a bit easier to do things the efficient way.
Re: Why Rust?
#278Earlier quoted context omitted.
For blogs, sure, JavaScript is "fast enough". But in the context of applications , JavaScript is slow as dog shit . It takes "seconds" to open my spreadsheet? That is an absolutely deplorable regression. Personally, I'm fine with 200KB initial downloads, sure that's great and I don't mind repeating them. (But, also don't care about 50MB or even 500MB downloads that I only do once.) But for the browser to really becom…
> it needs to be capable of delivering software that executes efficiently or else it is regresssion to barbarism by a thousand cuts. WebAssembly executes efficiently, it keeps its overhead within a small multiple of natively compiled binaries which is totally par for the course for any JIT-compiled intermediate code. You can write slow and inefficient code in any language, but Rust makes it a bit easier to do things…
Yeah, that's why I remain optimistic about the browser's future. My ranting was mainly about JavaScript itself.
We are already seeing real world web apps using WASM. (What I have seen is indeed mostly Rust, but in theory there are lots of other languages that can already, or will be able to, play in that same sandbox.)
The other fun thing about WASM is that there are already a bunch of ways to run it on the server (including "at the edge"). That makes it really easy to chop apps up into pieces that run in the browser, or run elsewhere.
Re: Why Rust?
#279> Safety and speed One thing I can't seem to find a quick answer to from the Rust crowed is how does Rust handle dynamic lifetimes? It seems like it does not; it simply prevents you from referring to objects that have a dynamic lifetime not known at compile time. You either have to use 'unsafe' or use the 'handles' pattern where you have what amounts to a custom allocator but the compiler does not know that it's an a…
Yes, your options are unsafety, garbage collection (in the broad sense, which includes Rc), and hiding lifetimes from the compiler via "handles" or similar. Can you even imagine other options, though? If enough information about the lifetimes isn't known at compile time, how can the compiler prove it safe?
It's very rare that a serious problem can be solved without some objects having some sort of a dynamic lifetime that you have to manage.
Rust just prevents you from doing this. So you can say it provides safety, but it also restricts you from solving the vast majority of serious problems that we write programs to solve.
This is very different from static vs dynamic typing.
In a statically typed language, the compiler actually _knows_ what you can and can't do with each object.
Where as Rust's life time management just says "Nope, I have no idea whether what you are doing is safe or not so I'm just going to tell you you can't do it".
Re: Why Rust?
#280Earlier quoted context omitted.
The enum example in the article
OK, that's an interesting language feature, but I can't say it's something that I've often wanted to do in C++. Of course C++ does have std::variant and std::any, although I'm not really a fan. I'd tend to (and have) just use a class that contains the variants and an enum to track which one, then setters and getters. event.SetKeyPress(ch); event.SetMouseButtonPress(pos, but); etc ... switch (event.type) { case EvKeyP…
Of course the Rust features being used by that Event type are runtime polymorphism and type introspection, so another obvious C++ approach would be just to use a pointer to a virtual based class including the type, then:
switch (event->type) {
case EvKeyPressEvent:
{
auto kpe - dynamic_cast(event)
...
}
break;
}