Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust 1.45

blog.rust-lang.org

Post reply on HN
Print view View original

171–180 of 227 posts

Re: Rust 1.45

#171

Post by kibwen »

SiVal wrote: post #169
kibwen wrote: post #87

Earlier quoted context omitted.

> Why not? For better or worse, Rust 1.0 released with the philosophy that the `as` operator is for "fast and loose" conversions where accuracy is not prioritized; e.g. casting a u32 to a u8 would always risk silently truncating in the event the value was too large to represent. Over the years the language has added a lot of standard library support for bypassing the `as` operator entirely, and I think the prevailing…

It seems to me (FWIW as someone curious abt Rust but not seriously using it yet), that "as" should require a warning label. If "unsafe" means something else, then "unsound" could be used. If the types are always safe to convert, "as" is fine, but if the types involved allow for a lossy conversion in any case, the compiler would require you to write "unsound as". You are both acknowledging that you are aware of the is…

"unsound" has a particular definition that is separate from what people have issue with here; in Rust parlance, there's nothing unsound about the `as` operator choosing to saturate or overflow etc., because that has no ability to break the guarantees provided by the type system.

As for requiring an additional speedbump (like e.g. a "lossy" label) here to guard against misuse, I think this proposal is overlooking something: Rust can't just abruptly break all code that currently uses `as` in order to demand that something like `lossy as` be used instead. Any removal would have to first have a very long period where `lossy as` is syntactically valid and where the compiler instead warns for people using raw `as`. But if the compiler is already emitting a mere warning for `as` that suggests a better alternative, then it could just as easily suggest a method like `.try_into()`, which exists today. And once you're having the compiler warn about changing `as` into something else, that's already indistinguishable from deprecating `as` in those instances, so there's no point trying to avoid it.

Re: Rust 1.45

#172

Post by proverbialbunny »

mas3god wrote: post #45
person_of_color wrote: post #13

Any algo-trading backtest frameworks in Rust?

All you need for algotrading is to query an api. Rust would be a poor choice for that anyways, like using a semi truck to carry your bike around.

>All you need for algotrading is to query an api. Rust would be a poor choice for that anyways, like using a semi truck to carry your bike around.

That's not really true. It's more pulling from a database or csvs as backtesting is the most important part, which is also why the person you were replying to was asking about backtesting specifically.

Most firms roll out their own programming language, because before Rust existed there wasn't really a language that was a good choice for algo trading. Algo trading needs a few things:

1) It needs a financial number data type. That is, base 10 precision. Floats and doubles will not cut it when dealing with money.

2) The language needs to not implicitly do type conversions, so your types do not accidentally get converted to doubles.

3) You want provability. That is, you want guarantees that your program will run exactly the way you intended or you could lose a lot of money.

4) You hopefully want it to go fast, or backtesting could take ages. Historically super computers have been preferred, but that is probably not the case today. (This isn't even for HFT, just scalping and swing trading.)

Most in house languages in the industry are functional programming paradigm, because it allows guarantees. What you see is what you get. It allows one to write in a more mathematical way.

Today Rust takes the cake, as it is the only mainstream language that meets all the criteria, despite not being a functional programming paradigm language.

Re: Rust 1.45

#173

Post by sjwright »

frabert wrote: post #124
sjwright wrote: post #65

Earlier quoted context omitted.

Why would you want math errors to be less obnoxious?

They're not math errors, it's the most sensible thing to do: when you overload a speaker, you get clipping, not some weird thing where the cone snaps to the opposite side of the range.

I’m talking about the basis of the analogy, not the analogy. If you’re processing audio signals, saturation (i.e. clipping) is of course preferable to the alternative.

Re: Rust 1.45

#174

Post by kibwen »

JeromeLon wrote: post #148
cuddlybacon wrote: post #146

As someone who hasn't used Rust, I am curious about why Rust has macros. I use C++ at work, which admittedly isn't the language I use most, and macros are used quite a bit in the code base. I find they just make the code harder to read, reason about, debug, and sometimes even write. I don't see them really living up to their claimed value. Is there something different about Rust's macros that make them better?

There is almost no intersection between the kind of things that can be done with the C++ macro system and the kind of things that can be done with the Rust macro system. They are not related. You can see them as another feature that is not available from C++.

Indeed, Rust macros are a descendant of Scheme macros, not of C macros.

Re: Rust 1.45

#175

Post by ReactiveJelly »

wtetzner wrote: post #88
ldng wrote: post #35

Earlier quoted context omitted.

IMHO, it's a shame So Much time has been spent (~3 years ?) on async at the cost of basic features like multipart and CORS. But I understand it could be more fun for the devs :-)

I think it makes sense to get your foundation and ergonomics correct before piling on features. Otherwise you end up building features that may need to be completely restructured/redone later.

I recently switched from old sync versions of hyper and postgres to the new async versions. [1]

It wasn't hard, but yeah it was not fun either.

I can only imagine it's worse if you're actually writing the libraries and not just a CRUD app like I am

[1] Apparently the postgres crate was a wrapper around tokio_postgres all along and I didn't notice. So to remove a dependency I switched to using tokio_postgres directly

Re: Rust 1.45

#176

Post by CBLT »

laszlokorte wrote: post #150
laszlokorte wrote: post #94

Earlier quoted context omitted.

It should be `assert!(len(arr) >= 255)` (greater instead of less than), right?

actually >, not >=

len(arr) == 255 should be okay, 0..255 doesn't include the end index[0]. In the Rust playground[1] I see it only print up to 254.

[0] https://doc.rust-lang.org/stable/rust-by-example/flow_contro... [1] https://play.rust-lang.org/?version=stable&mode=debug&editio...

Re: Rust 1.45

#177

Post by ReactiveJelly »

rgrs wrote: post #67
adamnemecek wrote: post #31

If you have been on the fence about learning Rust, I encourage you to dive in. It is very productive.

How is the build system? Is it stable and easy?

Here are the problems I've had with other build systems, as a noob, that I have not had with Cargo:

- Having to learn weird syntax and constantly look up the reference manual (CMake) - Having to manually add source files (qmake) - Sometimes it just needs a clean and nobody knows why (Visual Studio) - Having to remember to set up debug and release builds and decide your directory layout for everything and figure out what 'a shadow build' is and who gives a crap since it all takes too much HDD space either way (qmake, CMake, make)

Also having tests built-in is really nice. Rust is the only language where I bother writing tests. Everything else makes it too hard, as if entry points into your binary are supposed to be rare and expensive.

Re: Rust 1.45

#178

Post by dilap »

estebank wrote: post #136
dilap wrote: post #125

Earlier quoted context omitted.

Do you have examples of this? I'd be curious to know if so. (I've played w/ Rust a little bit -- I implemented a Boggle board scorer + high-scoring board generator; Rust outperformed my C++ code! I was impressed.)

