sagichmal

101 ms·

1021.
by sagichmal 12y ago
Good news, friend! http://soundcloud.com/jobs :)
1022.
by sagichmal 12y ago
You got it on your edit. The inbox is generated dynamically from multiple outboxes. The time series data, however, is not able to fit in one server's memory; it's sharded over multiple non-communicating Redis instances, collecti
1023.
Roshi: a CRDT system for timestamped events(developers.soundcloud.com)
108 points by sagichmal 12y ago|29 comments
1024.
by sagichmal 12y ago
It's true: not all features yield net benefit.
1025.
by sagichmal 12y ago
> I am on the side for proper dependency management. Vendoring is one of several proper dependency management options. It's also the option most suited to the Go ecosystem at this time.
1026.
by sagichmal 12y ago
> Rob said something interesting at the end, it appears > they are leaving the language to the community and > stepping out. He said nothing to imply that at all.
1027.
by sagichmal 12y ago
By "the language" he means Go major-version-1. There will be no generics in Go 1, that's clear. The path is wide open for Go 2, though.
1028.
by sagichmal 12y ago
> [go get] Only works for source code packages, not > binary dependencies. There's no such thing as a binary dependency in the Go ecosystem. (At least, not without stretching some definitions.) It's one of Go&#
1029.
by sagichmal 13y ago
The name change to "Go" happened after Go(lang)'s public release. Kind of a dumb move.
1030.
by sagichmal 13y ago
I totally agree with the parent: far better to have 8 methods doing the same thing with different names and statically-typed parameters, than 1 method taking interface{}s. Strong +1 to a change in API.
1031.
by sagichmal 13y ago
Lines of code in type declarations isn't an interesting metric. Type safety, however, is.
1032.
by sagichmal 13y ago
> Your hand written CRUD operations gain you nothing but > extra work. And maintainability. (shrug)
1033.
by sagichmal 13y ago
> I suppose my question is more along the lines of whether > we'll ever see a package in go that would standardize > the data-object divide There is no lucid standardization possible for the data-object div
1034.
by sagichmal 13y ago
> you're being a human compiler. The transformation from "type instance in my language" to "relational data in my storage engine" is absolutely not "compilation". It's a subtle translatio
1035.
by sagichmal 13y ago
> (unless one actually feels they can write something > better than, say ActiveRecord, from scratch). The point is that ActiveRecord's method of modeling, especially when it comes to dynamically mapping language co
1036.
by sagichmal 13y ago
I suppose the Go philosophy would discourage developers from tightly coupling Go types and their relational representations through an ORM. The idiomatic way of mapping your objects to a database is by defining a thin interface around a sql
1037.
by sagichmal 13y ago
> I was decoding a large JSON data structure that could > easily have thousands of different fields nested 10+ > levels deep. Go's standard json library usually > recommends that you define a struct t
1038.
by sagichmal 13y ago
> The type system literally straddles the dynamic and > static The Go type system is fully static...
1039.
by sagichmal 13y ago
Article contents, since the link is caught in some infinite loop: http://pastebin.com/zx0q56hG Is this really HN front page material?
1040.
by sagichmal 13y ago
Sure, the monolithic app at the center is still Rails. We're working to deprecate it and go all SOA/microservice, but many of those services are JRuby. tl;dr still very polyglot here.
1041.
by sagichmal 13y ago
The underlying Raft implementation is brand new, and looks much improved on the goraft used by etcd. Very impressed.
1042.
by sagichmal 13y ago
> How do companies which do this keep the support workload > of developers low enough so that they have time for > development? Development and operations are not distinct things. A novel algorithm, say, needs
1043.
by sagichmal 13y ago
Good article. It closely reflects the experience we've had at SoundCloud in our more heavily-stressed services.