4 ms·

Here are the things I would need to migrate from C/C++/Rust to a new language: Automatic memory management, with optional manual control, no garbage c

by qppo 6y ago

Here are the things I would need to migrate from C/C++/Rust to a new language: Automatic memory management, with optional manual control, no garbage collection. A universal or widely accepted build system (Cargo, CMake) A public package registry and dependency resolver, designed for deterministic builds, multiple versions of the same package on one machine, etc, and support for private/proprietary registries (Cargo, Conan) A modern query-oriented/reactive/responsive (non-batch) compiler, that supports static analysis, linting, language server features, AST traversals/queries, etc. Support for debugging with GDB/LLDB. A (substantial) subset of the language with a stable ABI. Fast debug builds, fast release binaries. Syntax/semantics of the language are significantly less important to me than all of the above.

Nuoji 6y ago
- Plan is to be able to at least build a robust ref counting lib in the standard library, supported by subtyping and defer this could be at least as easy as in ObjC before automatic refcounting. Temporary allocators (like Odin) will solve most of the temporary allocs (like when you work with strings etc). I'd need some time to explain how that works in detail, but memory management can be made much easier without even having GC or refcounting. - The build system is part of the compiler. - Package registry: still on the fence with that one. We'll see. - The compiler is not built as a responsive compiler. Working on the compiler I don't feel that the workflow of a compiler is the same as is needed for an IDE. The most important thing is not that the compiler is responsive, but that the language amends itself to be compiled in isolation in a modular way. This is a property of the language, and it's been designed with IDE friendliness in mind. - Adding more DWARF support is on the todo and obviously a requirement for a serious language - LLVM prevents anything based on LLVM to be really slow to compile. It takes something like 99% of all compile time, even on debug builds with no optimizations. To have really fast debug builds a custom backend is needed for each platform. That will happen eventually.

by qppo 6y ago

Nuoji 6y ago

- Plan is to be able to at least build a robust ref counting lib in the standard library, supported by subtyping and defer this could be at least as easy as in ObjC before automatic refcounting. Temporary allocators (like Odin) will solve most of the temporary allocs (like when you work with strings etc). I'd need some time to explain how that works in detail, but memory management can be made much easier without even having GC or refcounting. - The build system is part of the compiler. - Package registry: still on the fence with that one. We'll see. - The compiler is not built as a responsive compiler. Working on the compiler I don't feel that the workflow of a compiler is the same as is needed for an IDE. The most important thing is not that the compiler is responsive, but that the language amends itself to be compiled in isolation in a modular way. This is a property of the language, and it's been designed with IDE friendliness in mind. - Adding more DWARF support is on the todo and obviously a requirement for a serious language - LLVM prevents anything based on LLVM to be really slow to compile. It takes something like 99% of all compile time, even on debug builds with no optimizations. To have really fast debug builds a custom backend is needed for each platform. That will happen eventually.