Live data from Hacker News

Thoughts on what a next Rust compiler would do

matklad.github.io

11–20 of 147 posts

Re: Thoughts on what a next Rust compiler would do

#11
post #7
post #4

I say this with great respect, but the thing keeping me from Rust isn't the compiler, it's the language.

What about the language do you dislike? It's a strongly typed Ruby with generics. Edit: trait-based OO is a breath of fresh air compared to tree-style class inheritance. Super flexible without having to overthink. Immutable by default is reassuring, Option/Result are fantastic null/exception replacements. Enums and match blocks are powerful and gracefully help ensure handling of all cases, have nice syntax, and work…

The borrow checker. The syntax. It isn't a good fit for my needs. It'd be like using a forklift to move a few books. I'm not generally a fan of strong explicit typing/high ceremony in general.

Re: Thoughts on what a next Rust compiler would do

#12
post #7
post #4

I say this with great respect, but the thing keeping me from Rust isn't the compiler, it's the language.

What about the language do you dislike? It's a strongly typed Ruby with generics. Edit: trait-based OO is a breath of fresh air compared to tree-style class inheritance. Super flexible without having to overthink. Immutable by default is reassuring, Option/Result are fantastic null/exception replacements. Enums and match blocks are powerful and gracefully help ensure handling of all cases, have nice syntax, and work…

It's probably not the language syntax per se, but satisfying the compiler (borrow checker) can be tedious for beginners.

Re: Thoughts on what a next Rust compiler would do

#13
post #11
post #7

Earlier quoted context omitted.

What about the language do you dislike? It's a strongly typed Ruby with generics. Edit: trait-based OO is a breath of fresh air compared to tree-style class inheritance. Super flexible without having to overthink. Immutable by default is reassuring, Option/Result are fantastic null/exception replacements. Enums and match blocks are powerful and gracefully help ensure handling of all cases, have nice syntax, and work…

The borrow checker. The syntax. It isn't a good fit for my needs. It'd be like using a forklift to move a few books. I'm not generally a fan of strong explicit typing/high ceremony in general.

Curious, are you a fan of Typescript?

Re: Thoughts on what a next Rust compiler would do

#14
post #11

Earlier quoted context omitted.

The borrow checker. The syntax. It isn't a good fit for my needs. It'd be like using a forklift to move a few books. I'm not generally a fan of strong explicit typing/high ceremony in general.

Curious, are you a fan of Typescript?

Never used it. I don't even have the need to touch vanilla javascript that often.

Re: Thoughts on what a next Rust compiler would do

#15
post #4

I say this with great respect, but the thing keeping me from Rust isn't the compiler, it's the language.

Once you're done fighting with the compiler (Rust Analyzer), it's actually very enjoyable and one can be _relatively_ productive. The language allows so much flexibility that it's very easy to produce well organized code...

But the compiler is really slow. Even an incremental build on a mid size project is never below 10s, whereas on a similar size project, Golang will take me less than 1 second to build incrementally. Also, I find cross-compilation (from/to major platforms) really challenging on Rust, as opposed to Golang where it's for my use cases super straightforward

Re: Thoughts on what a next Rust compiler would do

#16
post #7
post #4

I say this with great respect, but the thing keeping me from Rust isn't the compiler, it's the language.

What about the language do you dislike? It's a strongly typed Ruby with generics. Edit: trait-based OO is a breath of fresh air compared to tree-style class inheritance. Super flexible without having to overthink. Immutable by default is reassuring, Option/Result are fantastic null/exception replacements. Enums and match blocks are powerful and gracefully help ensure handling of all cases, have nice syntax, and work…

Not OP but for me it's the syntax. I'm not even saying it's bad or could even be improved... I just don't find it intuitive. I've only sat down and walked through some of the learn rust book and tried to hack out a few small things.

I'm not sure what it is - there just always seem to be random symbols that dont seem to follow conventions of other languages. Guess I am use to C-style (including C++, C#, JS) syntax and python. Its possible that there are just new concepts that aren't really represented in the languages I use too.

Again, I don't necessarily think its bad. Just what I don't find intuitive.

Re: Thoughts on what a next Rust compiler would do

#17
post #4

I say this with great respect, but the thing keeping me from Rust isn't the compiler, it's the language.

Once you're done fighting with the compiler (Rust Analyzer), it's actually very enjoyable and one can be _relatively_ productive. The language allows so much flexibility that it's very easy to produce well organized code... But the compiler is really slow. Even an incremental build on a mid size project is never below 10s, whereas on a similar size project, Golang will take me less than 1 second to build incrementall…

My personal issue with Rust isn't the borrow checker. I actually find it quite intuitive. What I don't like is the extreme complexity of everything. There's just so much... stuff.

What I want is a Rust, but with almost everything stripped away. Complexity similar to Go.

Re: Thoughts on what a next Rust compiler would do

#18
post #7
post #4

I say this with great respect, but the thing keeping me from Rust isn't the compiler, it's the language.

What about the language do you dislike? It's a strongly typed Ruby with generics. Edit: trait-based OO is a breath of fresh air compared to tree-style class inheritance. Super flexible without having to overthink. Immutable by default is reassuring, Option/Result are fantastic null/exception replacements. Enums and match blocks are powerful and gracefully help ensure handling of all cases, have nice syntax, and work…

In real world software, you need lots of freedom in order to design high performance scalable systems. This includes using non-trivial data structures, and being able to access and organise memory in subtle ways. The Linux kernel is an example of this. Look at the reclaim subsystem in the kernel, for instance, and how it interacts in subtle and very complex ways with various other subsystems, the page cache, the generic block layer, the memory control groups, the VFS and the filesystems. All of them are multi-threaded and run on complex high performance CPUs performing memory re-ordering, speculative execution, branch perdiction and parallel execution of both processes and instructions. You really need extremely smart smart data structures and organisation and very smart algorithms to manage the concurrency. C is a language where you have all that freedom to do whatever you want leading to high performance and low latency. In Rust, you can't even safely implement a doubly linked list. Now, if you have to use unsafe every time you need high performance or scalable data structures, then Rust is as unsafe as C and it's just making your life harder for no reason, except hype.

Re: Thoughts on what a next Rust compiler would do

#19
post #11
post #7

Earlier quoted context omitted.

What about the language do you dislike? It's a strongly typed Ruby with generics. Edit: trait-based OO is a breath of fresh air compared to tree-style class inheritance. Super flexible without having to overthink. Immutable by default is reassuring, Option/Result are fantastic null/exception replacements. Enums and match blocks are powerful and gracefully help ensure handling of all cases, have nice syntax, and work…

The borrow checker. The syntax. It isn't a good fit for my needs. It'd be like using a forklift to move a few books. I'm not generally a fan of strong explicit typing/high ceremony in general.

> strong explicit typing/high ceremony

If you think strong typing is "ceremony" then you probably spend most of your time writing (and documenting) code and not reading, refactoring, or collaborating on it.

The time people spend writing unnecessary, buggy unit tests (that static analysis can do in better languages) is far greater than the time to just use the type system.

Most languages don't even force you to be explicit anymore. They infer the types, so you don't even write extra code. You just get better errors and speed.

Re: Thoughts on what a next Rust compiler would do

#20
post #4

I say this with great respect, but the thing keeping me from Rust isn't the compiler, it's the language.

It's the standard library & tooling for me. To be perfectly honest for must stuff I use rust for I'd prefer to have garbage collection. But the standard library and tooling I just too far ahead of the competition (diplomatically avoiding naming languages here)
Post reply on HN