4 ms·

I love Rust but I am still looking for the perfect blend of the two camps. One the one hand, Go/Node/Python/etc doesn't scratch my itch for the strong type sys

I love Rust but I am still looking for the perfect blend of the two camps. One the one hand, Go/Node/Python/etc doesn't scratch my itch for the strong type system (sum types/tagged enums mostly) and on the other hand even though I like prototyping in Rust I really miss things like a REPL, more terse syntax, and a bit more expressiveness. I think OCaml is closer to my ideal but the ecosystem isn't quite there. Maybe all it needs is time.

baby 4y ago
Yeah I would have recommended OCaml, the language seriously need more developers to contribute to the ecosystem. It could be much nicer.
jdlshore 4y ago
Have you looked at Node + TypeScript? I'm just starting to dig into TS, but its type system is one of the better ones I've seen. And Node is nice and mature with good async capabilities.
- jjnoakes 4y ago
  I'd prefer something with a more sound type system, and something that makes cleaning up resources easier and more ergonomic. This might help with cleanup: https://github.com/tc39/proposal-explicit-resource-management https://github.com/tc39/proposal-explicit-resource-managemen... But I'm not sure anything will help with the type system. For example, this drives me absolutely insane: https://www.typescriptlang.org/play#code/MYewdgziA2CmB00QHMAUBtARARgAyYBoACHfY0zAXXgFsBDAB1QboCcJYBJMAFwEo+AKCA https://www.typescriptlang.org/play#code/MYewdgziA2CmB00QHMA...
  - jdlshore 4y ago
    > makes cleaning up resources easier I've never really had a problem with it, but I isolate such resources behind a wrapper, which makes cleanup easy. I just create a little higher-order function: function doSomethingThatNeedsCleanup(fn) { const thing = createTheThing(); try { return fn(thing); } finally { cleanUpTheThing(thing); } } > this drives me absolutely insane (console.log(["10", "10", "10"].map(parseInt) outputs [10, NaN, 2]) That's not really an issue with the type system, that's just coincidence and bad luck. The signature of parseInt is: parseInt(string: string, radix?: number | undefined): number And Array<string>.map(fn) takes a function with the signature: fn(element: string, index?: number | undefined, array?: string[] | undefined): any So parseInt coincidentally matches the signature Array<string>.map() is looking for. I'm not sure what you expect the type system to do here. It works just fine at catching an actual type error, such as this: console.log([10, 10, 10].map(parseInt) ...which correctly complains: Argument of type '(string: string, radix?: number | undefined) => number' is not assignable to parameter of type '(value: number, index: number, array: number[]) => number'. Types of parameters 'string' and 'value' are incompatible. Type 'number' is not assignable to type 'string'. (As I'm sure you know, this is the correct code: `console.log(["10", "10", "10"].map(s => parseInt(s))` .)
    - jjnoakes 4y ago
      > So parseInt coincidentally matches the signature Array<string>.map() is looking for. If that were true I'd not mind quite as much... but actually, parseInt takes two parameters and map passes three.
      - jdlshore 4y ago
        Map’s second and third parameters are optional. Your functions aren’t required to implement them, which is good, because most of the time you don’t need them. Again, this isn’t a type system issue. It’s both an API design issue and a poor programming hygiene issue. (Don’t pass bare functions if you don’t know what the parameters are.)
        jjnoakes 4y ago
        > Map’s second and third parameters are optional. I mean, map always passes them in, so in that sense they aren't optional. Mixing that with functions that take in optional parameters, but aren't usually called with them, gives you a ticking time bomb, IMO. And double that danger when the language's type system allows you to call a function with more parameters than it could ever take. > Don’t pass bare functions if you don’t know what the parameters are. This is exactly the kind of thing I want my programming language's type system to catch for me, if I'm working in a language with a static type system like TS. And even in dynamic languages, this is exactly the kind of thing I want my programming language to catch for me at runtime. Python does, for example. Stuff like this - while it might fit JS and TS and make sense to some - makes absolutely no sense to me, and is why I simply look to other languages to fit my needs.
        Mapsmithy 4y ago
        How would you change the Type System to fix this particular issue? >> Don’t pass bare functions if you don’t know what the parameters are. > This is exactly the kind of thing I want my programming language's type system to catch for me, if I'm working in a language with a static type system like TS. Hows your compiler supposed to know you don't know what the parameters are?
  - doodlesdev 4y ago
    > But I'm not sure anything will help with the type system. For example, this drives me absolutely insane: https://www.typescriptlang.org/play#code/MYewdgziA2CmB00QHMA... You just gave me CPTSD, thank you. This motivated me enough so that I will leave JavaScript and TypeScript for good now.
  - dragonwriter 4y ago
    Oh, god, the “you can call it with one arg, but it really has more, and then you tried to use map, you poor fool” trap.
tekkk 4y ago
Pick a problem, not a tool first. Unless you're more interested in the tool than the problem, then it's fine. I don't love Rust, but I can get by. TS+NodeJS is okay. But I'm more interested in the problems that I'm solving so I just use whatever is the most suited.
- hot_gril 4y ago
  Yes. I cringe a little getting emails from startup recruiters saying "join a Rust startup." As if the success of their business hinges on using Rust for something that probably doesn't need it. I've found that the basic NodeJS or Python works for most problems I've chosen. Not even with strong typing.
- jjnoakes 4y ago
  I do that today, but I believe there is still a lot of opportunity for languages to approach my ideal, and I think I share my ideal with others. And if a language like that did exist, or could be made, I'd love to use it - changing languages every project is workable, but you'd probably agree (I hope?) that NOT changing languages every project would be even better.
cultofmetatron 4y ago
its older than rust. its had plenty of time. what ocaml needs is a renaissance and new blood. sadly it doesn't have the momentum of being new but I agree its a compelling language. I see it as a better, typed alternative to go.
12345hn6789 4y ago
If you don't need bare metal something like Scala or koitlin will fit. Scala is extremely expressful and does CRUD very well
- jjnoakes 4y ago
  Scala is on my list of languages to try. I'm usually not a fan of large runtimes or too many abstractions from the OS, but I do want to give it a fair shake. F# too.
- jmaker 4y ago
  Scala is amazing but the community has been shrinking for the past few years, ever so fewer libraries maintained.
Zababa 4y ago
OCaml with tooling and an ecosystem from the size of Go would be an ideal. Java and C# can more and more be written like MLs too.
- jjnoakes 4y ago
  I think I would love an ML-like language built on the go runtime and standard library and ecosystem.

baby 4y ago

Yeah I would have recommended OCaml, the language seriously need more developers to contribute to the ecosystem. It could be much nicer.

jdlshore 4y ago

Have you looked at Node + TypeScript? I'm just starting to dig into TS, but its type system is one of the better ones I've seen. And Node is nice and mature with good async capabilities.

jjnoakes 4y ago
I'd prefer something with a more sound type system, and something that makes cleaning up resources easier and more ergonomic. This might help with cleanup: https://github.com/tc39/proposal-explicit-resource-management https://github.com/tc39/proposal-explicit-resource-managemen... But I'm not sure anything will help with the type system. For example, this drives me absolutely insane: https://www.typescriptlang.org/play#code/MYewdgziA2CmB00QHMAUBtARARgAyYBoACHfY0zAXXgFsBDAB1QboCcJYBJMAFwEo+AKCA https://www.typescriptlang.org/play#code/MYewdgziA2CmB00QHMA...
- jdlshore 4y ago
  > makes cleaning up resources easier I've never really had a problem with it, but I isolate such resources behind a wrapper, which makes cleanup easy. I just create a little higher-order function: function doSomethingThatNeedsCleanup(fn) { const thing = createTheThing(); try { return fn(thing); } finally { cleanUpTheThing(thing); } } > this drives me absolutely insane (console.log(["10", "10", "10"].map(parseInt) outputs [10, NaN, 2]) That's not really an issue with the type system, that's just coincidence and bad luck. The signature of parseInt is: parseInt(string: string, radix?: number | undefined): number And Array<string>.map(fn) takes a function with the signature: fn(element: string, index?: number | undefined, array?: string[] | undefined): any So parseInt coincidentally matches the signature Array<string>.map() is looking for. I'm not sure what you expect the type system to do here. It works just fine at catching an actual type error, such as this: console.log([10, 10, 10].map(parseInt) ...which correctly complains: Argument of type '(string: string, radix?: number | undefined) => number' is not assignable to parameter of type '(value: number, index: number, array: number[]) => number'. Types of parameters 'string' and 'value' are incompatible. Type 'number' is not assignable to type 'string'. (As I'm sure you know, this is the correct code: `console.log(["10", "10", "10"].map(s => parseInt(s))` .)
  - jjnoakes 4y ago
    > So parseInt coincidentally matches the signature Array<string>.map() is looking for. If that were true I'd not mind quite as much... but actually, parseInt takes two parameters and map passes three.
    - jdlshore 4y ago
      Map’s second and third parameters are optional. Your functions aren’t required to implement them, which is good, because most of the time you don’t need them. Again, this isn’t a type system issue. It’s both an API design issue and a poor programming hygiene issue. (Don’t pass bare functions if you don’t know what the parameters are.)
      - jjnoakes 4y ago
        > Map’s second and third parameters are optional. I mean, map always passes them in, so in that sense they aren't optional. Mixing that with functions that take in optional parameters, but aren't usually called with them, gives you a ticking time bomb, IMO. And double that danger when the language's type system allows you to call a function with more parameters than it could ever take. > Don’t pass bare functions if you don’t know what the parameters are. This is exactly the kind of thing I want my programming language's type system to catch for me, if I'm working in a language with a static type system like TS. And even in dynamic languages, this is exactly the kind of thing I want my programming language to catch for me at runtime. Python does, for example. Stuff like this - while it might fit JS and TS and make sense to some - makes absolutely no sense to me, and is why I simply look to other languages to fit my needs.
        Mapsmithy 4y ago
        How would you change the Type System to fix this particular issue? >> Don’t pass bare functions if you don’t know what the parameters are. > This is exactly the kind of thing I want my programming language's type system to catch for me, if I'm working in a language with a static type system like TS. Hows your compiler supposed to know you don't know what the parameters are?
- doodlesdev 4y ago
  > But I'm not sure anything will help with the type system. For example, this drives me absolutely insane: https://www.typescriptlang.org/play#code/MYewdgziA2CmB00QHMA... You just gave me CPTSD, thank you. This motivated me enough so that I will leave JavaScript and TypeScript for good now.
- dragonwriter 4y ago
  Oh, god, the “you can call it with one arg, but it really has more, and then you tried to use map, you poor fool” trap.

tekkk 4y ago

Pick a problem, not a tool first. Unless you're more interested in the tool than the problem, then it's fine. I don't love Rust, but I can get by. TS+NodeJS is okay. But I'm more interested in the problems that I'm solving so I just use whatever is the most suited.

hot_gril 4y ago
Yes. I cringe a little getting emails from startup recruiters saying "join a Rust startup." As if the success of their business hinges on using Rust for something that probably doesn't need it. I've found that the basic NodeJS or Python works for most problems I've chosen. Not even with strong typing.
jjnoakes 4y ago
I do that today, but I believe there is still a lot of opportunity for languages to approach my ideal, and I think I share my ideal with others. And if a language like that did exist, or could be made, I'd love to use it - changing languages every project is workable, but you'd probably agree (I hope?) that NOT changing languages every project would be even better.

cultofmetatron 4y ago

its older than rust. its had plenty of time. what ocaml needs is a renaissance and new blood. sadly it doesn't have the momentum of being new but I agree its a compelling language. I see it as a better, typed alternative to go.

12345hn6789 4y ago

If you don't need bare metal something like Scala or koitlin will fit. Scala is extremely expressful and does CRUD very well

jjnoakes 4y ago
Scala is on my list of languages to try. I'm usually not a fan of large runtimes or too many abstractions from the OS, but I do want to give it a fair shake. F# too.
jmaker 4y ago
Scala is amazing but the community has been shrinking for the past few years, ever so fewer libraries maintained.

Zababa 4y ago

OCaml with tooling and an ecosystem from the size of Go would be an ideal. Java and C# can more and more be written like MLs too.

jjnoakes 4y ago
I think I would love an ML-like language built on the go runtime and standard library and ecosystem.