51–60 of 182 posts
Go without the garbage collector.
import "C"
import "Unsafe"
Since the GC is fairly light and snappy, I find it's best of both world to only resort to Unsafe for the performance critical parts, and leave the GC deal with the rest.
For more serious performance requirements, consider using jemalloc: https://dgraph.io/blog/post/manual-memory-management-golang-...
Rust's borrow checker is the most innovative but also most inconvenient bit, and GCs are certainly more convenient.
But Rust is much more than that:
- Rust traits are like typeclasses, but you can still use dot notation for better discoverability, which IMO makes them even beter (no, hoogle is no substitute for automatic, instant inline editor documentation).
- Macros in Rust are very powerful: not only can you control what they generate, but you can also control error messages via `compile_error!` and the exciting upcoming compiler diagnostic API. This means great DX is possible, even when macros are used!
- Rust lets you write code that uses Result that is almost as compact as exceptions in other languages. The `?` (previously try! macro) operator implicitly early-returns if there is an error. With a bit of effort, its usable even in functions such as `map` and `flat_map` via `collect`
- Traits are really helpful here in two ways: You can implement `From` for standard error types to ensure they're converted to your error type (Or you can use an awesome ready-made crate that lets you add context such as https://docs.rs/anyhow/latest/anyhow/). Traits also help .collect() work with Result regardless of whether the iterable is an iterator, vector or some other data structure.
- Cargo, the Rust package manager, just works. No fuss. If you want to setup a monorepo of multiple crates, binaries, libraries, no problem - it can do that too and it will know how to handle it. Contrast with JS/TypeScript ecosystem, where monorepo setup is the topic of blogposts.
- Rust documentation culture is crazy good. Crates go as far to add a copy-pastable example to many of the functions. Thanks to python style doctests, those examples are also automatically tested. Almost all crates have an excellent "README" page that introduces the library properly. Contrast with Haskell where there's none of that.
- Some things available are just plain cool. For example, just add the Rayon crate https://docs.rs/rayon/1.5.3/rayon/ to your project and replace a few key `iter()`s with `par_iter()` and you have a multi-core program that is 4-8 times faster on your average machine.
- One of my favorite macro packages is peg (https://docs.rs/peg/latest/peg/) - it uses the compiler_error api to tell you if you've written a left-recursive definition (not good for PEG). Its super easy to use and as is Rust tradition, produces excellent parse errors with locations.
- All those C library bindings available. Enough said.
- Its really cool and convenient that you can produce a single binary. Thanks to rust-embed (https://crates.io/crates/rust-embed) its also really easy to keep it a single binary in many situations.
- Last but not least, the community goes above and beyond to make people feel welcome.
Syntax like F# but with the ability to get performance like C++. Linear types seem to offer some hope of being able to have manual / non GC memory management in a functional programming language but I haven't really seen this done in a mature functional language. To really get good performance you probably need the ability to drop down and write more procedural style code in hot code paths and expose it with a functi…
Have you tried Rust? It checks a great deal of your boxes, don't be misled by the reputation of a "systems programming language"! I made a video explaining why rust is different here, if you're interested https://youtu.be/4YU_r70yGjQ
Non-opionated memory management means that I am in the ultimate control of each allocation it does. Even if it requires GC it should allow me to redefine malloc/free and sandbox it into a memory region I choose (like Lua). It should not allocate memory willy-nilly and free it as it chooses, especially if it aims for a "system language" role.
Nice syntax is the most opionated point of mine. It should definitely be C-like and not, for example, Python-like or Lisp-like. After all, everyone can read JavaScript. I like the idea of expanding C syntax with first-class blocks (like Ruby) and semantic macros and quoting like Lisp. C has a tradition to make language constructs first-class - that was the motivation for varargs, but it's ability to create new language constructs is flawed. You can #define a "foreach" with "for"-like syntax, but it still falls short compared to what proper semantic macros can achieve. It would be nice to be able to define a "foreach" as a hygienic macro with a quote.
Typing is a non-question - I don't want to have to deal with dynamically-typed languages anymore. Extra points for local type inference. Strong static typing also enables a lot of performance enhancements down the line.
The execution model is the next salient point. My perfect language should have REPL (I'm that spoiled by Ruby and RoR) and also should be performant enough in release/production builds. Which is why it should allow both live coding and ultra-optimized AOT builds right down to native machine code. In my opinion, the best way of AOT compilation is targeting C or C++ - the AOT compiler shouldn't have to implement any optimizations Clang or GCC already have. Maybe it could target LLVM IR instead.
Native interop should be zero-cost and ideally based on LLVM tooling. The performance cost of calling a C or C++ function should be negligible. Regarding the tooling, I don't actually want to write FFI interfacing code by hand, it can easily be generated automatically.
The only language I know of that actually ticks most of these boxes is daScript, but it is still in the early phase of development and I don't particularly like the syntax of it.
Earlier quoted context omitted.
What is your thoughts on Crystal?
I had written two implementations of the same program in both Ruby in Crystal that need parallel (not threads!) jobs to be run. It did some more or less heavy computation on large data sets. Almost no difference in terms time execution. Crystal is nice, but if Ruby is the same, what's the point? Only thing I don't like about Ruby now is how they implemented types (in separate files... no, thank you). But generally sp…
You answered your own question >> I want easy code navigation.
Static types makes this a much, much more solvable problem. But I'm curious about what you mean here, because modern code navigation tools are pretty good - even for Ruby - but perhaps I am not fully understanding what it is that you are after.
* Strongly, statically typed. * Good package management. * Good, easy to reason about build system. * Popular enough to find jobs with it. Probably a lot more, but I don't really remember my annoyances unless they're in front of me.
To name a few details:
Rich but plain standard library with convenience features. E.g. if you have to read json file, you just readJsonFile(filename), not sys.fs.readFile(fn, “a”, {encoding:”utf-8”}).pipe(new JsonReader({streaming:true}).inPipe()).collect(pipeUtils.buildArray()). If you have a date, it should be easy to modify, format or extract any of its parts, and it must be a built-in standard type. If you work with http, it must be result = http.postJson(data), easily findable in a reference. If you want to just communicate with another instance, it’s result = myInstance.(), not http.
Good data extraction, transferring and restructuring features, e.g. var data1 = obj.{name, id, contacts[].value}; obj.{a, b} = data2.
Development environment is the same as runtime, no explicit build-deploy phase. See a bug or require a new feature? Click “Menu - Edit module” and edit it right there with live data and live tests. When you save, your temporary db instance/transaction/backup/whatever is applied to the main branch, after it gets its own backup.
I have much more bullet points than time rn, so I’ll stop here.
This is not exactly a “language”, but that would be perfect.
- Multiparadigm, that means traditional OOP, but also first class functions (well first class everything)
- Compiles to native code, runs relatively fast
- Designed from the ground up for async/await
- No undefined behavior
- Statically typed, but with the feeling that the compiler is helping and not punishing you. I get that feeling from Typescript, Python+MyPy, C++ on a good day, Kotlin.
I would also love to experiment with a few ideas of mine:
- Voluntary checked exceptions (You mark a block specifically and it is a syntax error if an exception could possibly leak that block).
- First class observables for easy GUI binding
- You can lift the action of a piece of code into a variable. Then you can reason about this action. For example, you would write imperative looking code to modify a document, and it would generate objects for the "command pattern" so you'd have undo functionality. Or you could lift a longer running action and have it running on a thread and cancellable. I imagine this to be closures on steroids.