8 ms·

I like Go quite a lot. Mainly I am a Lisp programmer, so I am not looking for the next most high level programming language. I am looking for a language which g

by _ph_ 10y ago

I like Go quite a lot. Mainly I am a Lisp programmer, so I am not looking for the next most high level programming language. I am looking for a language which gets things done, where Lisp doesn't quite fit. For jobs, which traditionally would have been done in C. Programs that run fast and have a reasonable complexity. It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system. On top of that it adds memory safetey due to the presence of GC. Go it easy to learn, as its a moderately sized language, but it has just enough abstractions, that your programs are not held back by the lack of those, without opening the traps too "powerful" languages bring with themselves, namely complexety. On top of all, the whole infrastructure is very well thought out and a pleasure to use. A very fast compiler which produces static executables, a good module system without header files, a rich standard library, many things. There are quite a few quirks, especially for the beginner, but the more I gain insight, the more I agree with the choices made - with some I don't, but the agree to disagree ratio is surprisingly high. And most of them don't get into the way of writing good programs, which is what counts.

junke 10y ago
I am really curious about the kind of tasks that are easily done in Go but for which Lisp doesn't quite fit.
- _ph_ 10y ago
  Sometimes I like to have a fully statically typechecked program. You can do that in Lisp, its easier in Go. Also, it directly produces statically linked executables. You can do a lot of this in SBCL, it also produces executables, has type checking etc. But for some of this, you have to wrestle a bit with the Lisp system. The Common Lisp numeric tower is great - until you want to write low level programs where you just want to have machine word sized integers which may wrap around. I once even submitted an abstract to a Lisp conference addressing some of these issues, but as it was not accepted, this side-project was postponed (but I plan to revive it some day). And of course, there is always the question of the environment. The Go universe has tons of libraries, actively developed.
  - devishard 10y ago
    > Sometimes I like to have a fully statically typechecked program. Wait, I thought we were talking about situations where Go was appropriate. What do you use when you want a fully statically typechecked program?
    - scott_s 10y ago
      Please don't do this. You obviously disagree that Go is a language which provides full static typechecking. Please instead just state that disagreement, rather than feign confusion. It leads to much better discussions.
      - premium-concern 10y ago
        Why do Go advocates never have any technical response to facts they dislike, but always respond with complaints about the tone in which the fact was voiced?
      - devishard 10y ago
        We would have a lot better discussions if people bothered to educate themselves about static typechecking before making claims about it on Hacker News.
        scott_s 10y ago
        HN advocates the principle of charity - assuming the best possible intentions of the people you're talking to. In this case, that would mean assuming this person means something different when they use the phrase "fully statically typechecked", stating what you mean when you say it, and possibly linking to some source material to help further explain. It's quite possible they have the same understanding you do, they just are using the terms differently.
        devishard 10y ago
        Okay, why don't you assume in everything I'm talking about fluffy rainbow butterflies or something nice like that? Principle of charity, right? That way we can both go our separate ways happily. If someone doesn't mean "fully statically typechecked" then they shouldn't say "fully statically typechecked". It's not an ambiguous phrase.
pjmlp 10y ago
> It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system. On top of that it adds memory safetey due to the presence of GC. Wirth's work also includes languages with GC. :)
- coldtea 10y ago
  And more modern features than Go, even if designed in the 90s...
  - _ph_ 10y ago
    Out of genuine interest: could you elaborate on those? I have mainly worked with Pascal/Modula-2, and only shortly glanced at Oberon, so I am a bit shaky on his "later works".
    - pjmlp 10y ago
      I don't have much time to explain them in detail now, but can quickly provide some links: Check Active Oberon: http://www.ocp.inf.ethz.ch/wiki/Documentation/Language http://www.ocp.inf.ethz.ch/wiki/Documentation/Language Component Pascal is a Oberon-2 derivative but Wirth hasn't collaborated much there: http://www.oberon.ch/blackbox.html http://www.oberon.ch/blackbox.html They made the very last version available for free. It was a kind of Delphi like, with the Oberon ideas of full stack OS. www.pas.rochester.edu/~skulski/Presentations/BB_Class.pdf
