6 ms·

I'be been mulling over a similar concept for a while, really excited for this. Go has such great tooling and a nice ecosystem, but could use some language impr

by cgag 11y ago

I'be been mulling over a similar concept for a while, really excited for this. Go has such great tooling and a nice ecosystem, but could use some language improvements, like coffeescript or the alt JVM languages. I really want sum types, strict semantics, and untyped IO, and a good ecosystem.

KirinDave 11y ago
I don't understand how you can say Go has great tooling when tooling is one of the single biggest difficulties the language has. It's story of building and dependency management is one of its major areas of growth in the last 2 releases because the developers agree.
- boulos 11y ago
  You don't think go build, go fmt, etc. are great? I agree there are deficiencies, but a lot of my day to day (admittedly in emacs) is pretty great.
  - JBReefer 11y ago
    Those are nice, but "great tooling" is Visual Studio or better, at a minimum.
    - KirinDave 11y ago
      Not all languages with VS support or even VSC support have "great tooling." It's a very complicated set of balances and acceptance criterion.
    - KirinDave 11y ago
      Not all languages with VS support or even VSC support have "great tooling." It's a very complicated set of balances and acceptance criterion.
    - KirinDave 11y ago
      Not all languages with VS support or even VSC support have "great tooling." It's a very complicated set of balances and acceptance criterion.
  - KirinDave 11y ago
    The compiler is very fast, and in absence of interactive development that's good. The cross compilation is also a thing I guess? I just use docker anyways. But no... I mean... I can get a lot of editors to do a better job of formatting. Other languages I use offer true interactive development. And go build requires a Zigguraut Of Filesystem around it to function properly. Go get provides no realistic versioning other than "this is what I grabbed RIGHT NOW and I hope you don't need bugfixes because good luck with figuring out the hash I got." The lack of reproducible builds and better tooling for versioning is a pretty damning stroke against the ecosystem, because I nearly lost a project when my HD crashed. I had my repo checked in AND go deps set up and it still took me a solid day of wrangling to recover a project. For all my kvetching about bower and maven, when I set them up they tend to stay set up and so the right thing. Go projects decay. Add that to the language's total punt on error handling and sync semantics so crazy that the ecosystem got a basic race detector before a basic interactive execution tool... I just don't get why this ecosystem has adherents.
    - jzelinskie 11y ago
      >The cross compilation is also a thing I guess? I just use docker anyways. Docker does not make anything crossplatform; it just enables you to package your dependencies such that you can easily run on any other linux-amd64 machine. Go applications usually don't have many dependencies so Docker usually doesn't buy you much if anything at all. >But no... I mean... I can get a lot of editors to do a better job of formatting. I've never used a language with an ecosystem that so adamantly abided by one standard format. PEP8 comes somewhat close, but there are still fights over different linters etc... >Go get provides no realistic versioning other than "this is what I grabbed RIGHT NOW The vendor directory introduced in Go 1.6 (and usable in Go 1.5) has addressed the versioning issue with `go get`. I agree creating/updating vendored dependencies can be tricky depending on the tool you use and having a Go workspace per project is slightly cumbersome (though no less cumbersome than say virtualenv), but even before Go "officially" supported vendoring, going from zero to development is literally just `git clone` and `godep restore`. Go projects do not decay if you've vendored your dependencies. >so crazy that the ecosystem got a basic race detector before a basic interactive execution tool... Am I crazy that I prefer having a race detector over a REPL? There were plenty of REPL projects that never gained traction because you can develop pretty easily without them. I usually jump into the playground[0] if I need to test something. This has the added advantage of being sharable after I write it, too. [0]: https://play.golang.org https://play.golang.org
- cgag 11y ago
  I mostly mean vim-go and all the tools it relies on. Dependency management is awful. All the IDE-like features that actually work well in vim are great.
