We build products for financial budget planning and management and headcount budget planning and management for growth-stage startups

Doublefin

A Guide to Creating Fun User Polls and Surveys With QuickBlox in Your Flutter App

How to Implement a Dynamic Authentication Form in Flutter

How To Create An Onboard Screen In Android and IOS with Flutter?

Introduction Generic Programming in Go has always been awkward compared to other compiled languages. The most popular ways to implement it in Go are using interfaces, typecasting, and code-generation. But every method has its significant limitations. For instance, using interfaces requires implementing an interface for each data type. Typecasting leads to potential runtime errors. And in the case of code generation, we have to write generators, which takes a lot of time. The article's primary goal is to understand how Generics work in Go and compare their performance with previous Generic Programming methods in Go. I will implement a popular function, " ," that iterates over an array of data and transforms each element using a callback function. Map The article code examples are stored in the . Github repository Go Generic Functions Generic functions were added in Go in the 1.18 release. Generic functions refer to a mechanism for compile-time polymorphism, specifically parametric polymorphism. These are functions defined with Type Parameters, intended to be resolved with compile-time type information. The compiler uses these types to instantiate suitable versions, resolving any function overloading appropriately. Generic functions in Go allow: define type parameters for function and types. define interface types as sets of types, including types that don’t have methods. define type inference, which permits omitting type arguments in many cases when calling a function In practice, it gives the following features: code writing becomes comfortable for developers since there is no need to implement or generate code for every new data type a compile-time type safety a runtime type safety Go Generic Function — Map Example Let’s see how Generic Functions work in Go. And for the real-world example, we will use the function. The function takes a slice and a callback that modifies every item and returns a new slice. Map The function implementation for integer values looks like this: Map // Map modifies every item of list and returns a new modified slice.
func Map[T any](list []T, modify func(item T) T) []T {
	if list == nil {
		return nil
	}

	if modify == nil {
		return list
	}

	mapped := make([]T, len(list))
	for i, item := range list {
		mapped[i] = modify(item)
	}

	return mapped
} There are two checks on values for a list and a callback function for safety. After that, there is a new slice with the same length as a list. Then, the function iterates through a list, modifies each item, and writes the item in a new slice . An example of how the function works: nil mapped package main

func main() {
    // prints 2, 4, 6
    fmt.Println(Map([]int{1,2,3}, func(item int) int {
		return item * 2
	}))
} However, if there is a need to use the function with another type, it needs to implement a new function. This architecture isn't scalable and hard to maintain. But using new Generic Functions, we can create a single function that will work with all types that we need: Map // Map modifies every item of list and returns a new modified slice.
func Map[V any](list []V, modify func(item V) V) []V {
	if list == nil {
		return nil
	}

	if modify == nil {
		return list
	}

	mapped := make([]V, len(list))
	for i, item := range list {
		mapped[i] = modify(item)
	}

	return mapped
} Type is a new alias for . any interface{} The function implementation looks similar to the integer mapping implementation. The only difference is the function signature. Now there is a type parameter definition which means that the function can handle any type, but it should be the same type in a callback function . Let’s see how the function works for different types: [V any] modify func(item V) V) []V Map package main

import (
	"fmt"
	"strings"
)

type person struct {
	name string
	age  int
}

func main() {
	// prints [2 4 6]
	fmt.Println(Map([]int{1, 2, 3}, func(item int) int {
		return item * 2
	}))

	// prints [HELLO WORLD]
	fmt.Println(Map([]string{"hello", "world"}, func(item string) string {
		return strings.ToUpper(item)
	}))

	// prints [{Linda 19} {John 23}]
	fmt.Println(Map([]person{{name: "linda", age: 18}, {name: "john", age: 22}}, func(p person) person {
		p.name = strings.Title(p.name)
		p.age += 1

		return p
	}))
} Go Generic Functions Internals This section will research how Generic Functions behave during compilation and program runtime. Runtime type safety For the research, I will use the following Go program: package main

import (
	"fmt"
	"runtime"
	"strings"
)

type person struct {
	name string
	age  int
}

func main() {
	ints := []int{1, 2, 3}
	doubledInts := Map(ints, func(item int) int {
		return item * 2
	})

	// prints [2 4 6]
	fmt.Println(doubledInts)

	words := []string{"hello", "world"}
	capitalizedWords := Map(words, func(item string) string {
		return strings.ToUpper(item)
	})

	// prints [HELLO WORLD]
	fmt.Println(capitalizedWords)

	people := []person{{name: "linda", age: 18}, {name: "john", age: 22}}
	modifiedPeople := Map(people, func(p person) person {
		p.name = strings.Title(p.name)
		p.age += 1

		return p
	})

	// prints [{Linda 19} {John 23}]
	fmt.Println(modifiedPeople)

	runtime.Breakpoint()
}

