8 ms·

I've seen the charm suite on HN before, and everytime I see them I wish they had bindings to other languages. I'm just not interested in Go, but I'm really inte

I've seen the charm suite on HN before, and everytime I see them I wish they had bindings to other languages. I'm just not interested in Go, but I'm really interested in learning to create ssh applications. Its an application runtime with a lot of potential for the dev space, but almost no quick-start frameworks!

shirogane86x 4y ago
if you need a fun language to learn to make TUIs, haskell has the brick library :) . I've heard very good things about it, it's declarative, only downside is that it doesn't support windows.
kelvie 4y ago
Why not? There's a lot to hate about every language, but one advantage about Go is that it's fairly easy to context switch in/out of, which makes it great for side projects, because it's cognitive load while using it is really low. Unlike say, Rust. I do love Rust though.
- nepeckman 4y ago
  I'm only really interested in learning a language if it excites me, or if I'm getting paid to do it. I don't hate Go, and would be fine to learn it on company time for company projects, but there is no spark that would lead me to learn the language on my own. I've written some basic Go, but if I'm using it in personal projects, I'd would have to invest time to understand the ecosystem, runtime, standard lib, best practices, etc.
  - pstuart 4y ago
    It's not exciting but it is pleasing. The ecosystem is refining well (e.g., $GOPATH deprecated and workspaces just added). Now with generics there's even less to complain about.
    - anyfoo 4y ago
      It's not really very pleasant if you are used to modern type systems. It feels antiquated in a limiting way, for no good reason. With C at least it's clear to me that it's literally (very literally) a 50 years old language, and I've gotten used to it after decades. It's far from ideal, but at least there's some deep familiarity, and that coupled with the fact that it's everywhere makes me feel more tolerant of it. But learning a new language which is, in some ways, stuck in the same past as that established 50 years old language is not very pleasing.
      - nemo1618 4y ago
        > for no good reason When a language has some property that surprises you, consider whether it might have been designed that way on purpose, not simply because the creators were ignorant/lazy/negligent/drunk/lost a bet/etc.
        kaba0 4y ago
        > creators were ignorant/lazy/negligent/drunk/lost a bet/etc. This is not a well-intended comment, but then why didn't they add generics at the start? It's not like it was a surprise to anyone even remotely familiar with PLs that they will have to retrofit it sooner or later. Also, function-scoped defers instead of surrounding braces-based one? Come on...
        pstuart 4y ago
        They were very clear about why generics weren't there for a long time -- they weren't sure how to do it and keep things simple and build quickly. I'm just a simple code monkey but I think they did a decent job with it.
        philosopher1234 4y ago
        Not adding generics, if you dig through the archives, was a pragmatic choice. Partly it was to help the process of language design, partly it was project management, and partly it was due to technical constraints. Generics is a big, complex feature. The team was prioritizing getting the most immediately valuable features shipped first, and didn’t want the introduction of generics to hit their limited resources too hard or distract from getting the fundamentals right. Generics implementations in existing languages at the time also made trade offs/interactions that weren’t appropriate for go.
  - ryukoposting 4y ago
    This is roughly my take. Between Nim and Rust, I have no purpose for Go that isn't covered by a language that's flat-out better.
    - philosopher1234 4y ago
      They’re not better.
      - mixedCase 4y ago
        People tend to disagree on that. But it depends on what you value. If you like a language that helps you write robust and expressive code, Go doesn't score as high as any language with sum types, and good "generics" support (which 1.18 does not have).
  - lazyier 4y ago
    Being boring is one of Golang's strongest suits. There just isn't a whole lot you need to learn compared to most languages.
  - naikrovek 4y ago
    > but there is no spark that would lead me to learn the language on my own. you just said you wanted to write SSH apps. is that not enough of a spark?
- Klonoar 4y ago
  What exactly is hard to switch in/out of Rust, context-wise...?
  - LanceH 4y ago
    You get interrupted every time a post is made about Go and you have to comment on Rust's superiority.
    - Klonoar 4y ago
      We both know that's not what I did, and I'm not taking the bait. Have a good day. ;)
      - LanceH 4y ago
        Not directed at you, but here we are in a post about a CLI for Go, discussing Rust. It seems like every discussion of something related to Go requires someone to screech about safety (again, not you) and how Go is a terrible choice. I use both weekly, for different things. There are numerous people who don't use Go at all that are in Go specific forums. They read Go specific threads here on HN just to make their Rust points. I poke fun at them with my statement. You just gave me the hook. :) smiley face for you