deleted 11y ago
[deleted]
KirinDave 11y ago
I don't understand how you can say Go has great tooling when tooling is one of the single biggest difficulties the language has. It's story of building and dependency management is one of its major areas of growth in the last 2 releases because the developers agree.
rntz 11y ago
What do you mean by "strict semantics"? As a PL researcher, I associate "strict" with eager (as opposed to lazy) evaluation, but Go is eager, so you can't mean that.
- scythe 11y ago
  A lot of people say this to mean that object types can't be set to nil. The classic fix is to implement parametrized types (which Go has resisted), although since Go is rabid about simplicity and puts a low priority on generality (generic maps but no other containers, automatic JSON but no other serializations, actor model keywords but no other concurrency primitives, type switch but no real pattern matching), it might better fit the Go philosophy to define only one kind of fallible type, like maybe[T], which is always either T or an error.
  - aikah 11y ago
    > generic maps but no other containers Yet it feels like magics. Why just maps? why not sets, with useful set methods ? (union...) . It doesn't feel consistant in a statically typed language. It also feel like a mistrust of the developer. Go doesn't trust me enough so I can implement my own typesafe containers ? or does Go asks me to do the compiler's job by writing code generation tools ? And there is no maybe[T] or we wouldn't need multiple return values when dealing with errors. If there was a maybe[T], we could chain functions and only deal with errors in the last return statement.
    - cpalone 11y ago
      > Why just maps? why not sets, with useful set methods ? Having programmed in Go for production a while now, in my experience it's rarely necessary. Sometimes a set is needed, but it's very simple to just use a map[T]struct{}. And if something like union or intersect is needed it's usually less than 20 lines to implement all those operations. Usually that operation is only needed in one instance, and it's very quick to write. Would it be faster to have a builtin generic set? Absolutely, but it's such a small inconvenience I honestly don't care.
  - 11y ago
cyphar 11y ago
In what way does Go have great tooling? Your compiler doing dependency management is one of the worst things that Go did (and I'm sure they'd do it differently if they could have their time again). It makes packaging libraries impossible, it caused the whole vendoring thing to happen. If you're talking about gofmt or govet, C has had stuff like that for years. Go's main selling point IMO is that they have added as little to the basic "C" language as possible while also adding as many updated semantics and concepts as possible.
- goldbrick 11y ago
  I suspect you are just hating. The fact that you immediately glom onto the dependency management issue which EVERYONE KNOWS AND KEN AND ROB ARE REALLY SORRY YALL and also try to cut gofmt and govet off at the pass, which come on, let's be real, the fact that something exists that might remotely resemble those concepts is an extremely fucking far cry from them being standard community practices which if you don't see the value of that then you never dealt with other people's C code... indicates that you know in your heart of hearts exactly how great Go's tooling is. go run, go test, go build, boom! so simple. Oh and might I mention the race detector? Fucking incredible, C never dreamed of something like that. There are plenty of good third-party options available for dependency management (nice double standard btw since you apparently have no problem with third-party stuff for fmt/vet/lint concerns) and there is also this https://golang.org/cmd/go/#hdr-Vendor_Directories https://golang.org/cmd/go/#hdr-Vendor_Directories so a better world is coming don't you fret.
  - pcwalton 11y ago
    > Oh and might I mention the race detector? Fucking incredible, C never dreamed of something like that. go race is pretty much a port of Thread Sanitizer, which was a C tool. Before that, there was Helgrind, also a C tool. All of these tools have a long list of forerunners in academia, largely for Java (Eraser, FastTrack, etc.)
    - goldbrick 11y ago
      go race is Thread Sanitizer, in fact, but see again my point about being part of the community best practice vs. a third-party tool you may or may not have heard of. Eraser and FastTrack are un-googleable, if you have any links they would be appreciated.