devishard 10y ago
This post is yet another reinforcement of my assertion that the people who like Go only like it because they have no idea what has happened in programming languages for the last few decades. Case in point: > It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system. Strict type checking? Have you used any other languages besides C? Go's type system is a joke. Like literally, it's a joke. If you get a bunch of people who know about types languages in a room discussing types, "What about Go?" is guaranteed to get a laugh.
- jsmith0295 10y ago
  Maybe if by "people who know about types languages" you mean "Haskell snobs"
  - spion 10y ago
    But also ML, Scala, C++, C#, Java, TypeScript, Hack, Dart, Swift, Objective C (as of late), Visual Basic... and COBOL snobs.
    - jsmith0295 10y ago
      I was referring more to the "joke" part of this. Just because a type system offers slightly more safety doesn't make it better. I'm primarily a Java developer, and I would prefer Go's type system over Java's the vast majority of the time. It does a much better job at staying out of the way.
      - spion 10y ago
        That may be true, but the joke part comes when you actually want to develop new abstractions that are type-safe. For example you cant write a thread-safe map container in Go without sacrificing type safety (i.e. one that would not crash the program when there are concurrent writes to the map). The standard library doesn't offer one either. This means you end up copy pasting the lock related code for every map you want to make thread safe. You have to remember to declare and initialise its lock, to use that lock every time you access it, and to remember to unlock it. Now for some things, this cost isn't too bad. For others, it makes the language a joke. As a result, Go is a toy, or at least, a non-general-purpose language. If the problem you're solving fits its limited set of built-in abstractions, its great. Otherwise, its a disaster. In my experience, well written programs evolve over time to gain new carefully chosen abstractions that cleanly implement shared underlying concepts of the problem domain. These abstractions often require the use of generics. When this happens in a Go project, however, you're out of luck. Even worse, developing primarily in Go means distorting your thinking to fit its limits. This is more or less true in any language, and its not a binary thing. Languages are all over the place on the ladder of abstraction (with lisps being close to the top, Go near the bottom). p.s. Java also suffers because it added generics too late: by the time they were added there was already a clear picture painted of "idiomatic Java". To make matters worse lambdas were also added way too late, and the verbosity of type declarations is still staggeringly high. However, modern Java is a much better language than Go.
comex 10y ago
Heh: my initial thought was that Go is nothing like Lisp - Lisp has the most powerful metaprogramming around thanks to its macro system, while Go doesn't even have C-level macros, or any of the type-system features some languages use as an alternative approach to metaprogramming. As a result Lisp is notoriously unopinionated, while Go is very opinionated. Lisp is functional, Go is aggressively imperative. And so on. But I guess the languages share some things: no complex type system, fast compiles, emphasis on simplicity in general, no need for an IDE, old fashioned feel (no, really, that's not a diss necessarily)... and at least Go has reflection.
- junke 10y ago
  > Lisp is functional Not really, multi-paradigm. > and at least Go has reflection. Go is introspective. Lisp has both introspection (e.g. find-class allows to look at existing classes) and intercession (e.g. ensure-class creates/modifies a class at runtime).
  - comex 10y ago
    > Not really, multi-paradigm. Yeah, that's probably a better way to describe it; it certainly ain't Haskell. But Go really doesn't want you even to use things like map and filter.

by _ph_ 10y ago

junke 10y ago

I am really curious about the kind of tasks that are easily done in Go but for which Lisp doesn't quite fit.

_ph_ 10y ago
Sometimes I like to have a fully statically typechecked program. You can do that in Lisp, its easier in Go. Also, it directly produces statically linked executables. You can do a lot of this in SBCL, it also produces executables, has type checking etc. But for some of this, you have to wrestle a bit with the Lisp system. The Common Lisp numeric tower is great - until you want to write low level programs where you just want to have machine word sized integers which may wrap around. I once even submitted an abstract to a Lisp conference addressing some of these issues, but as it was not accepted, this side-project was postponed (but I plan to revive it some day). And of course, there is always the question of the environment. The Go universe has tons of libraries, actively developed.
- devishard 10y ago
  > Sometimes I like to have a fully statically typechecked program. Wait, I thought we were talking about situations where Go was appropriate. What do you use when you want a fully statically typechecked program?
  - scott_s 10y ago
    Please don't do this. You obviously disagree that Go is a language which provides full static typechecking. Please instead just state that disagreement, rather than feign confusion. It leads to much better discussions.
    - premium-concern 10y ago
      Why do Go advocates never have any technical response to facts they dislike, but always respond with complaints about the tone in which the fact was voiced?
    - devishard 10y ago
      We would have a lot better discussions if people bothered to educate themselves about static typechecking before making claims about it on Hacker News.
      - scott_s 10y ago
        HN advocates the principle of charity - assuming the best possible intentions of the people you're talking to. In this case, that would mean assuming this person means something different when they use the phrase "fully statically typechecked", stating what you mean when you say it, and possibly linking to some source material to help further explain. It's quite possible they have the same understanding you do, they just are using the terms differently.
        devishard 10y ago
        Okay, why don't you assume in everything I'm talking about fluffy rainbow butterflies or something nice like that? Principle of charity, right? That way we can both go our separate ways happily. If someone doesn't mean "fully statically typechecked" then they shouldn't say "fully statically typechecked". It's not an ambiguous phrase.

