3 ms·

No-one ever has the "Grand Vision" to cut something down to it's essential 25% and delete the rest.

techbrovanguard 8mo ago
By all means, write some Go instead—you might want to order a new `if err != nil` button to stave off the RSI. The rest of us are trying to make things better.
ebiederm 8mo ago
Chuck Moore of Forth fame.
lioeters 8mo ago
Unless there's a conscious and constant effort to keep things simple, a programming language or software project will grow to consume all available resources, developers' time, intellectual capacity, and funding.
chiffaa 8mo ago
You can't cut down a language without breaking changes. And there fairly often are internal changes to simplify the compiler and the tooling. Just in the latest release, annotation internals were finally fully unified between rustc, cargo, clippy and other tools. This was a fairly considerable effort in deduplicating code. Borrow checker is being rewritten to move to tree borrows, trait resolution is being refactored for a variety of reasons. Code is being simplified where possible, but this doesn't mean Rust doesn't have areas to improve in, especially if there is a goal of replacing Ada/SPARK
nsm 8mo ago
https://without.boats/blog/revisiting-a-smaller-rust/ https://without.boats/blog/revisiting-a-smaller-rust/ I think there is a programming language hole for a Rust-like language, but with GC and green threads. One that dispenses with single-ownership, and async/await footguns. Something like F#/Kotlin is closest in terms of developer experience. Unfortunately, we are really lacking a language that skews badly on some other axis - F# - tainted by being Windows only for really long and being Microsoft. - Kotlin - tainted by the JVM - Java 24+ - has virtual threads, sum types, match expressions and other niceties, but tainted by the JVM again (Verbosity included, but this is not really a factor with IDEs and LLMs.) Note that the opinions above are not mine, but "consensus". I'd say they are all unfair opinions. I feel like people end up favoring new languages, simply because of novelty. Like, inevitably, somebody is gonna say Gleam. I'm all for having existing BEAM users getting access to new languages, but I'm not sure why one would pick a BEAM language for non-server applications when the developer tooling story for CLI apps, line-of-business apps and so on is so much stronger for the .NET and JVM ecosystems. No offense to the Gleam folks intended.

By all means, write some Go instead—you might want to order a new `if err != nil` button to stave off the RSI. The rest of us are trying to make things better.

ebiederm 8mo ago

Chuck Moore of Forth fame.

lioeters 8mo ago

Unless there's a conscious and constant effort to keep things simple, a programming language or software project will grow to consume all available resources, developers' time, intellectual capacity, and funding.

chiffaa 8mo ago

You can't cut down a language without breaking changes. And there fairly often are internal changes to simplify the compiler and the tooling. Just in the latest release, annotation internals were finally fully unified between rustc, cargo, clippy and other tools. This was a fairly considerable effort in deduplicating code. Borrow checker is being rewritten to move to tree borrows, trait resolution is being refactored for a variety of reasons. Code is being simplified where possible, but this doesn't mean Rust doesn't have areas to improve in, especially if there is a goal of replacing Ada/SPARK

nsm 8mo ago

https://without.boats/blog/revisiting-a-smaller-rust/ https://without.boats/blog/revisiting-a-smaller-rust/ I think there is a programming language hole for a Rust-like language, but with GC and green threads. One that dispenses with single-ownership, and async/await footguns. Something like F#/Kotlin is closest in terms of developer experience. Unfortunately, we are really lacking a language that skews badly on some other axis - F# - tainted by being Windows only for really long and being Microsoft. - Kotlin - tainted by the JVM - Java 24+ - has virtual threads, sum types, match expressions and other niceties, but tainted by the JVM again (Verbosity included, but this is not really a factor with IDEs and LLMs.) Note that the opinions above are not mine, but "consensus". I'd say they are all unfair opinions. I feel like people end up favoring new languages, simply because of novelty. Like, inevitably, somebody is gonna say Gleam. I'm all for having existing BEAM users getting access to new languages, but I'm not sure why one would pick a BEAM language for non-server applications when the developer tooling story for CLI apps, line-of-business apps and so on is so much stronger for the .NET and JVM ecosystems. No offense to the Gleam folks intended.