4 ms·

Great! Something I've always wanted. I'd love to be able to use a bit more type-y Go such as Borgo, and have a Pythonesque dynamic scripting language that latc

by ralegh 2y ago

Great! Something I've always wanted. I'd love to be able to use a bit more type-y Go such as Borgo, and have a Pythonesque dynamic scripting language that latches onto it effortlessly. Dynamic typing is great for exploratory work, whether that's ML research or developing new features for a web app. But it would be great to be able to morph it over time into a more specified strongly typed language without having to refactor loads of stuff. Like building out of clay and firing the parts you are happy with. Could even have a three step - Python-esque -> Go/Java-esque -> Rust/C++esque.

mattlondon 2y ago
Sounds like JavaScript and typescript would be a good fit for you. Highly expressive, dynamic and strongly typed, and highly performant both on server side and within the browser.
- ralegh 2y ago
  I do like JavaScript but it strikes a weird balance for me where it's a bit too easy to write and a bit too verbose so I tend to end up with hard to maintain code. Feels good at the start of a project but rarely a few weeks in. Also not a fan of the node ecosystem, I try to use deno where I can (maybe that would be bun these days).
- zem 2y ago
  perhaps rescript [https://rescript-lang.org/ https://rescript-lang.org/] even more than typescript
anonzzzies 2y ago
> Like building out of clay and firing the parts you are happy with. > Could even have a three step - Python-esque -> Go/Java-esque -> Rust/C++esque. We do exactly that with Common Lisp. It compiles to different languages/frameworks depending on what we require (usually sbcl is more than enough, but for instance for embedded or ML we need another step. All dev (with smaller data etc) is in sbcl so with all the advantages.
- ralegh 2y ago
  Is there somewhere I could read more about this? I've always wanted to learn Lisp but lacked a specific need for it.
  - anonzzzies 2y ago
    We don’t necessarily do good lisp things; we use Common Lisp because macros and easy DSLs allows us to use CL for everything we do while using, for us, the best dev and debugging env in the world. So we want to do the exploration, building, debugging all in CL and after that compile, possibly, to something better depending. We trade for that a little bit of inconvenience (as in; leaky abstraction), but it’s worth it the past 30+ years. For learning cl, the reddit lisp subreddit is good and has the current best ones on it. Lately there is a guy making a gui (clog) who is doing good work for spreading general lisp love by making it modern. Including tutorials. And there are others too.
VBprogrammer 2y ago
I like the idea but in all honesty I have difficulty imagining it working in practice. Once your python code is stable (i.e. You've worked out 99% of the bugs you might have caught earlier with strict type checking) would there be any incentive to go back and make the types more rigid or rigorous? Would there be a non-negligible chance of introducing bugs in that process?
- ralegh 2y ago
  I agree it's a bit of a pipe dream. I'm more thinking of performance here, e.g. web services using Django. You could start off in dynamic/interpreted land and have a seamless transition to performant compiled land. Also lets you avoid premature optimisation since you can only optimise the hot paths. Also types are self documenting to an extent. Could be helpful for a shared codebase. Again Python just now getting round to adding type definitions. At the end of the day good tooling/ecosystem and sheer developer hours is more important than what I'm suggesting but it would be nice anyway. I dream about cool programming languages but I stick to boring for work.
- zem 2y ago
  by the time you have your code in its final state (i.e. you're done experimenting) and shaken out the bugs, your types are mostly static; they're just implicitly so. adding annotations and a typechecker helps you maintain that state and catch the few places where type errors might still have slipped through despite all your tests (e.g. lesser-used code paths that need some rare combination of conditions to hit them all but will pass an unexpected type through the call chain when you do). it is very unlikely that you will introduce bugs at this point.
claudionaoto 2y ago
Dart? Version 1 was a lot like Javascript/Typescript in one spec (a dynamic language with optional unsound typing). Version 2 uses sound typing, but you can still let variables unannoted (and the compiler will infer type "dynamic") for scripts.
adsharma 2y ago
py2many does python-esque to both Go and Rust. The larger problem is building an ecosystem and a stdlib that's written in python, not C. Use ffi or similar instead of C-API.

by ralegh 2y ago

mattlondon 2y ago

Sounds like JavaScript and typescript would be a good fit for you. Highly expressive, dynamic and strongly typed, and highly performant both on server side and within the browser.

ralegh 2y ago
I do like JavaScript but it strikes a weird balance for me where it's a bit too easy to write and a bit too verbose so I tend to end up with hard to maintain code. Feels good at the start of a project but rarely a few weeks in. Also not a fan of the node ecosystem, I try to use deno where I can (maybe that would be bun these days).
zem 2y ago
perhaps rescript [https://rescript-lang.org/ https://rescript-lang.org/] even more than typescript

anonzzzies 2y ago

> Like building out of clay and firing the parts you are happy with. > Could even have a three step - Python-esque -> Go/Java-esque -> Rust/C++esque. We do exactly that with Common Lisp. It compiles to different languages/frameworks depending on what we require (usually sbcl is more than enough, but for instance for embedded or ML we need another step. All dev (with smaller data etc) is in sbcl so with all the advantages.

ralegh 2y ago
Is there somewhere I could read more about this? I've always wanted to learn Lisp but lacked a specific need for it.
- anonzzzies 2y ago
  We don’t necessarily do good lisp things; we use Common Lisp because macros and easy DSLs allows us to use CL for everything we do while using, for us, the best dev and debugging env in the world. So we want to do the exploration, building, debugging all in CL and after that compile, possibly, to something better depending. We trade for that a little bit of inconvenience (as in; leaky abstraction), but it’s worth it the past 30+ years. For learning cl, the reddit lisp subreddit is good and has the current best ones on it. Lately there is a guy making a gui (clog) who is doing good work for spreading general lisp love by making it modern. Including tutorials. And there are others too.

VBprogrammer 2y ago

I like the idea but in all honesty I have difficulty imagining it working in practice. Once your python code is stable (i.e. You've worked out 99% of the bugs you might have caught earlier with strict type checking) would there be any incentive to go back and make the types more rigid or rigorous? Would there be a non-negligible chance of introducing bugs in that process?

ralegh 2y ago
I agree it's a bit of a pipe dream. I'm more thinking of performance here, e.g. web services using Django. You could start off in dynamic/interpreted land and have a seamless transition to performant compiled land. Also lets you avoid premature optimisation since you can only optimise the hot paths. Also types are self documenting to an extent. Could be helpful for a shared codebase. Again Python just now getting round to adding type definitions. At the end of the day good tooling/ecosystem and sheer developer hours is more important than what I'm suggesting but it would be nice anyway. I dream about cool programming languages but I stick to boring for work.
zem 2y ago
by the time you have your code in its final state (i.e. you're done experimenting) and shaken out the bugs, your types are mostly static; they're just implicitly so. adding annotations and a typechecker helps you maintain that state and catch the few places where type errors might still have slipped through despite all your tests (e.g. lesser-used code paths that need some rare combination of conditions to hit them all but will pass an unexpected type through the call chain when you do). it is very unlikely that you will introduce bugs at this point.

claudionaoto 2y ago

Dart? Version 1 was a lot like Javascript/Typescript in one spec (a dynamic language with optional unsound typing). Version 2 uses sound typing, but you can still let variables unannoted (and the compiler will infer type "dynamic") for scripts.

adsharma 2y ago

py2many does python-esque to both Go and Rust. The larger problem is building an ecosystem and a stdlib that's written in python, not C. Use ffi or similar instead of C-API.