// Map modifies every item of list and returns a new modified slice.
func Map[T any](list []T, modify func(item T) T) []T {
	if list == nil {
		return nil
	}

	if modify == nil {
		return list
	}

	mapped := make([]T, len(list))
	for i, item := range list {
		mapped[i] = modify(item)
	}

	runtime.Breakpoint()

	return mapped
} There are two runtime breakpoints for debug purposes. For convenience, I use JetBrains Goland IDEA to debug the code. After running the program in debug mode we can see that the first call of the function contains the with . Map list []int However, the following two function calls have different types in runtime: Therefore, a specific, strictly defined type is passed from a caller function in runtime inside the function. Map Also, in the function all types are defined as well: main We can conclude, that Generics in Go retain their type information at runtime, and in fact, Go does not know about the generic "template" at runtime - only how it was instantiated. do To make sure that type is retained during compilation, we can try to assign to : capitalizedWords []string doubledInts []int ints := []int{1, 2, 3}
	doubledInts := Map(ints, func(item int) int {
		return item * 2
	})

	words := []string{"hello", "world"}
	capitalizedWords := Map(words, func(item string) string {
		return strings.ToUpper(item)
	})

	doubledInts = capitalizedWords Here happens a compilation error: ./main.go:24:16: cannot use capitalizedWords (variable of type []string) as type []int in assignment Therefore, Go does enforce type safety for generic types at runtime. Runtime instantiation Let’s see what happens if we try to inspect a Generic Function in runtime using reflection: package main

import (
	"fmt"
	"reflect"
)

func main() {
	fmt.Println(reflect.TypeOf(Map))
}

// Map modifies every item of list and returns a new modified slice.
func Map[T any](list []T, modify func(item T) T) []T {
	if list == nil {
		return nil
	}

	if modify == nil {
		return list
	}

	mapped := make([]T, len(list))
	for i, item := range list {
		mapped[i] = modify(item)
	}

	return mapped
} Trying to compile the program returns an error: ./main.go:9:29: cannot use generic function Map without instantiation Therefore, Generics are not helpful in Go until instantiated. There is no way to refer to generic "templates" using reflection, which means it is not possible to instantiate new types using Generics at runtime. It is almost as if generic types do not exist in compiled Golang binaries. Generic Functions Performance We researched how Generic Functions work during compilation and runtime. The last important question is: how fast do they perform? There are three different implementations of the function: Map // Map modifies every item of list and returns a new modified slice.
func Map[T any](list []T, modify func(item T) T) []T {
   if list == nil {
      return nil
   }

   if modify == nil {
      return list
   }

   mapped := make([]T, len(list))
   for i, item := range list {
      mapped[i] = modify(item)
   }

   return mapped
}

// MapTyped modifies every item of list and returns a new modified slice. It works only with Integer values.
func MapTyped(list []int, modify func(item int) int) []int {
   if list == nil {
      return nil
   }

   if modify == nil {
      return list
   }

   mapped := make([]int, len(list))
   for i, item := range list {
      mapped[i] = modify(item)
   }

   return mapped
}

// MapAny modifies every item of list and returns a new modified slice. It works with Any type, so you should cast types by yourself.
func MapAny(list []any, modify func(item any) any) []any {
   if list == nil {
      return nil
   }

   if modify == nil {
      return list
   }

   mapped := make([]any, len(list))
   for i, item := range list {
      mapped[i] = modify(item)
   }

   return mapped
} For benchmark, we use a list of integers and a callback function that doubles each integer value: []int{1,2,3} func BenchmarkGenericMap(b *testing.B) {
	for i := 0; i < b.N; i++ {
		Map([]int{1, 2, 3}, func(item int) int {
			return item * 2
		})
	}
}

func BenchmarkTypedMap(b *testing.B) {
	for i := 0; i < b.N; i++ {
		MapTyped([]int{1, 2, 3}, func(item int) int {
			return item * 2
		})
	}
}

