361–367 of 367 posts
I've recently tryed out Go for its Unicode integration. What I liked at first sight... * the indexing makes a map[something]boolean act like a set. Sets and maps are so similar it always felt wrong for them to be two separate constructs. * making exported functions/vars/etc begin with a capital letter. When naming important stuff, it's a relief not worrying about naming conflicts with keywords. When naming locals, ju…
Earlier quoted context omitted.
I'm writing a language in Go. It is fun. Sum types (and ASTs) are implemented with interfaces which provide a pretty clean and type safe way of doing this.
Can you show some small example encoding of an AST in Go?
http://blog.labix.org/2013/07/16/twik-a-tiny-language-for-go
There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen." But, for systems programming, abstractions suck. They always, always have a cost. When abstractions break, you not only have to deal with a broken system but the broken ab…
I'm not writing the following to make people pick another language - if Go is suitable for your project in terms of features, runtime, tools and community, then by all means use Go. It's a fairly decent platform to target and it can further evolve to meet more stringent needs. But if we are talking about the cost of abstractions , the biggest elephant in the room is that Go's GC is NOT optional, which makes it unsuit…
This is an inadequate analysis. I am writing a soft real-time system in Go, and GC pause simply isn't an issue for me. Go allows one to greatly limit the reliance on GC. The GC in Go certainly places an ultimate limit to the memory footprint of any one Go process, but a whole lot of productive work can be done within such limits.
Also, my program is a rewrite of one in Clojure, so it ran on the JVM. Go is giving me better performance for my particular application. Also given that Go is just starting out in its development, I expect there to be some improvement in the future.
For fear of disagree downvotes: I would say that many of the qualms brought up in this article are problems that are encountered fighting the language. The problem of 'summing any kind of list' is not a problem that is solved in Go via the proposed kind of parametric polymorphism. Instead, one might define a type, `type Adder Interface{Add(Adder)Adder}`, and then a function to add anything you want is fairly trivial,…
>When it comes to iteration, there is the generator pattern, in which a channel is returned, and then the thread 'drinks' the channel until it is dry, for example `func (m myType) Walk() chan->myType` can be iterated over via `range v := mt.Walk(){ [...] }`. Non-channel based patterns also exist, tokenisers usually have a Next() which can be used to step into the next token, etc. Actually using channels as a general…
Earlier quoted context omitted.
Can you show some small example encoding of an AST in Go?
The code for Twik has a simple AST in it. Of course, it's Lisp, so it's perhaps too simple. http://blog.labix.org/2013/07/16/twik-a-tiny-language-for-go
Also, the type-switch on interface {} is ugly.
Consider how an AST looks like in Haskell:
data AST
= LiteralInt Int
| LiteralFloat Float
| List [AST]
...
case ast of
LiteralInt int -> ...
LiteralFloat float -> ...
List nodes -> ...
Also, if you add an annotation to each AST element (e.g: inferred types), you can very easily and safely map over them, etc.
Earlier quoted context omitted.
The built-in GC is nothing like the GC needed for lots of other languages. Don't write those languages in Go.
That kind of defeats the whole idea that it's a good language for writing other languages in. Not to mention that to use the GC, you'd have to carry the whole baggage of Go's runtime with you in the new language. And that's Go's GC is not that good in the first place.
Earlier quoted context omitted.
> Always remarkable that such critiques always focus on the utterly trivial, while absolutely ignoring things like concurrency or composing complex systems. But generics are a fundamental tool to solve concurrency or composition. How do you propose to compose complex systems when you can't abstract on the type? How can you add new concurrency constructs that work safely for every type without generics?
Actually Go interfaces map pretty well to a concurrent (and likely networked environment). It's often straightforward to put a network-based implementation behind a Go interface type. When was the last time you saw a web service that is parameterised by a type?
Maybe if Go was dynamic or with full type inference, will like it more :)
I bet is great for the niche between C++ and Java, but not sure if I would want to use as a general programming language