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

Rust – A hard decision pays off

pinecone.io

Post reply on HN
Print view View original

351–360 of 386 posts

Re: Rust – A hard decision pays off

#351

Post by rjh29 »

rowanG077 wrote: post #347
rjh29 wrote: post #270

Earlier quoted context omitted.

Having recently used it, my impression is Python's type system is pretty damn powerful. It might not be as crazy as TypeScript, but it can handle recursive types, dictionaries with a fixed set of keys, functions, union types and generics. Types can be re-used or exported. There are generic types for things like 'Iterable'. If a package does not supply its own types (increasingly rare now), you can generate stubs and…

Does it support annotating numpy arrays with their dimensions yet? Last time I checked I was incredibly surprised the status quo was basically all numpy arrays are np.ndarray.

I think so:

https://numpy.org/devdocs/reference/typing.html

Which is cool, even strongly typed languages don't usually support that.

Re: Rust – A hard decision pays off

#352

Post by rjh29 »

linsomniac wrote: post #311
tlrobinson wrote: post #234

Earlier quoted context omitted.

> I find that static typing means I can be more productive, because type errors are caught straight away I agree completely. I feel like there’s a pretty common arc among programmers: 1. learn to program using verbose statically typed languages 2. discover fun dynamically typed languages, eschew statically typed languages 3. discover dynamically typed languages are a shitshow for large real-world projects 4. re-disco…

The thing I like about Python is that I can decide, even on a line-by-line basis, but more likely on a program by program basis, if it makes sense to be type oblivious, or type checked.

Exactly. For one-off scripts or code you might throw away, there is nothing wrong with skipping the types.

Re: Rust – A hard decision pays off

#353

Post by elcritch »

formerly_proven wrote: post #346
elcritch wrote: post #335

Earlier quoted context omitted.

If you like doing compile time things with types like typescript enables then Nim is fantastic. I've been learning Rust recently and I'm continually disappointed with how little compile time or type based stuff you can do.

With prior C++ experience it's easy to equate C++ templates and Rust generics (similar syntax - usually does similar things - quack like ducks etc.); I know I did. And through this lens generics will soon seem very limited compared to templates. But the underlying reason for this is because C++ templates aren't generics - they're much closer semantically to hygienic, declarative macros. C++ templates are based around…

Yah the type level programming in Rust really is limited to traits which provide little compile time functionality. It's pretty straight jacketed which is nice in some ways as you wont have un-anticipated interactions with user types. On the downside that limits un-anticipated usage of libraries or types.

Even macro_rules! aren't as capable as modern C++ templates with types. I am let down with how lacking Rust is when doing compile time type based programming. There's no CTTI or RTTI in Rust. The procedural macros don't have access to type information, just syntax. The constexpr equivalents are so limited, etc.

Re: Rust – A hard decision pays off

#354

Post by Thaxll »

throwaway234566 wrote: post #319
Thaxll wrote: post #203

Earlier quoted context omitted.

Rust std lib is subpar compared to the Go one, yes you have iterators but that's it, basic things like async are not even provided just the interface so everyone has to use tokyo. Then for real use cases you're missing http/json/compression/crypto etc ... https://pkg.go.dev/std Overall tooling and std lib are better on Go, actually there are not many languages that are on part with Go to that regard. When you see wha…

Agreed 100%. Go doesn't have a standard library problem, it has a userland language problem. * No sum types / algebraic data types in 2022. * No exhaustive pattern matching in 2022 * No move semantics / Uses GC * No borrow checker * Still suffers from nil problem / No type-safe nil / No type-safe Optionals in 2022 -- (I can show you all the nil panics in kubernetes logs if you like) Current go users are already sold…

And yet Go has delivered very useful software used by millions of people.

Re: Rust – A hard decision pays off

#355

Post by CharlieDigital »

throwaway894345 wrote: post #266
sharno wrote: post #207

Earlier quoted context omitted.

I'd argue that C# (dotnet core) is a much better option than Go for an easy GC language with max productivity and great performance ceiling.

I haven't worked with C# since ~2013, but I mostly liked it. I'm sure it's a different beast now though. Some things I prefer about Go: 1. Tooling. `go build` just needs a `go.mod` file with a list of dependencies. There's no MSBUILD stuff (I think dotnet had a similar JSON file format, but then went back to MSBUILD?) 2. Runtime. I love that Go's default is static, native binaries, and that the ecosystem revolves aro…

1. `dotnet build` requires a .csproj file. It's XML based (they tried a JSON based format a few years back, but reverted to XML).

C# and .NET's main strength, IMO, is the web API framework and general purpose utility; everything from web apps to Unity and Godot. It's easy to start with `dotnet new webapi -minimal` will give you a scaffolded project which is pretty similar a barebones Express or Flask app. But you get much more headway and scalability and the room to layer more complexity as needed.

It's main detriment is, as you mentioned, the need for a somewhat heavy runtime and the relatively slow cold starts which make it a poor choice for things like CLI tools and serverless functions.

Re: Rust – A hard decision pays off

#356

Post by rowanG077 »

krab wrote: post #350
rowanG077 wrote: post #348