pjmlp 10y ago

> It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system. On top of that it adds memory safetey due to the presence of GC. Wirth's work also includes languages with GC. :)

coldtea 10y ago
And more modern features than Go, even if designed in the 90s...
- _ph_ 10y ago
  Out of genuine interest: could you elaborate on those? I have mainly worked with Pascal/Modula-2, and only shortly glanced at Oberon, so I am a bit shaky on his "later works".
  - pjmlp 10y ago
    I don't have much time to explain them in detail now, but can quickly provide some links: Check Active Oberon: http://www.ocp.inf.ethz.ch/wiki/Documentation/Language http://www.ocp.inf.ethz.ch/wiki/Documentation/Language Component Pascal is a Oberon-2 derivative but Wirth hasn't collaborated much there: http://www.oberon.ch/blackbox.html http://www.oberon.ch/blackbox.html They made the very last version available for free. It was a kind of Delphi like, with the Oberon ideas of full stack OS. www.pas.rochester.edu/~skulski/Presentations/BB_Class.pdf

devishard 10y ago

This post is yet another reinforcement of my assertion that the people who like Go only like it because they have no idea what has happened in programming languages for the last few decades. Case in point: > It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system. Strict type checking? Have you used any other languages besides C? Go's type system is a joke. Like literally, it's a joke. If you get a bunch of people who know about types languages in a room discussing types, "What about Go?" is guaranteed to get a laugh.

jsmith0295 10y ago
Maybe if by "people who know about types languages" you mean "Haskell snobs"
- spion 10y ago
  But also ML, Scala, C++, C#, Java, TypeScript, Hack, Dart, Swift, Objective C (as of late), Visual Basic... and COBOL snobs.
  - jsmith0295 10y ago
    I was referring more to the "joke" part of this. Just because a type system offers slightly more safety doesn't make it better. I'm primarily a Java developer, and I would prefer Go's type system over Java's the vast majority of the time. It does a much better job at staying out of the way.
    - spion 10y ago
      That may be true, but the joke part comes when you actually want to develop new abstractions that are type-safe. For example you cant write a thread-safe map container in Go without sacrificing type safety (i.e. one that would not crash the program when there are concurrent writes to the map). The standard library doesn't offer one either. This means you end up copy pasting the lock related code for every map you want to make thread safe. You have to remember to declare and initialise its lock, to use that lock every time you access it, and to remember to unlock it. Now for some things, this cost isn't too bad. For others, it makes the language a joke. As a result, Go is a toy, or at least, a non-general-purpose language. If the problem you're solving fits its limited set of built-in abstractions, its great. Otherwise, its a disaster. In my experience, well written programs evolve over time to gain new carefully chosen abstractions that cleanly implement shared underlying concepts of the problem domain. These abstractions often require the use of generics. When this happens in a Go project, however, you're out of luck. Even worse, developing primarily in Go means distorting your thinking to fit its limits. This is more or less true in any language, and its not a binary thing. Languages are all over the place on the ladder of abstraction (with lisps being close to the top, Go near the bottom). p.s. Java also suffers because it added generics too late: by the time they were added there was already a clear picture painted of "idiomatic Java". To make matters worse lambdas were also added way too late, and the verbosity of type declarations is still staggeringly high. However, modern Java is a much better language than Go.

comex 10y ago

Heh: my initial thought was that Go is nothing like Lisp - Lisp has the most powerful metaprogramming around thanks to its macro system, while Go doesn't even have C-level macros, or any of the type-system features some languages use as an alternative approach to metaprogramming. As a result Lisp is notoriously unopinionated, while Go is very opinionated. Lisp is functional, Go is aggressively imperative. And so on. But I guess the languages share some things: no complex type system, fast compiles, emphasis on simplicity in general, no need for an IDE, old fashioned feel (no, really, that's not a diss necessarily)... and at least Go has reflection.

junke 10y ago
> Lisp is functional Not really, multi-paradigm. > and at least Go has reflection. Go is introspective. Lisp has both introspection (e.g. find-class allows to look at existing classes) and intercession (e.g. ensure-class creates/modifies a class at runtime).
- comex 10y ago
  > Not really, multi-paradigm. Yeah, that's probably a better way to describe it; it certainly ain't Haskell. But Go really doesn't want you even to use things like map and filter.