func BenchmarkAnyMap(b *testing.B) {
	for i := 0; i < b.N; i++ {
		MapAny([]any{1, 2, 3}, func(item any) any {
			return item.(int) * 2
		})
	}
} After calling the command, we have the benchmark results that are described in the table below: go test -bench=. -benchmem -v ./... Map function type Operations count ns/op bytes/op allocs/op Generic 42033705 28.90 24 1 Typed 41317022 29.16 24 1 Any (using type casting) 17563975 68.61 48 1 The benchmark takeaways: the Generic Function has the same performance as a specifically-typed function implementation on average, the Generic Function outperformed the Any (using type casting) implementation: operations are ~2.4 times faster consumed half the memory the performance improvements were the result of removing the need to use a type casting Conclusion We researched what the Generic Functions are and how they work in Go. Also, we compared the Generic Functions' performance with previous Generic Programming methods. Finally, there are the main conclusions: Generics allow to write a function only once and use it for different data types without any extra code. Therefore, it’s easier to scale and maintain. Go Generic Functions are instantiated during compilation, and they aren’t presented in program runtime. That prevents unexpected behavior in a program and guarantees a type-safety. Go Generic Functions have the same performance as a specifically-typed function implementation, but it’s preferable since there is no need to write a new function for each data type. References Generic function - Wikipedia ( ) https://en.wikipedia.org/wiki/Generic_function An introduction to Generics - The Go Programming Language ( ) https://go.dev/blog/intro-generics Go generics the hard way ( ) https://github.com/akutz/go-generics-the-hard-way

Generic Programming in Go

Crypto Crash? Not Really... 

