super_flanker

What is "linting efficiency", never heard of this term before?

> long before LLMs

I thought this thread was about an ideal language for LLMs, no?

Why would you think so? Rust provide better type system and abstraction mechanisms compared to Go, hence equivalent system should have less lines of code, at least in from my experience.

This must be a sarcasm, right?

> I was referring to mandate to use it at big companies.

I've worked in almost all of big tech, and these companies don't create mandate just because "Trust me bro" or to gain some "political achievements". Their are teams who champion new technology/languages, they create proof of what new technology will bring to the table which cannot be filled with existing ones. I left amazon 7 years ago so don't know about recent development. However at Meta/Google teams are encouraged to choose from the mandate languages and if they can't they need to request for exemption and justify the exception.

> It might be counterintuitive, but garbage collectors in multithreaded code can be very efficient.

What has garbage collector to do with multithreaded code? Once you have two or more threads which needs to share data, they need to sync and you'd end up using some kind of lock, which will affect the performance. GC doesn't make anything efficient or less efficient here. It might make the code simpler as you don't have to worry about allocation/deallocation, but I don't see how it's magically going to remove the lock.

No, you don't. All you need is to create a folder `bin` and any file with `main` fn in it will create a binary.

And tell me how that pointer semantics would do * a very strict type checking * Pattern matching * Algeberic data type

Plenty of people don't write Rust for additional memory safety, they write Rust because the features provided by it is overall very balanced & encourages developer to write code which handles almost all edge cases.

This, from my limited experience working on AOSP at Google, only the newer code were being written in Rust, not the existing code. But that was 2 years ago.

I agree with simplicity and ease of learning Go.

> 3 years working with I might have had at most 3 times nil pointer crashes in prod

I've been running a rust app for my personal trading app and a small service at a very large FAANG company for more than 3 years, and guess what I'm yet to see a nil crash.

> Their goal is by end of year.

It's like what 6-7 years since the goal was "end of the year".

What exactly? I work at Instagram.

Gotcha, yeah you got me there with so many `&`. Good one.

It indeed doesn't look elegant, however I've never in my experience seen a usage like this. Do you have any reference where you might have seen this kind of usage.

What's wrong with using 3rd party library?

Can golang stop you from using a channel when it's consumed/closed?

Just curious, which programming language allows preventing shared mutable state for out-of-process data?

No, let me try to explain differently. If `compact_str` was not used, then your normal `String` would take 24 bytes of stack space (regardless of the string size) + heap space. What `compact_str` is trying to do is not use heap when string content is less than 24.

> Is there a good argument for actually using Rust for such things?

Can't speak for the author, but I'd choose Rust over Go/Java/Python for such projects for following reason:

* Rust is a more pleasant language to work with, i.e. Sum type, pattern matching, and Drop trait closing resources/cancelling tasks.

* Type system is much more robust than Go and Java, resulting in better quality code with less requirement of unit tests.

* I don't care about performance much (for personal projects), but a free performance is always a win.

Reference Counting is a type of GC.

Reference counting is a garbage collection strategy, otherwise python too would be non-gc language (cpython).

How's your experience with Leptos so far? I gave it a try over a weekend for my pet project, felt that it's not ready for prime time yet, so decided to go ahead with Dioxus (which doesn't mean that it's more stable or anything).

Could you please tell a bit more about your project, I'm very curious.

> You won't get in any trouble as a tourist or business person 99% of the time.

So there is 1% chance; and why would I take even 1% chance of getting into troubled country?

Looks very impressive, I've been tinkering with this idea to have a Kotlin type of language which transpiles to Go, but didn't go past writing a parser. Kudos for working on it, I hope it gains some popularity.

I have used Go for my day job, I'd say you can get the job done in Go. But the resulting code won't be as elegant as you could do in Rust. I'd chose Rust just because how good the type system is: sum type, pattern matching, iterators, typestate pattern, etc makes programming a pleasure. Navigating async code takes little getting used to though. And be ready for reading many new symbols i.e. ', ~, etc.

I've been programming for 12+ years and it gets real boring when you've to type/copy same thing again and again, and Go doesn't want to help you here.

> You're a known troll spamming

Can you accept even one criticism? Everyone who dares to say anything negative is a troll in your book.

Great work, looks very simple and neat. I'm gonna use it today to see how does it suit my eyes. Do you have any plans for dark mode?

> rustup fetches and installs new versions without prompting

I don't think it's true. rustup installs new version only when you run `rustup update`. What parent is talking about is pinning a particular rustc version in Cargo.toml, which allows rustup to download that version of rustc to build that particular project/crate.

It could be different for other teams, but in my team we spend a lot of time writing design docs, discussing new features (which we never end up implementing), taking a lot of time in code reviews, making sure that public changes are backward compatible. Hence at the end producing very little output and wasting tons of time in the due process.

I agree, but Google is the slowest.