161–170 of 523 posts
Earlier quoted context omitted.
Unfortunately a lot of people will dismiss C# and F# just because it has the Microsoft label. I do think they're missing out.
Nowadays I program in a mostly Microsoft world (VSCode, Github, npm, typescript, GPT, ...) and I think its quite good, so no bias here. But the "shipping a native binary straight to the server that just works" is absolutely crucial for me
A good example of this trade-off in Java is Lombok. A very handy library that legitimately avoids a ton of boilerplate, but it also absolutely tanks your build time. In a real system, a large one, your team is better off just getting good enough with their editor that they can generate the hateful boilerplate, and leave Lombok out. Because you'll be paying for Lombok all the time, and only need it a small fraction of the time. There are hundreds, thousands of these conveniences that are deeply tempting but should be avoided, in every build. The problem is that the programmers become attached to these little nicities and actively resist giving them up, even though they are so costly.
,,I would have traded performance and expressivity away for simplicity'' ,,A lot of people in the Rust community think "zero cost abstraction" is a core promise of the language. I would never have pitched this and still, personally, don't think it's good'' If the language makes compromises in performance, it's not a real C++ competitor anymore. Some things are not about what people ,,like'', but that we need a langua…
Too bad graydon didn't get his way with build times. I've come to believe that the most important feature of any development environment is to minimize the built-test-debug cycle. Of course, a real system has many different ones, ranging from "language level" to "I have to redeploy and perform a complex series of actions in an app or 3". But at the language level I've found that build performance is of paramount impo…
Earlier quoted context omitted.
We build a proof-of-concept backend replacement for what is essentially “SharePoint being used as a DB with a frontend by people who don’t know how to use SharePoint” and was a nice experience. We also build it in a few other languages, C#, Go, Python and TypeScript and Rust was probably the best experience of them all. We ended up going with C# because we needed Odata, and at the time we hadn’t yet run into the many…
> I wish Rust would have someone like Facebook pick it up and build a frontend framework for it We have yew, and my personal favourite: leptos ( https://leptos.dev/ )
Earlier quoted context omitted.
I would like to second F#. It seems to have a lot of what people want, so why isn't it more popular?
Can I natively build self-contained binaries? One of Go's biggest advantages is the delivery chain from code to server (build for target arch, copy to target, ./run)?
"Complex grammar. I've become somewhat infamous about wanting to keep the language LL(1) but the fact is that today one can't parse Rust very easily, much less pretty-print (thus auto-format) it, and this is an actual (and fairly frequent) source of problems. It's easier to work with than C++, but that's fairly faint praise. I lost almost every argument about this, from the angle brackets for type parameters to the pattern-binding ambiguity to the semicolon and brace rules to ... ugh I don't even want to get into it. The grammar is not what I wanted. Sorry."
Earlier quoted context omitted.
You could try C# (or Kotlin if you have a MS bias ;-)). Both really nice general purpose languages, quite performant despite having a GC and great available tooling.
I think I still would have to deal with a lot of OOP and imperative code there, C# feels like a kitchen sink of stuff - right?
Rust is imperative too, though.
,,I would have traded performance and expressivity away for simplicity'' ,,A lot of people in the Rust community think "zero cost abstraction" is a core promise of the language. I would never have pitched this and still, personally, don't think it's good'' If the language makes compromises in performance, it's not a real C++ competitor anymore. Some things are not about what people ,,like'', but that we need a langua…
The trick is to find the right place to compromise so the cost is minimal overall even if it isn't zero.
Earlier quoted context omitted.
I disagree. You can call an async function in Rust from a regular one, that's true, but the returned value still needs to be passed through an executor to be useful. Async without function coloring means being able to call `async fn add(a, b: usize) -> usize` from anywhere and having an usize back, whether you're calling from a regular or async function. If you need slightly different logic because of async, you got…
Algebraic effects like how OCaml’s now implementing it may be possible! The ecosystem around effects in OCaml is still really young, but here’s an example of an http request being made that is asynchronous, non-blocking but looks synchronous with no special syntax. https://github.com/mirage/ocaml-cohttp/blob/16e991ec1f7e5f0c... Performing these effects is similar to throwing exceptions up the callstack where whicheve…
- what the type of res is (is it a string? A buffer? Async string? Something else?)
- how this code does not block: what is happening in parallel? At which point will it block?
I would like to be excited about OCaml’s algebraic effects, but right now I don’t really get it.