6 ms·
I love Rust and built some production code with it in the past. But nowadays I want something more simple so that not-so-senior developers can pick it up quickl
by anonyfox 3y ago
I love Rust and built some production code with it in the past. But nowadays I want something more simple so that not-so-senior developers can pick it up quickly, and I want flawless tooling, and willing to sacrifice a bit of performance. So basically I often end up with Go. Go is exceptionally great in tooling, ecosystem, any objective metrics like build times or crosscompilation... but I still don't like the language itself personally.
If there would be something just like Go, but with a bit more powerful typesystem like Rust has (Option<T> instead of `err != nil`, and so on), and a simplified ML-like language instead of an imperative one... that would be my dream.
- jeltz 3y agoYeah, that is exactly what I want for when I build web applications. Something with an ecosystem like Rust's, with more advanced type system than go but which sacrifices some performance for ease of development.
- californical 3y agoI feel like Crystal is close, they just need more community to build out their ecosystem. Otherwise it seems like a perfect language (fun, simple to understand, compiled + fast, has types)
- anonyfox 3y agoAlready played with it, what has killed me are the outragously long compile times for nontrivial code and no "easy" way to crosscompile binaries, besides from some docker hack. Also its like a modern Ruby, which is great in general, but I really want ML-like functional style programming instead of OOP
- jjtheblunt 3y agoHave you dismissed F# ?
- hajile 3y agoThe rest of the world has. If you're going to use .net, there's almost zero chance that you'll get permission to use F#. For whatever reason, C# devs seem incredibly resistant to even just looking at F#.
- pjmlp 3y agoDo you want reasons? Here are a couple from someone that has learned ML with Caml Light, and most of the latter ML variants. VS Tooling lacking versus C#/VB, no support for code generators, no support for Roslyn, no support for GUI frameworks, no support for EF tooling, many .NET vendors don't support projects if using F#, community likes to create their own wrappers instead of embracing standard .NET projects, ....
- FrustratedMonky 3y agoI would like to second F#. It seems to have a lot of what people want, so why isn't it more popular?
- anonyfox 3y agoCan 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)?
- naraga 3y agoI believe you can https://learn.microsoft.com/en-us/dotnet/core/deploying/single-file/overview https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...
- throwaway2037 3y agoI can vouch for it! I returned to C# for a tiny desktop GUI recently. I was blown away by how simple is the tooling to create a single monolithic binary. It's great for enterprise distribution. "No more installer."
- zidad 3y agoYou 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.
- anonyfox 3y agoI 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?
- zamalek 3y agoC# is horribly OOP. I use it in my day job, and the frameworks wield OOP overcomplexity proudly. It has likely gone beyond Java as the posterchild for OOP: interfaces that are implemented once, classes that are instantiated once. You can't get away from it either, it is practically part of the stdlib and everyone cargocults it. Rust is imperative too, though.
- hadrien01 3y agoThe language doesn't push you towards interfaces implemented once, but many developers indeed persist doing it for no reason at all. With proper code review we're able to make that practice go away on the projects I'm working on.
- deleted 3y ago[deleted]
- amelius 3y agoOCaml?
- anonyfox 3y agoreally tried to get into it for a while, but the tooling situation feels like the polar opposite of Go, where everything needed in daily work is right there in a standardized way and just works out of the box. I kinda like the language (its what I want basically) but the operational aspects are what I actually need and want first and foremost.
- kaba0 3y agoScala, Haskell, Java, Kotlin.
- gardaani 3y agoRust borrow checker and lifetimes are sometimes so frustrating. I hope that the Jakt language will evolve to the language I'd like to see: Swift without ties to Apple and Objective-C.
- bscphil 3y agoApple has been pushing Swift on Linux enough that I've been checking out its progress every so often. It will probably never get entirely free of ObjC but it's a nice enough language that I'd really like to be able to use it for cross-platform desktop applications. Having a pretty robust standard library and a stable ABI (currently just on macOS) are big plusses, in my book. Having a built in REPL is icing (delicious, delicious icing).
- netbioserror 3y agoNim gets real close. It doesn't have great UI tooling, but its command line tools are quite good.
- rdevsrex 3y agoYeah I've been looking into Nim and I want to build something substantial in it and see how it performs and feels to write.
- xhevahir 3y agoNim is quite imperative, too. And its BDFL(Araq) takes a dim view of functional programming: https://forum.nim-lang.org/t/8927 https://forum.nim-lang.org/t/8927
- 59nadir 3y agoNim punts too many things to random GitHub libraries. Tagged unions with exhaustiveness checks for something like pattern matching on them is the responsibility of some random person in the Nim community, for example, which is a step too far, IMO. I think what it comes down to is that the creator/BDFL of Nim has an eclectic set of things that he simply doesn't care about and will never add to the language even though they are basically table stakes nowadays.
- weatherlight 3y agoI wish someone would go back and give love to Standard ML. it such a great language, small, and easy to learn, extremely fast, compiles fast, and expressive to boot. It's tooling isn't great though. I think its syntax is a lot nicer than OCaml's for example. There is this wonderful language that is up and coming called Roc that look promising. https://www.youtube.com/watch?v=6qzWm_eoUXM https://www.youtube.com/watch?v=6qzWm_eoUXM language examples here -> https://www.roc-lang.org/tutorial https://www.roc-lang.org/tutorial
- YorickPeterse 3y agoPerhaps you'd be interested in Inko (https://inko-lang.org/ https://inko-lang.org/). It's obviously not there yet in terms of tooling and what not, but it might scratch an itch for those looking for something a bit like Rust, but easier to use. Disclaimer: I'm the author of said language :)
- justinpombrio 3y agoLots of languages are aiming for "like Rust, but easier to use" -- I think I could name half a dozen. It's a laudable goal! I'm curious how references in your language work. I see the very small example, but it doesn't explain much. Some questions in that regard: Is `&T` a type? Can you store it in a structure, or return it? Can you have a reference to a reference? If you can have a function `f(&T, &T) -> &T`, how do you distinguish whether the reference it returns lives as long as the first or second argument? If references can't be stored in structs, how do you do non-owned iterators, or string slices?
- YorickPeterse 3y agoIf you scroll past the code examples, there are a few more details, though for more you'll need to look at the documentation (specifically https://docs.inko-lang.org/manual/main/getting-started/memory-management/ https://docs.inko-lang.org/manual/main/getting-started/memor...). > Is `&T` a type? Inko's syntax for references is `ref T` for immutable references/borrows, and `mut T` for mutable ones. Unlike Rust, you can't implement methods/traits _only_ for references, instead you can only implement them for the underlying "base" type. So `impl ToString for String { ... }` is valid, but `impl ToString for ref String { ... }` isn't. > Can you store it in a structure, or return it? Yes. > Can you have a reference to a reference? No, `ref ref T` is "collapsed" into just `ref T`, and the language has no notion of pointers and pointer-pointers. > If you can have a function `f(&T, &T) -> &T`, how do you distinguish whether the reference it returns lives as long as the first or second argument Inko doesn't have a borrow checker, so it doesn't. Instead it relies on runtime reference counting to prevent dropping of values that still have references to them. Over time I hope to implement more compile-time analysis to reduce this cost as much as possible, but borrow checking/lifetime analysis like Rust isn't something Inko will have. Or to put it differently, I want the compiler to catch say 80-90% of the obvious "this ref outlives its pointee" errors without complicated borrow checkers. For the remaining 10-20% the runtime check should suffice.
- avgcorrection 3y ago> If there would be something just like Go, but with a bit more powerful typesystem like Rust has (Option<T> instead of `err != nil`, and so on), and a simplified ML-like language instead of an imperative one... that would be my dream. Not to be snarky (for once) but - More powerful type system: that goes against the whole implementation culture behind Go and their wider philosophy - ML-inspired instead of imperative: goes even more counter to the above I have never tried Go and I will probably never care to try it, but I have never seen a language which manages to both be (1) simple in the Go-sense and (2) look remotely anything like an ML language.
- scythe 3y ago>like Rust has (Option<T> instead of `err != nil` Didn't they implement generics already? https://go.dev/blog/why-generics https://go.dev/blog/why-generics It seems like their implementation has enough power to do this in most cases, although "Option" is not built in.