In this article I’ll introduce an implementation for Singly and Doubly Linked Lists, which you can reuse or modify for your own purposes. All the or as an npm package. code is available in github Coding data structures in Solidity is weird and beautiful. A few months ago I implemented a in Solidity for a client. More recently I decided that I might take on implementing a in Solidity as a pet project (aren’t nerds fun!) and Linked Lists appeared again. Linked List Fast Limit Order Book As I recently wrote in an article about : when to use different data structures Linked Lists are your data structure of choice when you need to preserve the insertion order, and also when you want to insert in arbitrary positions. I love coding and no one seemed to have done this one*, so I took to it happily. basic building blocks *Disclaimer: While writing this article, and after having coded the contracts, I found this from . Like him, I also considered using an array. Compared to using a mapping, it simplifies the creation of new items but also makes deletion more difficult. earlier implementation chriseth Implementation For this article I’m going to ignore that and code the lists in a single contract. Doing that will allow me to focus on the basics such as data usage. An , but the trade offs deserve an article of its own. Solidity is an Object Oriented Programming Language OOP implementation is possible Implementing a Linked List in a single contract Solidity was not an obvious thing to do. This code would be very convenient, but not doable in Solidity since you can’t have recursive . structs contract ImpossibleLinkedList {
   struct Item {
      Item next;
      address data;
   }
Item public head; The only dynamic contract variable that exists in Solidity are mappings. Even arrays are mappings under the hood. Given that constraint the best implementation for a Linked List in Solidity that I could come up is based on this: contract LinkedList {
  struct Item {
    uint256 id;
    uint256 next;
    address data;
}
mapping ( Item) public items;
uint256 public head;
uint256 public idCounter; => uint256 The Linked List is made of Item. The Item has a unique id, a member for the id of another Item, and an address which is the data payload. Then all items created are stored in a mapping indexed by Item id. You can retrieve any Item at cost O(1) if you know its id, just by looking it up in the mapping. If you are looking at an Item in the List and want to proceed to the next one you have to retrieve item.next which is an Item id, and then look up that next Item in the mapping. If this gets you confused, don’t feel bad. I also got very confused. My first question was “is there any point to a Linked List if you can just arbitrarily retrieve any Item from a list?”. The question is that yes, there is a point, but with a very limited scope. Linked Lists are your data structure of choice when you need to preserve the insertion order, and also when you want to insert in arbitrary positions. The fact that you can iterate over the list is useful to a point, if you have to do that in a transaction the list cannot grow indefinitely. You can use this data structure when a contract needs to frequently use several items in an ordered list that you can assume will be of limited size. For example if you need a contract to always know the 100 largest holders of a token to give them some perks. Unlike in previous articles, this time I’m not going to paste the whole code here. Instead I will direct you to the . There is an implementation for a Singly Linked List and another one for a Doubly Linked List, with each one being about 200 lines of code, which I’ve crafted carefully for maximum clarity. full implementation In this case I think it is more important to discuss the trade offs between a Singly Linked List and Doubly Linked List, in particular given that the Ethereum blockchain is quite limited in the algorithms that you can . execute safely Usage When I started the implementation of linked lists, I thought that doing a Doubly Linked List would be more complex than a Singly Linked List. Interestingly enough, it is slightly easier to implement the former. Adding in each item a link for the previous one allows you to remove this inefficient method: { (_id == head) ;
  Item memory prevItem = items[head]; (prevItem.next != _id) {
    prevItem = items[prevItem.next];
  } prevItem.id;
} /**
 * @dev Given an Item, denoted by `_id`, returns the id of the Item
 * that points to it, or 0 if `_id` refers to the Head.
 */ ( ) ( ) function findPrevId uint256 _id public view returns uint256 if return 0 while return That statement is evil. while You would use this method anytime that you know of an item and you want to insert another before it. Quite a common use case. A gas comparison between LinkedList.sol and DoubleLinkedList.sol sheds some more light on the issue. For these tests I used a list with 100 items. and operations with LinkedList are O(1) and cost about 100K gas. Data retrieval is not depicted but given that we use a mapping the cost will be O(1). addHead insertAfter The issue is when we need to loop over the list. Every item we loop through seems to cost about 1K gas as seen in findTailIdWithGas (which is a mock function that encloses findTailId in a transaction, wasting some gas). Maybe we can make without adding items at the tail or inserting before a known item, but the remove function is more of an issue. In a LinkedList you have to loop through the list from the head to remove items. In smart contracts a method with a cost of O(N) needs to be approached very carefully, or better even, avoided. A Doubly Linked List is easier to implement and more practical, even if a bit more expensive to use. In this specific case, and with a gas block limit of about ten million, it means that you can’t remove items that are more than 10,000 positions away from the head. That can be quite dangerous. For , on the other hand, all the methods are O(1). addHead and insertAfter are more costly than in because we need to update an extra pointer. If you need to insert at the end of the list, find neighbouring items in both directions, or remove items, you’ll benefit from O(1) cost. I haven’t included gas costs for looping the list but they should be identical to LinkedList. DoubleLinkedList LinkedList And as I said before, it’s interesting that for the same functionality, costs less to deploy than LinkedList. Not that important but interesting. DoubleLinkedList As with anything, your mileage will vary. Maybe you can do with a Singly Linked List, maybe you need a Doubly Linked List. Maybe you should use an array. At least now you know them all. Other Implementations The implementations discussed above are not the only ones, I just thought they would be easy to understand. There are other interesting implementations that might fit your use case better: You want to save some gas, then remove the id field from the Item struct. You don’t actually need it, funny enough. You don’t like the structs, them replace each struct variable with a mapping as a state variable, it will work exactly the same. You are happy with just appending items at the tail, and maybe those items expire after a set period of time: You can use . It would work great for a traditional fast limit order book. RenounceableQueue.sol If all the items in your list are unique, then you can use . I like the compactness and elegance of it. OrderedSet.sol If all the items in your list are unique, but you don’t care about the order, then you are after a canonical , get it from . Set OpenZeppelin Conclusion are the first complex data structure that is considered in smart contracts. Given the constraints in smart contracts that force us to code as simply as possible it is necessary to know the trade offs between different linked list implementations. Linked Lists In this article I’ve shown both Singly Linked Lists and Doubly Linked Lists, pointing to . An analysis of gas costs has also been provided, along with guidance for safe use. code ready to be reused I feel quite privileged to have the opportunity to code basic data structures. Sometimes coding smart contracts feels like a trip many years back when programming meant being very close to the hardware and was very close to mathematics. I like that. If you are considering using this code in a project, want to contribute, or have ideas to explore, please ! Talking to those that read me is always a pleasure :) drop me a line

A Linked List Implementation for Ethereum [Deep Dive]

“Proof-of-Nuclear-Bombs”: a most reliable design for stablecoin utility (Part I)

Note - this article was originally published on the in November 2017. Given the recent changes in Twitter, I thought it was a good time to look back at the work I and others did to double the original character count. Twitter Design blog · Looking After Number One-forty Solving a number of design challenges One defining aspect of Twitter, starting way back when we were still Twttr, is 140-character Tweets. For some, the character constraint has been a fun challenge. It motivates people to be briefer and more creative with their words. We’ve even heard people say that it’s helped them improve their writing. For many people, though, the limitation can be an incredibly frustrating part of using Twitter. It forces them to hack their sentences, severely limits their ability to express their thoughts, and often leads people to abandon their Tweets. We love the brevity of Twitter, but we also want people to be able to easily share their thoughts. When we looked into the data on Tweet length, we discovered an interesting pattern: depending on language, people have a very different experience with the 140-character limit. For example, in information dense languages, like Japanese or Korean, 140 characters isn’t very limiting. People in Japan are able to express a lot in 140 characters and don’t have any complaints about the limit. In languages like English, Spanish, French, and especially German, the character limit is a consistent complaint we’ve seen in our research over the years. A great example of this disparity can be seen below: The same basic idea expressed in three languages, English, Spanish, and Japanese. With this in mind, we designed a system that defines two types of written languages, dense and non-dense, and expands the character limit for non-dense languages. By grouping languages this way, we can give people writing in non-dense languages like English and Spanish the same space to express themselves as people writing in information-dense languages like Japanese. This will make sharing thoughts and ideas on Twitter a lot less frustrating for many more people, while maintaining brevity on Twitter overall. This is where the design challenge comes in: How can we make a UI that communicates these different character constraints that is still easily understood globally? Simply replacing the number doesn’t work because we can’t be certain which language you’re going to be Tweeting in. We could guess which language you’ll use, based on your location or system language, but that falls apart quickly, as many people live in foreign countries or travel regularly. Additionally, many people Tweet in multiple languages, sometimes within a single Tweet. Because we count dense alphabets differently than non-dense, mixed language Tweets can result in some intricate math that we want to be able to abstract away. The challenge here was to create a design that adapts to different character limits without relying on a number, works with the many ways people compose Tweets, and is intuitive enough that people don’t have to spend time thinking about it. During the initial design brainstorms, it became quickly apparent that there are lots of questions we needed research to help with. We knew we needed to understand all the different circumstances around how people compose Tweets, but we also had to answer some other key unknowns: Do people look at the number while composing a Tweet now? When does the number become important? Is just a warning sufficient enough? What happens when they go over the limit? When they’re getting close to the end, how soon do they worry about it? How important is UI progress indicator for people to understand how much space they have left as they compose? Based on these questions, I went through quite a few design explorations. This included 27 different, animated prototypes ( is my jam, in case you were interested), more than a couple design brainstorms, internal crit sessions, and a lot of revisions. At the end of all these explorations, we conducted in-person testing across two countries (Japan and the US) with a handful of functional prototypes. Principle In-person testing was very valuable in helping us identify what was working and what wasn’t. A great example of this is how one of my favorite designs totally failed. For this prototype in particular, I had decided to remove the counter completely until they got close to the limit (20 characters left). At that point they would see a small tracking number following their cursor. Despite what I initially thought, it actually ended up being quite confusing to people in our testing session. One of the research participants in Tokyo said, “I like the one with both circle and the number at the end. With the circle, I can intuitively know how much left to go. Also, without the number counting down from the beginning, I don’t have to feel pressured as I type in the Tweet.” This reasoning for liking the a combination of abstract + granular design was shared by our Japanese research participants. While I thought removing the UI until it was relevant would help alleviate the stress of the character limit, it ended up having the opposite effect; people were unable to properly plan their Tweet since they had no feel for how far along they actually were. Through our research, we were able to define some clear design constraints, including answering a lot of the unknowns. In the end, the research refocused our design needs: Be an abstract counter to support multiple counting methods Show progress throughout Have a granular counter appear as people got close to the end Use color or another visual indicator as a warning Lean less on subtlety or people won’t notice it Support all our composers Ultimately, we landed on a design that solves those needs and still felt “Twittery.” We wanted something lightweight and clear with some small elements of delight. Of course, just feeling something isn’t enough, so we’ve been tracking whether it’s working or not. Not only do we want people to understand the experience when composing Tweets, but we need to understand the impact of this change overall on brand perceptions — 140 was so core to who we were for more than a decade. In addition to researching people’s expression experience on the platform, we also worked to understand the impact of the character limit change on the overall perception. We wanted to make sure we maintained our identity as a brief way to consume information. Our brand research found that people in the experiment continued to think of Twitter as a concise way to consume information. We also discovered a measurable drop in these same people citing the character limit as a reason for dissatisfaction. One advantage of working on a digital product like Twitter is that our jobs are never done. Another advantage is that people can tell us what they think of our changes simply . We’ll be watching how people use their newfound 280 characters, and seeing if there are areas we can improve. I’m looking forward to seeing and hearing how everyone is using this update. with a Tweet There were lots of people involved in this project, but I want to give a huge thanks to Kiyotoshi Yamauchi and Dandan Zhang for helping with the research on this project. Photo help from Aastha Bhargava and . Also, for more details on some of the more technical aspects of this project check out our great engineering Josh Silverman blog . posts

DOUBLEFIN

doublefin.com

-- employees

Since n.d.

COMPANY RANKING

DOUBLEFIN

EVERGREEN INDEX #3874

Representing this company? Click here to claim and customize this page!

Doublefin WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

DOUBLEFIN

doublefin.com

-- employees

Since n.d.

COMPANY RANKING

DOUBLEFIN

EVERGREEN INDEX #3874

RELATED COMPANIESRANK

STORIES ABOUT DOUBLEFIN

Representing this company? Click here to claim and customize this page!

Doublefin WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!