Nice.

For going the other way, rust to ts, we have ts-rs. https://github.com/Aleph-Alpha/ts-rs

tc39’s proposal for private fields in JavaScript has some interesting design discussion. https://github.com/tc39/proposal-class-fields/blob/main/PRIVATE_SYNTAX_FAQ.md

Nom is nice for simple formats and could be used for a hobby language. But I wouldn’t use it to parse a real programming language.

If you like nom, I would strongly consider winnow, which was originally forked from nom by the toml crate maintainer. See why winnow? for a comparison of priorities. It also discusses a few things to consider before deciding on how you’ll write your parser.

Not the parent poster. I knew what you meant. But I’m guessing the confusion is because in JS, “number” refers to a type. What you mean is it only works for numeric literals. A literal is the syntactic construct like 3.14, “hello”, or true. Literals do not include identifiers that may resolve to numbers at runtime. An example contrasting what it would not change might also help.

implicit multiplication

5(1 + y) => 5 * (1 + y)

function call

x(1 + y) => x(1 + y)

Can you post the YouTube video link?

It’s more for making the server, but check out https://github.com/ebkalderon/tower-lsp Be aware, it’s unmaintained and some people are in the process of forking it here: https://github.com/tower-lsp/tower-lsp

Sorry, but in 2023, I can’t support something that’s written in PHP. https://codeberg.org/Kbin/kbin-core

Yup. This is the situation I’m in. I rewrote a few simple things in Rust as a proof of concept and eventually convinced our CTO to adopt Rust. Fast-forward, and now we have more lines of Rust code than Python!

We spent a long time trying to hire. There aren’t enough senior Rust developers to run all these new Rust projects, so if you’re one of them, the market is in your favor.

Here is the original link: https://www.codewithjason.com/snail-mail-newsletter/

I suspect the post was deleted because it didn't get enough upvotes for the creator's liking.

Can you expand on why this is? Or do you know of a thread or article that explains the complications?

This is why I use the clippy lint str_to_string which enforces the use of to_owned() on &str. This way, if you see to_string(), it’s clear that it’s a conversion from another type.

https://rust-lang.github.io/rust-clippy/master/#str_to_string

With Rc/Arc, there’s already precedent for using a separate type. So what about a hybrid approach? You have a separate public type so that users can easily control it. But a trait to abstract over the interior mutability type is used internally to prevent code duplication. The public types are essentially aliases with the generic parameter filled in.

In Ruby, return always returns from the enclosing method. It works this way so that you can create, for example, a method that abstracts over opening a file by opening the file, executing a block with the file as its argument, and then ensuring that the file is closed.

If return didn’t work this way, then if you organically factored out the file opening and closing parts, any returns in the center that got moved into the block would be broken.

If you only want to jump to the end of the block, that’s what break does. This allows you to implement your own for-each or other iteration methods. They don’t need to be special built-ins.

In Ruby, methods and blocks have different syntax, so it’s always clear which to use. It’s similar to the way Rust has fn foo() {} and || {}.

Unfortunately, having return behave this way would be a breaking change for Rust. It would have to come up with another solution.

I really miss Ruby blocks in other languages because of this. In Ruby, using break, next, and return work just as you'd expect, without breaking the abstraction that the higher-order function creates.

In Rust, I oftentimes need to use a match or if let instead of map(), unwrap_or_else(), or other functions so that I can do an early return of a Result, for example. It feels like an arbitrary limitation that forces me into one style for no good reason.

Check out Shen. It's based on sequent calculus. I've seen examples in it or its predecessor of a prime number type. If you're at all familiar with type theory, derivation rules are basically valid syntax, and it has a Prolog-esque solver.

This reminds me of Niko Matsakis’s interesting post What it feels like when Rust saves your bacon. In the moment, it can feel frustrating because it’s preventing you from doing something. But in actuality, it’s saving you from making a big mistake and causing yourself lots of pain down the road.

What if there are multiple paths from A to C? How does it choose which type to convert through?

In my opinion, most ideas in this thread have it backwards, at least in the short-term. It won’t allow people to write natural language specs that AI converts to code; it will allow us to write code that AI converts to natural language. AIs like ChatGPT are bad at logic, but they’re good at fuzzy things like writing an email that another human will consume.

In the short-term, AI is good at explaining what a line or small chunk of code does. So it could autogenerate comments or generate them on-demand when not present in the original.

Many developers think reading code is harder than writing code. The editor could convert source code into literate code, assisting with reading other people’s code. Similar to how browsers have a reader mode for websites, your editor could have a reader mode for code, filling in documentation when it isn’t present, adding context for people new to the codebase, and linking to relevant reference material. It will always be up to date and never get out of sync with the code.

As you’re writing code, AI can help name variables, functions, etc., which has been claimed to be one of the hardest problems in the field: naming things.

AI will affect collaboration workflows. CONTRIBUTING.md files will start to say to make pull requests small enough that the AI can accurately summarize your change in 100 words or less. That will be done automatically, of course, when you create the pull request. Instead of it coming down to one or two maintainers’ judgment about whether a piece of code is comprehensible (i.e. not code golf), especially for distributed open source projects, the judgment could be left to whether the AI can accurately explain it, which can be one of the checks that must be passed before merging.

Do you think its worthwhole to fully invest time into rust, and that the market will value it in the following years?

Yes. Be the Rust champion and convince your employer, ideally whoever is in charge of making technical decisions, of Rust's value. Use actual data from the context that's relevant to them.

For example, if they're concerned about security, share links about security. If they're concerned about performance, share material about performance and make proof-of-concept comparisons from actual problems you're hitting at your company.

Don't be annoying about it, but also don't give up. Part of the problem of people adopting new technology is not being familiar with it. As time goes on and they keep hearing about it, people are more likely to warm up to it, especially if it's in the context of something else they value.

As other comments have said, it's a long-term investment that can take years to pay off. By then, not only will you be a Rust expert, but all your peers will see you that way and think of you when they encounter a Rust opportunity.

When you truly love something, a minute with it is never wasted.

lalrpop is great. It's a completely different approach from nom, but for parsing a programming language, I would at least consider it. RustPython uses it.

Unstructured concurrency.

See Notes on structured concurrency, or: Go statement considered harmful for a great explanation of why. But the tl;dr is that any feature that allows running a function concurrently with the caller breaks the function abstraction, making it no longer possible to (easily) reason about code. Removing unstructured concurrency makes it possible to add lots of interesting features. Scoped threads are a way to make concurrency structured that doesn't break the function abstraction.

Except for max_width. It has the wrong default for viewing files side-by-side, especially with inlay hints showing inferred types inline, which makes the effective width of each line both variable and much longer than the max line width in the file.

I understand perfectly why the problem exists, and I understand the workarounds. But they're unsatisfactory to me and others. See the linked issue.

Also, I fixed the link to a blog post by Niko Matsakis this past November discussing a potential way to fix the problem using view types. It's recognized as a legitimate problem and being researched.

Factoring out a function isn't the same as inlining the body of the function. When you borrow self, you borrow the entire self; it's currently not possible to borrow only a part of it, like a single field, for example. On the other hand, when you inline the same code by copying and pasting, the compiler can see exactly what was borrowed. This was one of the most disappointing things I learned about Rust the language. I sometimes find myself making a macro to work around the issue.

See: https://github.com/rust-lang/rfcs/issues/1215 See also: https://smallcultfollowing.com/babysteps//blog/2021/11/05/view-types/

The Discord server is here: https://discord.gg/B9Z7ShCQBu We're working on it. Join if you have any interest in helping.