- ebingdom 4y ago
  I just can't get past the fact that Go doesn't have sum types. As someone who dabbles in category theory, it makes no sense to me that so many popular languages have product types but not their categorical dual. The lack of sum types leads to so many hacks and weird design patterns in the language, like returning two values when you only want the caller to read one of them (that is actually Go's error handling strategy!). To work around the limitations of not having sum types, Go has a "zero" value for every type so you can for example only set the fields relevant to your particular use case, and just hope that no one reads the fields you didn't set. The problem is that sometimes the zero value is valid, but not special in any way and doesn't make sense as the default. Go has arbitrarily decided that one particular value is special without your blessing or the ability to override it. This leads to bugs in which the zero value shows up in places where you don't expect it, simply because there is some code which doesn't explicitly set it. That's a very easy mistake to make, which makes writing Go an error prone activity. I shudder to think that there's probably some Go program that deals with money, and a user's balance might be cleared to zero simply because some operation forgot to explicitly set it in some struct. In order to implement "optional" fields in Go where you want to distinguish between zero (a valid value) and none (a missing value), the common solution is to either put the integer behind a pointer (which can be null) or use some "sentinel" value like -1 to indicate that the value is missing (as long as that sentinel value isn't actually valid in the domain of discourse). These are terrible hacks, but exactly what you'd expect from programmers who spent the majority of their careers writing C. This design also leads to another kind of issue: sometimes you don't want people to be able to construct values of a particular type without going through a constructor which ensures the relevant invariants hold. This concept ("smart constructors") is widely used in other programming languages, but it's impossible in Go because Go allows anyone to construct an inhabitant of any type simply by declaring a variable of that type. A simple example of that kind of issue is pointers: in (safe) Rust, references are guaranteed to be non-null, and you use sum types to implement optionality. This is great because you can always dereference a reference and not worry about handling the null case. In Go, all pointer types have that nasty zero value (null), and there's nothing you can do about it. The billion dollar mistake. I like the fact that Go encourages simplicity, and for the most part the language is fine. But I'm convinced that having every type be pointed rather than supporting proper sum types is actually more complex in terms of the implications it has on writing and reasoning about code. They have mistaken minimality for simplicity.

shirogane86x 4y ago

if you need a fun language to learn to make TUIs, haskell has the brick library :) . I've heard very good things about it, it's declarative, only downside is that it doesn't support windows.

kelvie 4y ago

Why not? There's a lot to hate about every language, but one advantage about Go is that it's fairly easy to context switch in/out of, which makes it great for side projects, because it's cognitive load while using it is really low. Unlike say, Rust. I do love Rust though.

nepeckman 4y ago
I'm only really interested in learning a language if it excites me, or if I'm getting paid to do it. I don't hate Go, and would be fine to learn it on company time for company projects, but there is no spark that would lead me to learn the language on my own. I've written some basic Go, but if I'm using it in personal projects, I'd would have to invest time to understand the ecosystem, runtime, standard lib, best practices, etc.
- pstuart 4y ago
  It's not exciting but it is pleasing. The ecosystem is refining well (e.g., $GOPATH deprecated and workspaces just added). Now with generics there's even less to complain about.
  - anyfoo 4y ago
    It's not really very pleasant if you are used to modern type systems. It feels antiquated in a limiting way, for no good reason. With C at least it's clear to me that it's literally (very literally) a 50 years old language, and I've gotten used to it after decades. It's far from ideal, but at least there's some deep familiarity, and that coupled with the fact that it's everywhere makes me feel more tolerant of it. But learning a new language which is, in some ways, stuck in the same past as that established 50 years old language is not very pleasing.
    - nemo1618 4y ago
      > for no good reason When a language has some property that surprises you, consider whether it might have been designed that way on purpose, not simply because the creators were ignorant/lazy/negligent/drunk/lost a bet/etc.
      - kaba0 4y ago
        > creators were ignorant/lazy/negligent/drunk/lost a bet/etc. This is not a well-intended comment, but then why didn't they add generics at the start? It's not like it was a surprise to anyone even remotely familiar with PLs that they will have to retrofit it sooner or later. Also, function-scoped defers instead of surrounding braces-based one? Come on...
        pstuart 4y ago
        They were very clear about why generics weren't there for a long time -- they weren't sure how to do it and keep things simple and build quickly. I'm just a simple code monkey but I think they did a decent job with it.
        philosopher1234 4y ago
        Not adding generics, if you dig through the archives, was a pragmatic choice. Partly it was to help the process of language design, partly it was project management, and partly it was due to technical constraints. Generics is a big, complex feature. The team was prioritizing getting the most immediately valuable features shipped first, and didn’t want the introduction of generics to hit their limited resources too hard or distract from getting the fundamentals right. Generics implementations in existing languages at the time also made trade offs/interactions that weren’t appropriate for go.
- ryukoposting 4y ago
  This is roughly my take. Between Nim and Rust, I have no purpose for Go that isn't covered by a language that's flat-out better.
  - philosopher1234 4y ago
    They’re not better.
    - mixedCase 4y ago
      People tend to disagree on that. But it depends on what you value. If you like a language that helps you write robust and expressive code, Go doesn't score as high as any language with sum types, and good "generics" support (which 1.18 does not have).
- lazyier 4y ago
  Being boring is one of Golang's strongest suits. There just isn't a whole lot you need to learn compared to most languages.
- naikrovek 4y ago
  > but there is no spark that would lead me to learn the language on my own. you just said you wanted to write SSH apps. is that not enough of a spark?
Klonoar 4y ago
What exactly is hard to switch in/out of Rust, context-wise...?
- LanceH 4y ago
  You get interrupted every time a post is made about Go and you have to comment on Rust's superiority.
  - Klonoar 4y ago
    We both know that's not what I did, and I'm not taking the bait. Have a good day. ;)
    - LanceH 4y ago
      Not directed at you, but here we are in a post about a CLI for Go, discussing Rust. It seems like every discussion of something related to Go requires someone to screech about safety (again, not you) and how Go is a terrible choice. I use both weekly, for different things. There are numerous people who don't use Go at all that are in Go specific forums. They read Go specific threads here on HN just to make their Rust points. I poke fun at them with my statement. You just gave me the hook. :) smiley face for you
