This person is no superstar.

Surely this will have a real impact instead of just making low-paid workers jobs much harder.

Gleam is cool. I wrote some services with it to see if I wanted to use it for more projects. It seemed like a good option because it would be easy to teach.

Things I like:

• fast build times (I only tested small apps though, under 2000 LOC)
• strong static types
• runs on the BEAM
• easy to learn
• pattern matching
• immutable + structural sharing
• currying (with parameter holes)

Things I don't like:

• no re-exports
• it's possible to have name collisions between packages; authors have a gentleman's agreement to always create a top-level module with the same name as the package
• some standard library APIs seem missing or immature (it's still pre-1.0)
• it can be hard to get good performance out of idiomatic code for specific tasks (see immutability)
• no format strings; best you can do is "Hello, " <> name. It starts to get cumbersome
• parsing/serialization is all quite manual boilerplate; there's nothing quite like serde
• no field/argument punning
• no method syntax; you just have to scan the docs to figure out what functions can be used with a given type
• you can't define the same variant name twice in the same module; I believe this is a limitation in how the types are translated to Erlang records
• you can't call functions in pattern matching if guards
• you can't have dependency cycles between modules in the same package
• hard to write FFI correctly; you lose all the comfort of types

I literally had a high school orchestra conductor named "Dr. Pipo" and it was pronounced exactly like that.

Are you kidding me? Clap has some of the best documentation of any crate.

I don't think my company uses batch scripts anywhere, but if they did, it would probably be in the app installer for Windows or something.

; is just a monad after all

The git push --force is definitely a controversial suggestion, im personally happy with doing that, but I have also personally accidentally force pushed dev/main and seen others do it. Squash on merge is probably a safer habit to have. Also, gitlab and bitbucket both get a bit confused if you forcepush to a branch that is part of a MR.

You can add branch protections that will prevent you from accidental force pushing to main or dev.

IMO when I see a PR with "WIP" commits, I just assume that minimal effort was put into keeping the commits organized, and I squash all commits to review the PR. If I see many meaningful commit messages, I will try reviewing one commit at a time.

When I make a PR, I force push to keep my commits organized. If there are changes I want to make as a result of feedback, and they would create significant churn to rebase all of the patches, then I will apply the feedback in a follow-up commit.

Seems like they could maintain non-canonical lookups by normalizing all crate names to use underscores.

I don't think DRY or WET or the "rule of 3" can address the nuances of some abstractions. I think most of the times when I decide to abstract something, it's not because the code looks repetitive, but because I've decomposed the architecture into components with specific responsibilities that work well together.

In other words, I don't abstract from the bottom up, looking at repetitive code. I abstract from the top down, considering what capabilities are required from a system and decomposing the system to deliver those capabilities.

Of course, repetitive code might be a smell, suggesting that there is room for abstraction, but I don't design the abstraction based (entirely) on the existing code.

I don't think many large established companies will be taking the risk on newer languages, but there are plenty of new companies that will mature based on a foundation of writing their backend in Rust or some other new language.

Probably some Rust contingents will form on internal teams within large companies, and they will build new products or services in X new language.

Loving it except for a handful of bugs that I expect to be fixed in the next release :)

It feels good to start fresh with a new set of community subscriptions. Some of them I've subscribed based on the topic before they've had significant traffic, but we'll see what happens!