Earlier quoted context omitted.

While the big one for rust borrowing system is memory bugs it als make it extremely specific what can be mutated. And there can only be a single mutator at any time. Unless you explicitly write something to work for multiple mutators. This makes many logic bugs much more obvious even though you could still make them. And of course you don't have nullability which is another big one.

Due to the pain that concurrency is in Python, the codebases I've seen mostly shared data only via external processes (queues, databases). I was very surprised to read the article. I think in the code I have in mind the borrow checker would only add overhead. The most frequent errors I see in the Python webapp code are: 1. logic errors, especially around concurrent DB transactions, 2. type errors (missing values, imp…

It's not only threads. It's also explicit in whether a function can modify an argument because it's type signature says this with the mut keyword.

Re: Rust – A hard decision pays off

#357

Post by rowanG077 »

rjh29 wrote: post #351
rowanG077 wrote: post #347

Earlier quoted context omitted.

Does it support annotating numpy arrays with their dimensions yet? Last time I checked I was incredibly surprised the status quo was basically all numpy arrays are np.ndarray.

I think so: https://numpy.org/devdocs/reference/typing.html Which is cool, even strongly typed languages don't usually support that.

There is no example there that show that. I mean something like np.ndarray[1024, 1024, 1024, type=Int] which would mean a 3D array where each dimensions has 1024 elements. Basically all statically typed language support it. Even in C you can do it.

Re: Rust – A hard decision pays off

#358

Post by formerly_proven »

elcritch wrote: post #353
formerly_proven wrote: post #346

Earlier quoted context omitted.

With prior C++ experience it's easy to equate C++ templates and Rust generics (similar syntax - usually does similar things - quack like ducks etc.); I know I did. And through this lens generics will soon seem very limited compared to templates. But the underlying reason for this is because C++ templates aren't generics - they're much closer semantically to hygienic, declarative macros. C++ templates are based around…

Yah the type level programming in Rust really is limited to traits which provide little compile time functionality. It's pretty straight jacketed which is nice in some ways as you wont have un-anticipated interactions with user types. On the downside that limits un-anticipated usage of libraries or types. Even macro_rules! aren't as capable as modern C++ templates with types. I am let down with how lacking Rust is wh…

Yep, true. Stuff like Zig's famous MultiArrayList, where you write pretty simple Zig code to take apart and reify types and functions just doesn't seem to be much of a thing for Rust by design. Procedural macros also have build time issues, because the macro must be fully compiled before any code using it can be compiled (hence why they must be put in a separate crate), and as I understand it procedural macros only get TokenStreams, so if they want to work with Rust code, they must re-create the AST from tokens with their own parser. Unfortunately, derive macros also happen to be procedural and subject to those limitations, handy as they may be.

What I really like about Rust generics on the other hand is that, while limited in many ways, those limitations allow them to be complete in the sense that as far as types concerned, the generic signature is the law of the land; it'll compile with any type fulfilling the trait bounds, and the implementation behind the signature is fully limited to exactly what's provided by the trait bounds.

Re: Rust – A hard decision pays off

#359

Post by krab »

rowanG077 wrote: post #356
krab wrote: post #350

Earlier quoted context omitted.

Due to the pain that concurrency is in Python, the codebases I've seen mostly shared data only via external processes (queues, databases). I was very surprised to read the article. I think in the code I have in mind the borrow checker would only add overhead. The most frequent errors I see in the Python webapp code are: 1. logic errors, especially around concurrent DB transactions, 2. type errors (missing values, imp…

It's not only threads. It's also explicit in whether a function can modify an argument because it's type signature says this with the mut keyword.

You're right. It just doesn't seem to create much issues in the application code I have experience with.

Re: Rust – A hard decision pays off

#360

Post by throwaway894345 »

throwaway234566 wrote: post #319
Thaxll wrote: post #203

Earlier quoted context omitted.

Rust std lib is subpar compared to the Go one, yes you have iterators but that's it, basic things like async are not even provided just the interface so everyone has to use tokyo. Then for real use cases you're missing http/json/compression/crypto etc ... https://pkg.go.dev/std Overall tooling and std lib are better on Go, actually there are not many languages that are on part with Go to that regard. When you see wha…

Agreed 100%. Go doesn't have a standard library problem, it has a userland language problem. * No sum types / algebraic data types in 2022. * No exhaustive pattern matching in 2022 * No move semantics / Uses GC * No borrow checker * Still suffers from nil problem / No type-safe nil / No type-safe Optionals in 2022 -- (I can show you all the nil panics in kubernetes logs if you like) Current go users are already sold…

I don’t mind GC. I think it’s the right choice for the sort of applications Go targets. I wish it had algebraic data types (with exhaustive pattern matching), but the “in 2022” meme is just vapid snark.

Notably, despite its shortcomings, Go is still perhaps the most productive programming language for general purpose applications. It turns out that type system features are neat, but tooling, ecosystem, simplicity, etc outrank type system features by quite a lot. Rust does very well here too, but it’s choice of borrow checker over GC amounts to trading off a lot of productivity in the general case (but it makes sense for Rust’s goals!).

Post reply on HN