7 ms·

My experience from a host of language experiments of late: ranging from F#, to Rust, to Nim, to C#, to Go, to C++ Is that it just doesn't matter very much. F#

My experience from a host of language experiments of late: ranging from F#, to Rust, to Nim, to C#, to Go, to C++ Is that it just doesn't matter very much. F# has very powerful generics, and there are particular circumstances where that saves me a lot of typing. But you can still get it done in C# with less powerful generics, or Go with none. F# has sum types, and replaces null with an option type - great ideas, but you can approximate these ideas in any language if you need to. Similarly, Nim's metaprogramming has let me do some really clever things, but again, it just saves some typing. I've found that language features and properties are often given more weight than they deserve. The really hard problems I've had when coding are just the actual problems. And while a particular language can be life-changing in particular problem domains, its rare that they are life changing in general. Go is maybe the language I think is least interesting of all of the ones I've played with but I currently prefer it over the others because 1. stable, mature language and tools (unlike nim) 2. fast compile times (unlike rust) 3. compiles to native executables F# might be my favorite if it had fast compile times and native compilation. Rust might be my favorite if I ever grok the borrow checker. But if someone said I had to use language X to do project Y I would almost always be fine with it, unless there were insurmountable performance problems caused by the language.

seanwilson 9y ago
> F# has sum types, and replaces null with an option type - great ideas, but you can approximate these ideas in any language if you need to. How? You can make up for it somewhat with linters, unit tests etc. but it's tiring and nowhere near as robust as a type checker that enforces null checks for you.
- gameswithgo 9y ago
  oh I agree, and understand. You lose compile time enforced type safety against nulls when you approximate it, and I do think it is the right approach to use option types instead of null, and that more languages should do this. But it is just one parameter of a thousand affecting how easy it is to write good code, it sometimes has runtime costs.
peterevans 9y ago
Go is like the Six Million Dollar Man language, compared to C. It's everything C can do, but much better. Both C and Go are very, very simple languages; there aren't many keywords, and it's pretty easy to grok both at a functional level. It takes, of course, a bit to reach the second-level understanding you need to make full use of either language, but it's easy to hit the ground running in both. We sometimes get stuck on one language being better than others because it has X feature or Y concept, and I've seen some people essentially root for one language over another. But at the end of the day, languages are tools to get your work done, and on balance the work is going to be hard whichever route you go. Use the one that suits the talents you have available and that broadly complements the needs that you have.
- gameswithgo 9y ago
  Yes it is definitely true that coming to a nearly-complete understand of Go is very very easy compared to Rust, F#, or Nim. I haven't used it with teams of people on any way yet but I imagine it makes it somewhat easier to drop into code that isn't yours and understand it. There are less ways to create voodoo. Which can be a pro or a con, depending!