ebingdom 4y ago
I just can't get past the fact that Go doesn't have sum types. As someone who dabbles in category theory, it makes no sense to me that so many popular languages have product types but not their categorical dual. The lack of sum types leads to so many hacks and weird design patterns in the language, like returning two values when you only want the caller to read one of them (that is actually Go's error handling strategy!). To work around the limitations of not having sum types, Go has a "zero" value for every type so you can for example only set the fields relevant to your particular use case, and just hope that no one reads the fields you didn't set. The problem is that sometimes the zero value is valid, but not special in any way and doesn't make sense as the default. Go has arbitrarily decided that one particular value is special without your blessing or the ability to override it. This leads to bugs in which the zero value shows up in places where you don't expect it, simply because there is some code which doesn't explicitly set it. That's a very easy mistake to make, which makes writing Go an error prone activity. I shudder to think that there's probably some Go program that deals with money, and a user's balance might be cleared to zero simply because some operation forgot to explicitly set it in some struct. In order to implement "optional" fields in Go where you want to distinguish between zero (a valid value) and none (a missing value), the common solution is to either put the integer behind a pointer (which can be null) or use some "sentinel" value like -1 to indicate that the value is missing (as long as that sentinel value isn't actually valid in the domain of discourse). These are terrible hacks, but exactly what you'd expect from programmers who spent the majority of their careers writing C. This design also leads to another kind of issue: sometimes you don't want people to be able to construct values of a particular type without going through a constructor which ensures the relevant invariants hold. This concept ("smart constructors") is widely used in other programming languages, but it's impossible in Go because Go allows anyone to construct an inhabitant of any type simply by declaring a variable of that type. A simple example of that kind of issue is pointers: in (safe) Rust, references are guaranteed to be non-null, and you use sum types to implement optionality. This is great because you can always dereference a reference and not worry about handling the null case. In Go, all pointer types have that nasty zero value (null), and there's nothing you can do about it. The billion dollar mistake. I like the fact that Go encourages simplicity, and for the most part the language is fine. But I'm convinced that having every type be pointed rather than supporting proper sum types is actually more complex in terms of the implications it has on writing and reasoning about code. They have mistaken minimality for simplicity.