amelius 11y ago
> Go has such great tooling and a nice ecosystem, but could use some language improvements, like coffeescript or the alt JVM languages. I'd like to see a language that compiles to Go, but also to Javascript, so that code can run on both client and server without changes. That language should not equal Go, because, honestly, some aspects of this language are quite strange: https://golang.org/doc/faq#nil_error https://golang.org/doc/faq#nil_error
- Vendan 11y ago
  Note that that issue makes perfect sense, and the odds of it affecting you are very very very small. I've written a lot of go code, and have never been affected by it.
- dmix 11y ago
  Gopher is a Go->Javascript compiler https://github.com/gopherjs/gopherjs https://github.com/gopherjs/gopherjs
lomnakkus 11y ago
So... GHC Haskell, really? The deployment profile, at least, is identical to Go in that you can just link statically and copy the binary. I mean, I don't necessarily condone it, but if you're into "recipe programming" you can just use the Turtle package/modules and get pretty far. The tutorial is pretty amazing. I'm not saying it's a bad thing, necessarily, but I'm one of those crazy people who thinks that a little bit of cogitation should be (and is!) rewarded. Maybe I'm wrong. EDIT: Oh, wait, you said "untyped IO". What does that mean, I wonder?
- cgag 11y ago
  I want strictness by default too. Looking forward to the strict pragma and using it everywhere. I kind of want Ocaml with a Go sized ecosystem.
  - lomnakkus 11y ago
    I don't know if this will be of interest, but I actually started my FP "journey" using O'Caml, oh (pun!) 10-15 years ago, but once I actually learned Haskell for real I didn't look back. There was just no contest. I've actually written a couple of pretty cool libraries for O'Caml that gained some traction in the community, way back when... which is a long-winded way of saying that I'm not a noob when it comes to O'Caml, so it's not that I don't understand what it can do for you :) (I appreciate that people may have different requirements; mine were and are mostly around my own productivity -- not so much real-time/low-latency/predictable performance/etc.).
nikolay 11y ago
BTW, JVM already has a Haskell - it's called Frege [0]. Here are the difference between it and the real deal: [1]. It has a playground, too [2]. [0]: http://www.frege-lang.org/ http://www.frege-lang.org/ [1]: https://github.com/Frege/frege/wiki/Differences-between-Frege-and-Haskell https://github.com/Frege/frege/wiki/Differences-between-Freg... [2]: http://try.frege-lang.org/ http://try.frege-lang.org/

by cgag 11y ago

KirinDave 11y ago

I don't understand how you can say Go has great tooling when tooling is one of the single biggest difficulties the language has. It's story of building and dependency management is one of its major areas of growth in the last 2 releases because the developers agree.

boulos 11y ago
You don't think go build, go fmt, etc. are great? I agree there are deficiencies, but a lot of my day to day (admittedly in emacs) is pretty great.
- JBReefer 11y ago
  Those are nice, but "great tooling" is Visual Studio or better, at a minimum.
  - KirinDave 11y ago
    Not all languages with VS support or even VSC support have "great tooling." It's a very complicated set of balances and acceptance criterion.
  - KirinDave 11y ago
    Not all languages with VS support or even VSC support have "great tooling." It's a very complicated set of balances and acceptance criterion.
  - KirinDave 11y ago
    Not all languages with VS support or even VSC support have "great tooling." It's a very complicated set of balances and acceptance criterion.
