Projekat

Općenito

Profil

Akcije

Reference #19547

Zatvoren

google goo language - golang

Dodano od Ernad Husremović prije skoro 15 godina. Izmjenjeno prije više od 14 godina.

Status:
Zatvoreno
Prioritet:
Normalan
Odgovorna osoba:
Kategorija:
-
Početak:
28.01.2010
Završetak:
% završeno:

0%

Procjena vremena:


Fajlovi

go_talk-20091030.pdf (242 KB) go_talk-20091030.pdf Ernad Husremović, 28.01.2010 11:52
GoCourseDay1.pdf (782 KB) GoCourseDay1.pdf Ernad Husremović, 01.02.2010 18:43
GoCourseDay2.pdf (788 KB) GoCourseDay2.pdf Ernad Husremović, 01.02.2010 18:43
GoCourseDay3.pdf (518 KB) GoCourseDay3.pdf Ernad Husremović, 01.02.2010 18:43

Povezani tiketi 2 (0 otvoreno2 zatvorenih)

korelira sa developer toolbox - Prijedlozi #19596: port harbour gt, rdd? -> ? ima li smisla raditi port ?! ruby, eclipse, qtZatvorenoErnad Husremović03.02.2010

Akcije
korelira sa developer toolbox - Podrška #20718: google golang - go language, mongodb, igranjeZatvorenoErnad Husremović01.07.2010

Akcije
Akcije #16

Izmjenjeno od Ernad Husremović prije skoro 15 godina

xgb Port of XCB to generate Go bindings for X11 Window System by Tor Andersson. (Not technically a 'binding' as it generates Go code that speaks the X protocol.) Now part of the main Go distribution!

Akcije #17

Izmjenjeno od Ernad Husremović prije skoro 15 godina

http://golang.org/doc/go_for_cpp_programmers.html#Interfaces

Stuttering (foo.Foo* myFoo = new(foo.Foo)) is reduced by simple type derivation using the := declare-and-initialize construct.

And perhaps most radically, there is no type hierarchy: types just are, they don't have to announce their relationships.

These simplifications allow Go to be expressive yet comprehensible without sacrificing, well, sophistication.

Akcije #18

Izmjenjeno od Ernad Husremović prije skoro 15 godina

Why is there no type inheritance?

Object-oriented programming, at least in the best-known languages, involves too much discussion of the relationships between types, relationships that often could be derived automatically. Go takes a different approach.

Rather than requiring the programmer to declare ahead of time that two types are related, in Go a type automatically satisfies any interface that specifies a subset of its methods. Besides reducing the bookkeeping, this approach has real advantages. Types can satisfy many interfaces at once, without the complexities of traditional multiple inheritance. Interfaces can be very lightweight—having one or even zero methods in an interface can express useful concepts. Interfaces can be added after the fact if a new idea comes along or for testing—without annotating the original types.

Because there are no explicit relationships between types and interfaces, there is no type hierarchy to manage or discuss.

It's possible to use these ideas to construct something analogous to type-safe Unix pipes. For instance, see how fmt.Fprintf enables formatted printing to any output, not just a file, or how the bufio package can be completely separate from file I/O, or how the crypto packages stitch together block and stream ciphers. All these ideas stem from a single interface (io.Writer) representing a single method (Write). And that's only scratching the surface.

It takes some getting used to but this implicit style of type dependency is one of the most exciting things about Go.

Akcije #22

Izmjenjeno od Ernad Husremović prije skoro 15 godina

http://defunkt.github.com/mustache/

Mustache

Inspired by ctemplate and et, Mustache is a framework-agnostic way to render logic-free views.

As ctemplates says, "It emphasizes separating logic from presentation: it is impossible to embed application logic in this template language."
Overview

Think of Mustache as a replacement for your views. Instead of views consisting of ERB or HAML with random helpers and arbitrary logic, your views are broken into two parts: a Ruby class and an HTML template.

We call the Ruby class the "view" and the HTML template the "template."

All your logic, decisions, and code is contained in your view. All your markup is contained in your template. The template does nothing but reference methods in your view.

This strict separation makes it easier to write clean templates, easier to test your views, and more fun to work on your app's front end.
Why?

I like writing Ruby. I like writing HTML. I like writing JavaScript.

I don't like writing ERB, Haml, Liquid, Django Templates, putting Ruby in my HTML, or putting JavaScript in my HTML.

Usage

Quick example:

>> require 'mustache'
=> true
>> Mustache.render("Hello {{planet}}", :planet => "World!")
=> "Hello World!" 

We've got an examples folder but here's the canonical one:

class Simple < Mustache
  def name
    "Chris" 
  end

  def value
    10_000
  end

  def taxed_value
    value - (value * 0.4)
  end

  def in_ca
    true
  end
end

We simply create a normal Ruby class and define methods. Some methods reference others, some return values, some return only booleans.

Now let's write the template:

Hello {{name}}
You have just won ${{value}}!
{{#in_ca}}
Well, ${{taxed_value}}, after taxes.
{{/in_ca}}

This template references our view methods. To bring it all together, here's the code to render actual HTML;

Simple.render

Which returns the following:

Hello Chris
You have just won $10000!
Well, $6000.0, after taxes.

Simple.

Akcije #32

Izmjenjeno od Ernad Husremović prije skoro 15 godina

http://www.downloadsquad.com/2009/11/12/new-go-integrates-with-chrome-and-chrome-os-native-high-speed/

Google's Native Client software is special in that it runs at much higher speeds than your usual Firefox or Chrome add-ons. It runs much more like another application on your computer, rather than 'a web app' in the browser. It has security built-in that won't allow developers to program dangerous applications.

But it's not actually new. It's been around for months. What is new is that Go, Google's new language, will integrate fully with Native Client!

This means two very important things: a) web apps will be propelled to a new level of speed and complexity when coded in Go with Native Client and b) you are now looking at how applications in Chrome OS will be developed and run.

When you run programs in Chrome OS they will simply be Native Client web applications. There won't be a difference between Photoshop or Gmail, World of Warcraft or FarmVille -- they'll all be tabs in Chrome.

Everything will be a tab in Chrome.

Akcije #33

Izmjenjeno od Ernad Husremović prije skoro 15 godina

http://code.google.com/p/nativeclient/

Native Client is an open-source technology for running native code in web applications, with the goal of maintaining the browser neutrality, OS portability, and safety that people expect from web apps. We've released this project at an early stage to get feedback from the open-source community. We believe that Native Client technology will help web developers to create richer and more dynamic browser-based applications.

Native Client runs on 32-bit x86 systems that use Windows, Vista, Mac OS X, or Linux. Some ARM and x86-64 support is implemented in the source base, and we hope to make it available for application developers later this year.

Akcije #58

Izmjenjeno od Ernad Husremović prije skoro 15 godina

http://code.google.com/p/goplot/

GoPlot is a learning vehicle for experimenting in the Go programming language. The direction of the code is toward a graphing utility with some curve-fitting features. So far it's capable of doing a simple linear regression on the source data.

As of version 0.3.0, GoPlot runs as a web server. The one page it serves presents a graph and a textarea for entering data as x,y pairs, one per line.

Input is simple value pairs (2D points) and results are provided as JSON. The JSON is interpreted on the client side and plotted in SVG using jsxGraph.

Akcije #61

Izmjenjeno od Ernad Husremović prije više od 14 godina

  • Status promijenjeno iz Novo u Zatvoreno
Akcije #62

Izmjenjeno od Ernad Husremović prije više od 14 godina

  • Naslov promijenjeno iz google goo language u google goo language - golang
Akcije

Također dostupno kao Atom PDF