Enso2023
From APIDesign
(Difference between revisions)
| Line 23: | Line 23: | ||
* Making it really immutable - like [https://github.com/enso-org/enso/pull/4023 Removing Unsafe.set_atom_field] | * Making it really immutable - like [https://github.com/enso-org/enso/pull/4023 Removing Unsafe.set_atom_field] | ||
* [https://github.com/enso-org/enso/pull/6151 Suspended atom fields are evaluated only once] | * [https://github.com/enso-org/enso/pull/6151 Suspended atom fields are evaluated only once] | ||
| + | * Designed and implemented ***runtime type system**: | ||
| + | ** [https://github.com/enso-org/enso/issues/6682 Clearly report type errors on API boundary] | ||
| + | |||
== Improving Libraries == | == Improving Libraries == | ||
Revision as of 07:02, 30 April 2026
Another year at Enso. I think I started to feel more confident about the code base than in Enso2022 and was able to start designing:
- propose architectural changes
- suggest language changes
- change the infrastructure to work better
Contents |
Performance and Runtime
- Speed Standard.Base initialization in simple Hello World example up!
- Any.== slowed down by gigantic EqualsNode specializations
- Removing need for asynchronous thread to execute ResourceManager finalizers
- Improve inlining of <|
Tooling
- Basic VSCode support for Enso language and development
- Basic IGV Scala Support
- Integration with VisualVM - write logs in XML & co.
Improving Language
- Making it really immutable - like Removing Unsafe.set_atom_field
- Suspended atom fields are evaluated only once
- Designed and implemented ***runtime type system**:
Improving Libraries
List of 252 issues and requests resolved in 2023.
Follow