One example of the choice you have is how you can deal with generic data types: fn foo (_: T){} fn foo(_: impl Trait) {} fn foo(_: &Trait) {} These three different fn definitions have two different behaviors and affect both the speed of the code and the speed of compilation and it depends entirely on how they are called. The first one is what the language calls generics: they are always monomorphized, which means tha…

Thanks!

The monomorphization-vs-dynamic dispatch thing feels natural from a C++ perspective, as it completely mirrors the choice of achieving 'polymorphism' via templates or virtual methods (though of course the Rust syntax is way nicer!, using traits for both, whereas in C++ you have either a class definition or...nothing, just ungodly compile errors ("compile-time dynamic typing")).

That's interesting re Swift. It seems similar in a way to using heuristics to decide whether to inline a function or not.

I _think_ C# does monomorphization for value types ("struct") and vtables for reference types ("class"), though I wouldn't bet on it...

> fn it() -> impl Iterator {

One of the things that impressed me w/ rust was being able to write really concise code using ".map()" and friends and finding that it all ended up running just as fast as raw loops.

(The thing that has most impressed me about rust was the crossbeam crate + type system + derive stuff, which let me parallelize board search in an incredibly easy fashion. I found it much nicer to work w/ than Go channels, which is supposedly one of Go's big tricks!)

Re: Rust 1.45

#179

Post by jeffparsons »

The_rationalist wrote: post #135
neilsense wrote: post #33

Earlier quoted context omitted.

That's not how versions work

>= 1.0 in semantic versioning universally means that it should be "stable enough"

I think you're missing the point of contention.

> [...] it's not even 1.0 yet. Thus, it isn't stable enough for production use.

API stability (i.e. how the API will change in future) is largely unrelated to the question of whether you can trust it to work in production.

Maybe for some people API stability is a "must have" for production use, for the sake of minimizing churn when upgrading dependencies, but that's far from a universal principal.

I think people often get confused about different meanings of "stable". I've worked with plenty of libraries with stable APIs that are buggy piles of hacks. And I've worked with plenty of libraries with unstable APIs that are rock-solid in production. They're different concerns, but people seem to conflate them a lot.

So, to clarify, any statement like "not even 1.0 [...] isn't stable enough for production use", made without qualification, is a non sequitur.

Re: Rust 1.45

#180

Post by kibwen »

cuddlybacon wrote: post #164
1ris wrote: post #149

Earlier quoted context omitted.

Writing macros (in any language) is a way of creating an abstraction. Creating abstractions is a way of automating the job of programming, making it ideally more efficient and less error prone. This is why people usually prefer java to basic. Marcos are a way of creating abstractions that are particular suited to be "concreted" by the compiler, making them a ideal match for programming languages that seek to be "clos…

> C Macros are lacking because they are very primitive, e.g. they have not type system. They are also hardly turing complete. Its extremely hard to write a meaningful algorithm in them. I think this may be why I'm having a hard time appreciating them. Probably half the macros I see could just be a function call. The majority of those that don't are hiding a conditional return or goto, which I find to be a net negativ…

> Probably half the macros I see could just be a function call.

Yes, that particular breed of C macros would likely manifest in Rust as people just defining a new function. In Rust, you tend to see macros in places where "just make a new function" doesn't suffice for whatever reason; for example, maybe you need to define a dozen different structs that only differ by the type of one field, so instead of actually defining the struct a dozen times, you could just define the struct inside the macro and then `define_my_struct!(u8); define_my_struct!(u16);` and so on.

You also can't use Rust macros to "redefine" other unrelated pieces of code, so that's one less thing to worry about.

Post reply on HN