- KirinDave 11y ago
  The compiler is very fast, and in absence of interactive development that's good. The cross compilation is also a thing I guess? I just use docker anyways. But no... I mean... I can get a lot of editors to do a better job of formatting. Other languages I use offer true interactive development. And go build requires a Zigguraut Of Filesystem around it to function properly. Go get provides no realistic versioning other than "this is what I grabbed RIGHT NOW and I hope you don't need bugfixes because good luck with figuring out the hash I got." The lack of reproducible builds and better tooling for versioning is a pretty damning stroke against the ecosystem, because I nearly lost a project when my HD crashed. I had my repo checked in AND go deps set up and it still took me a solid day of wrangling to recover a project. For all my kvetching about bower and maven, when I set them up they tend to stay set up and so the right thing. Go projects decay. Add that to the language's total punt on error handling and sync semantics so crazy that the ecosystem got a basic race detector before a basic interactive execution tool... I just don't get why this ecosystem has adherents.
  - jzelinskie 11y ago
    >The cross compilation is also a thing I guess? I just use docker anyways. Docker does not make anything crossplatform; it just enables you to package your dependencies such that you can easily run on any other linux-amd64 machine. Go applications usually don't have many dependencies so Docker usually doesn't buy you much if anything at all. >But no... I mean... I can get a lot of editors to do a better job of formatting. I've never used a language with an ecosystem that so adamantly abided by one standard format. PEP8 comes somewhat close, but there are still fights over different linters etc... >Go get provides no realistic versioning other than "this is what I grabbed RIGHT NOW The vendor directory introduced in Go 1.6 (and usable in Go 1.5) has addressed the versioning issue with `go get`. I agree creating/updating vendored dependencies can be tricky depending on the tool you use and having a Go workspace per project is slightly cumbersome (though no less cumbersome than say virtualenv), but even before Go "officially" supported vendoring, going from zero to development is literally just `git clone` and `godep restore`. Go projects do not decay if you've vendored your dependencies. >so crazy that the ecosystem got a basic race detector before a basic interactive execution tool... Am I crazy that I prefer having a race detector over a REPL? There were plenty of REPL projects that never gained traction because you can develop pretty easily without them. I usually jump into the playground[0] if I need to test something. This has the added advantage of being sharable after I write it, too. [0]: https://play.golang.org https://play.golang.org
cgag 11y ago
I mostly mean vim-go and all the tools it relies on. Dependency management is awful. All the IDE-like features that actually work well in vim are great.

deleted 11y ago

[deleted]

KirinDave 11y ago

rntz 11y ago

What do you mean by "strict semantics"? As a PL researcher, I associate "strict" with eager (as opposed to lazy) evaluation, but Go is eager, so you can't mean that.

scythe 11y ago
A lot of people say this to mean that object types can't be set to nil. The classic fix is to implement parametrized types (which Go has resisted), although since Go is rabid about simplicity and puts a low priority on generality (generic maps but no other containers, automatic JSON but no other serializations, actor model keywords but no other concurrency primitives, type switch but no real pattern matching), it might better fit the Go philosophy to define only one kind of fallible type, like maybe[T], which is always either T or an error.
- aikah 11y ago
  > generic maps but no other containers Yet it feels like magics. Why just maps? why not sets, with useful set methods ? (union...) . It doesn't feel consistant in a statically typed language. It also feel like a mistrust of the developer. Go doesn't trust me enough so I can implement my own typesafe containers ? or does Go asks me to do the compiler's job by writing code generation tools ? And there is no maybe[T] or we wouldn't need multiple return values when dealing with errors. If there was a maybe[T], we could chain functions and only deal with errors in the last return statement.
  - cpalone 11y ago
    > Why just maps? why not sets, with useful set methods ? Having programmed in Go for production a while now, in my experience it's rarely necessary. Sometimes a set is needed, but it's very simple to just use a map[T]struct{}. And if something like union or intersect is needed it's usually less than 20 lines to implement all those operations. Usually that operation is only needed in one instance, and it's very quick to write. Would it be faster to have a builtin generic set? Absolutely, but it's such a small inconvenience I honestly don't care.
- 11y ago

cyphar 11y ago

In what way does Go have great tooling? Your compiler doing dependency management is one of the worst things that Go did (and I'm sure they'd do it differently if they could have their time again). It makes packaging libraries impossible, it caused the whole vendoring thing to happen. If you're talking about gofmt or govet, C has had stuff like that for years. Go's main selling point IMO is that they have added as little to the basic "C" language as possible while also adding as many updated semantics and concepts as possible.