- vvanders 9y ago
  > It's everything C can do, but much better. Are you sure about that? I don't think you'll be running Go on an AVR. Likewise to this day Go still can't pin pointers so interop with native C libraries is a royal pain(this is something that C# and Java both support). People love to bag on C but there are domains where it can go that a GC'd language can't. I wouldn't be so quick to equate the two.
  - peterevans 9y ago
    I love C. It's the language I used when I first "got" programming, and it's stuck with me, even though I don't use much professional use for it. I don't think you can count me among those who "love to bag" on it. I don't think Go needs to be a like-for-exact-like analog of C to be a valid replacement. For many C programs, the memory management pattern they use is something that could be handled just as easily with GC, and done so in such a way as to lift a significant burden on the programmer. I mentioned this in another comment, but definitely, if you need to manage your own memory—don't use Go. I must disagree that GC disallows Go as a replacement for the language. But I will respect your opinion if you think it does!
systems 9y ago
> F# might be my favorite if it had fast compile times and native compilation. i am sure you must have heard of ocaml and reasonml .. why didn't you consider them
- gameswithgo 9y ago
  I do! Ocaml has some tough to live with syntax for me, the threading issue, and tiny ecosystem. But yes it interests me! ReasonML fixes the syntax and maybe it will lead to a bigger ecosystem, that would be great.
  - weberc2 9y ago
    I've tried ReasonML, but it's principally focused on JavaScript; support for native compilation is meager.
    - gameswithgo 9y ago
      That is too bad. I would have assumed it transpiles to OCaml as step 1 then you just Ocaml's compiler?
      - weberc2 9y ago
        It does, but the tooling for Reason->OCaml->JS is better than the tooling for Reason->OCaml->Native. Or maybe the OCaml tooling is fine and the documentation is nil. In any case, most people I asked indicated it wasn't really mature yet.
Scarbutt 9y ago
Is that it just doesn't matter very much. F# has very powerful generics, and there are particular circumstances where that saves me a lot of typing. But you can still get it done in C# with less powerful generics, or Go with none. Having less lines of code looks like a big win to me.
- gameswithgo 9y ago
  Maybe it is sometimes? Maybe not? Nobody does a great job of quantifying this stuff. Sometimes a lot of lines where each line is very simple and clear is net easier to deal with than a few very short lines that are cryptic and whose details are hidden from you. Sometimes it doesn't matter either way, because once the code is done, it works forever and you never have to touch it again. Sometimes the languages that save you lines of code cost you at runtime, or compile time, which is a loss. So I don't think it is always a big win, but maybe sometimes it is.
- peterevans 9y ago
  Expressiveness can be good–but at a conceptual cost, because you must now understand how those fewer lines of code do the same thing as a program in another language that isn't as expressive. I'm glad it's a big win for you! But in the main, I think, it's a tradeoff. Expressiveness has a cost; simplicity has a cost. Personally, I think it's best not to get too attached to specific concepts or languages, because times change, and needs change. If you're a good programmer, you can learn any language and any concept you need to.
flavio81 9y ago
>F# has sum types, and replaces null with an option type - great ideas, but you can approximate these ideas in any language if you need to. Yes, i will approximate a Formula 1 car by connecting two bicycles side to side and fitting a lawnmover motor.
- kjksf 9y ago
  And your analogy would hold if C# was to Go what a Formula 1 car is to 2 bicycles. If you insist on car analogies, Go is a good-at-most-things car. It's not the fastest car, it's not the most gas efficient car, it's not the cheapest car, it's not the best looking car, it's not the most technically advanced car but it scores in 10% percentile on all on those fundamental characteristics. Other cars are more bimodal. One car is very fast but also very expensive. Another uses the latest high-tech titanium making it very light but designers only included very small gas tank. C++ is like Homer Simpson's car: wants to have everything and ends up as a frankenstein. And I'm already regretting this car analogy because it's so unnecessary. Go gets top marks on things that matter. Fundamentals like: generates fast code, compiles quickly, has garbage collector, array bounds checking, excellent concurrency, great standard library, lots of third party libraries, generated binaries use little memory etc. Go might not have something that your favorite language X has but language X is very bad on at least one of those fundamentals. It might be 10x slower, compile code 10x slower, rely on gigantic runtime, lack any reasonable concurrency etc.
  - paulddraper 9y ago
    > Fundamentals like: generates fast code, compiles quickly, has garbage collector, array bounds checking, excellent concurrency, great standard library, lots of third party libraries, generated binaries use little memory etc. Why doesn't Java count? * Because it doesn't have "excellent concurrency"? (I posit its concurrency is far better than C, Python, Ruby, JS, or pretty much any mainstream language) * Or because "generated binaries use little memory"? (That's the stereotype and arguable, but Java is used as the primary user space language on low end, memory constrained mobile devices. AFAIK, Go can make no such claim.) * Or something else? FWIW, Java has other fundamentals like custom generic collections, standard package management system/conventions, nullable types/optionals, and a workable error strategy.
xstartup 9y ago
Can you please tell me how you implement exhaustive pattern matching which you've in F# in Go?
- paulddraper 9y ago
  if (...) { ... } else if (...) { ... } else { ... } is pretty good 99% of the time

seanwilson 9y ago

> F# has sum types, and replaces null with an option type - great ideas, but you can approximate these ideas in any language if you need to. How? You can make up for it somewhat with linters, unit tests etc. but it's tiring and nowhere near as robust as a type checker that enforces null checks for you.

gameswithgo 9y ago
oh I agree, and understand. You lose compile time enforced type safety against nulls when you approximate it, and I do think it is the right approach to use option types instead of null, and that more languages should do this. But it is just one parameter of a thousand affecting how easy it is to write good code, it sometimes has runtime costs.

peterevans 9y ago

Go is like the Six Million Dollar Man language, compared to C. It's everything C can do, but much better. Both C and Go are very, very simple languages; there aren't many keywords, and it's pretty easy to grok both at a functional level. It takes, of course, a bit to reach the second-level understanding you need to make full use of either language, but it's easy to hit the ground running in both. We sometimes get stuck on one language being better than others because it has X feature or Y concept, and I've seen some people essentially root for one language over another. But at the end of the day, languages are tools to get your work done, and on balance the work is going to be hard whichever route you go. Use the one that suits the talents you have available and that broadly complements the needs that you have.

gameswithgo 9y ago
Yes it is definitely true that coming to a nearly-complete understand of Go is very very easy compared to Rust, F#, or Nim. I haven't used it with teams of people on any way yet but I imagine it makes it somewhat easier to drop into code that isn't yours and understand it. There are less ways to create voodoo. Which can be a pro or a con, depending!
vvanders 9y ago
> It's everything C can do, but much better. Are you sure about that? I don't think you'll be running Go on an AVR. Likewise to this day Go still can't pin pointers so interop with native C libraries is a royal pain(this is something that C# and Java both support). People love to bag on C but there are domains where it can go that a GC'd language can't. I wouldn't be so quick to equate the two.
- peterevans 9y ago
  I love C. It's the language I used when I first "got" programming, and it's stuck with me, even though I don't use much professional use for it. I don't think you can count me among those who "love to bag" on it. I don't think Go needs to be a like-for-exact-like analog of C to be a valid replacement. For many C programs, the memory management pattern they use is something that could be handled just as easily with GC, and done so in such a way as to lift a significant burden on the programmer. I mentioned this in another comment, but definitely, if you need to manage your own memory—don't use Go. I must disagree that GC disallows Go as a replacement for the language. But I will respect your opinion if you think it does!

systems 9y ago

> F# might be my favorite if it had fast compile times and native compilation. i am sure you must have heard of ocaml and reasonml .. why didn't you consider them

gameswithgo 9y ago
I do! Ocaml has some tough to live with syntax for me, the threading issue, and tiny ecosystem. But yes it interests me! ReasonML fixes the syntax and maybe it will lead to a bigger ecosystem, that would be great.
- weberc2 9y ago
  I've tried ReasonML, but it's principally focused on JavaScript; support for native compilation is meager.
  - gameswithgo 9y ago
    That is too bad. I would have assumed it transpiles to OCaml as step 1 then you just Ocaml's compiler?
    - weberc2 9y ago
      It does, but the tooling for Reason->OCaml->JS is better than the tooling for Reason->OCaml->Native. Or maybe the OCaml tooling is fine and the documentation is nil. In any case, most people I asked indicated it wasn't really mature yet.

Scarbutt 9y ago

Is that it just doesn't matter very much. F# has very powerful generics, and there are particular circumstances where that saves me a lot of typing. But you can still get it done in C# with less powerful generics, or Go with none. Having less lines of code looks like a big win to me.

gameswithgo 9y ago
Maybe it is sometimes? Maybe not? Nobody does a great job of quantifying this stuff. Sometimes a lot of lines where each line is very simple and clear is net easier to deal with than a few very short lines that are cryptic and whose details are hidden from you. Sometimes it doesn't matter either way, because once the code is done, it works forever and you never have to touch it again. Sometimes the languages that save you lines of code cost you at runtime, or compile time, which is a loss. So I don't think it is always a big win, but maybe sometimes it is.
peterevans 9y ago
Expressiveness can be good–but at a conceptual cost, because you must now understand how those fewer lines of code do the same thing as a program in another language that isn't as expressive. I'm glad it's a big win for you! But in the main, I think, it's a tradeoff. Expressiveness has a cost; simplicity has a cost. Personally, I think it's best not to get too attached to specific concepts or languages, because times change, and needs change. If you're a good programmer, you can learn any language and any concept you need to.

flavio81 9y ago

>F# has sum types, and replaces null with an option type - great ideas, but you can approximate these ideas in any language if you need to. Yes, i will approximate a Formula 1 car by connecting two bicycles side to side and fitting a lawnmover motor.

kjksf 9y ago
And your analogy would hold if C# was to Go what a Formula 1 car is to 2 bicycles. If you insist on car analogies, Go is a good-at-most-things car. It's not the fastest car, it's not the most gas efficient car, it's not the cheapest car, it's not the best looking car, it's not the most technically advanced car but it scores in 10% percentile on all on those fundamental characteristics. Other cars are more bimodal. One car is very fast but also very expensive. Another uses the latest high-tech titanium making it very light but designers only included very small gas tank. C++ is like Homer Simpson's car: wants to have everything and ends up as a frankenstein. And I'm already regretting this car analogy because it's so unnecessary. Go gets top marks on things that matter. Fundamentals like: generates fast code, compiles quickly, has garbage collector, array bounds checking, excellent concurrency, great standard library, lots of third party libraries, generated binaries use little memory etc. Go might not have something that your favorite language X has but language X is very bad on at least one of those fundamentals. It might be 10x slower, compile code 10x slower, rely on gigantic runtime, lack any reasonable concurrency etc.
- paulddraper 9y ago
  > Fundamentals like: generates fast code, compiles quickly, has garbage collector, array bounds checking, excellent concurrency, great standard library, lots of third party libraries, generated binaries use little memory etc. Why doesn't Java count? * Because it doesn't have "excellent concurrency"? (I posit its concurrency is far better than C, Python, Ruby, JS, or pretty much any mainstream language) * Or because "generated binaries use little memory"? (That's the stereotype and arguable, but Java is used as the primary user space language on low end, memory constrained mobile devices. AFAIK, Go can make no such claim.) * Or something else? FWIW, Java has other fundamentals like custom generic collections, standard package management system/conventions, nullable types/optionals, and a workable error strategy.

xstartup 9y ago

Can you please tell me how you implement exhaustive pattern matching which you've in F# in Go?

paulddraper 9y ago
if (...) { ... } else if (...) { ... } else { ... } is pretty good 99% of the time