Re: [OT] Go officially won't get generics
Beyond being fodder for people who don't write Go but hate it for some reason, this seems to be an ongoing non-event. The official mailing list has practically no mention of generics anymore.
Re: [OT] Go officially won't get generics
On Friday, 9 May 2014 at 19:07:24 UTC, Jesse Phillips wrote: No, the context around what he said is very important. Google isn't leaving Go development, generics are not nixed for Go 2.0, the language will continue to see bug fixes. This is all very clear with context. I see this as a good. What would you rather use - a third party library written against abstractions or one written against concrete types? I would rather use a library based on concrete types. My observation is that the more abstraction people indulge, the greater the chance I will regard one of their abstractions as a code smell. And it isn't the the case that the lack of generics is inhibiting participation. Go's library selection is already very good and getting better daily. Just yesterday I needed a Go lz4 compression library and was able to find three distinct implementations. Go is not hurting for third-party libraries.
Re: D For A Web Developer
On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote: I think one of the great things about Rails and Ruby is all the libraries and plugins that are available. If I want to do something, in RoR there's a big chance there's already a library for that. In D, there's a big chance I need to implement it myself. this has been the fundamental issue for me. its not just missing libs, its libs that are surfaced via a C-binding, which in my limited experience have been difficult to use and make portability hard. I think D is a superior language to Go, but Go has a very complete SDK and its all written in Go, so I don't have to worry about chasing down native libs to install. brad
Re: Announcing TitaniumD - A D Binding for the Botan Cryptography Library
Adam, this is very cool! do you have any examples showing its use? In particular, examples highlighting D code using AES and SHA libs thanks! brad
how to print ubyte*
hi, I'm back again with another openssl related question.
given this program
--
import std.stdio;
import deimos.openssl.hmac;
import deimos.openssl.evp;
void main() {
HMAC_CTX *ctx = new HMAC_CTX;
HMAC_CTX_init(ctx);
auto key = 123456;
auto s = hello;
auto digest = HMAC(EVP_sha1(),
cast(void *) key,
cast(int) key.length,
cast(ubyte*) s,
cast(int) s.length,
null,null);
}
--
digest should be of type ubyte*
does anyone know how to print this out as ascii?
thanks!
brad
AES encryption with openssl bindings
hi everyone. I'm trying to symmetrically encrypt some text using the openssl bindings. My code compiles and fails silently. Clearly there is something very wrong with it - it could be my novice D skills, or my misuse of the openssl binding. auto chunk = new ubyte[](16); foreach(ref x; chunk) x = uniform; AES_KEY wctx; AES_set_encrypt_key(chunk.ptr,128,wctx); string s = virident; ubyte[] b; b = cast(ubyte[]) s; ubyte[] e; AES_encrypt(b.ptr,e.ptr,wctx); ubyte[] d; AES_decrypt(e.ptr,d.ptr,wctx); writefln(%s,d); Any clues? I am a D novice, so any spoonfeeding you could provide would be helpful :) thanks! Brad
Re: D vs Go in real life
this has been a great thread and I've found a lot of the replies very insightful. I've been programming in Go at work for about a year or so now, so I have some opinions on Go that I believe are reasonably informed, while I am still a D novice but hope to continue learning. First, let me say that it is obvious that, by design, D is a more powerful language than Go. Go's simplicity will either be an advantage or a deal-breaker based on who you ask. On my vps instance last night I tried to create an initial D programming environment, with the following tools: - dmd - dub - vibe.d - ldc (not strictly necessary but I've heard so many good things about it) First I tried installing dmd from source, which was fine but then I would get strange errors about referring to a file object.d when trying to build dub. Some poking around on the web resulted in the advice of installing the pre-built dmd binary that is in the release distribution. Now I was able to build dub, although it was strange to see two completely different build mechanisms for dmd and dub - dmd using a makefile and dub using a sh script wrapper. vibe.d was easier to install once dub worked. Over an hour just to get basic tools installed, although I feel HTTP serving is so common that it should be one of the accepted batteries included by default. If this were Go, I would have installed the default build for my platform and had an http server in my standard sdk and everything else available by go get, which has never failed to work flawlessly for me in a year of dealing with code from the web. This is one reason why there are already so many libraries for Go - it is trivial to expose your code to other developers via the supported toolchain. This might not be a fair assessment given my shallow experience with D, but it seems much less polished relative to Go for setting up a development environment and working with code from the web. Go's tools can be criticized as precluding operating system package managers, if people feel that criticism is valid, maybe a solution is something like the Haskell Platform, which was a reasonable response to the same criticism with haskell in years back - that setting up a development environment with basic consistent libraries was very painful. Haskell Platform does not seek to preclude operating system package managers. Anyway, I hope this didn't seem too harsh. I still am playing with D and hopefully at some point in the future, package managers will address some of these needs. brad
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
an excellent post, thanks for linking it Walter the relative weakness of dynamic-typed tools is compounded by the fact that they tend to be used to build monolithic applications, typical of what might emerge from rails, php etc. you take the whole ball of mud or nothing. with no types to define the rules of engagement, management of the interior of the application becomes lore-oriented...i.e. application lifetime job security for the original developer. but its also important to put dynamic tools in their proper context. in the mid-90s they vastly accelerated many industrial coding chores. they had their time, but I believe that time is over.
Re: Facebook is using D in production starting today
this is fantastic news. I've been reading your book and lurking in these forums unregistered for a while...signed up to congratulate you! brad