goldbrick 11y ago
I suspect you are just hating. The fact that you immediately glom onto the dependency management issue which EVERYONE KNOWS AND KEN AND ROB ARE REALLY SORRY YALL and also try to cut gofmt and govet off at the pass, which come on, let's be real, the fact that something exists that might remotely resemble those concepts is an extremely fucking far cry from them being standard community practices which if you don't see the value of that then you never dealt with other people's C code... indicates that you know in your heart of hearts exactly how great Go's tooling is. go run, go test, go build, boom! so simple. Oh and might I mention the race detector? Fucking incredible, C never dreamed of something like that. There are plenty of good third-party options available for dependency management (nice double standard btw since you apparently have no problem with third-party stuff for fmt/vet/lint concerns) and there is also this https://golang.org/cmd/go/#hdr-Vendor_Directories https://golang.org/cmd/go/#hdr-Vendor_Directories so a better world is coming don't you fret.
- pcwalton 11y ago
  > Oh and might I mention the race detector? Fucking incredible, C never dreamed of something like that. go race is pretty much a port of Thread Sanitizer, which was a C tool. Before that, there was Helgrind, also a C tool. All of these tools have a long list of forerunners in academia, largely for Java (Eraser, FastTrack, etc.)
  - goldbrick 11y ago
    go race is Thread Sanitizer, in fact, but see again my point about being part of the community best practice vs. a third-party tool you may or may not have heard of. Eraser and FastTrack are un-googleable, if you have any links they would be appreciated.

amelius 11y ago

> Go has such great tooling and a nice ecosystem, but could use some language improvements, like coffeescript or the alt JVM languages. I'd like to see a language that compiles to Go, but also to Javascript, so that code can run on both client and server without changes. That language should not equal Go, because, honestly, some aspects of this language are quite strange: https://golang.org/doc/faq#nil_error https://golang.org/doc/faq#nil_error

Vendan 11y ago
Note that that issue makes perfect sense, and the odds of it affecting you are very very very small. I've written a lot of go code, and have never been affected by it.
dmix 11y ago
Gopher is a Go->Javascript compiler https://github.com/gopherjs/gopherjs https://github.com/gopherjs/gopherjs

lomnakkus 11y ago

So... GHC Haskell, really? The deployment profile, at least, is identical to Go in that you can just link statically and copy the binary. I mean, I don't necessarily condone it, but if you're into "recipe programming" you can just use the Turtle package/modules and get pretty far. The tutorial is pretty amazing. I'm not saying it's a bad thing, necessarily, but I'm one of those crazy people who thinks that a little bit of cogitation should be (and is!) rewarded. Maybe I'm wrong. EDIT: Oh, wait, you said "untyped IO". What does that mean, I wonder?

cgag 11y ago
I want strictness by default too. Looking forward to the strict pragma and using it everywhere. I kind of want Ocaml with a Go sized ecosystem.
- lomnakkus 11y ago
  I don't know if this will be of interest, but I actually started my FP "journey" using O'Caml, oh (pun!) 10-15 years ago, but once I actually learned Haskell for real I didn't look back. There was just no contest. I've actually written a couple of pretty cool libraries for O'Caml that gained some traction in the community, way back when... which is a long-winded way of saying that I'm not a noob when it comes to O'Caml, so it's not that I don't understand what it can do for you :) (I appreciate that people may have different requirements; mine were and are mostly around my own productivity -- not so much real-time/low-latency/predictable performance/etc.).

nikolay 11y ago

BTW, JVM already has a Haskell - it's called Frege [0]. Here are the difference between it and the real deal: [1]. It has a playground, too [2]. [0]: http://www.frege-lang.org/ http://www.frege-lang.org/ [1]: https://github.com/Frege/frege/wiki/Differences-between-Frege-and-Haskell https://github.com/Frege/frege/wiki/Differences-between-Freg... [2]: http://try.frege-lang.org/ http://try.frege-lang.org/